Networking: zero to CCNA

1. Follow one packet

An IP address identifies an interface at the network layer. A subnet prefix tells a host which destinations are local. Ethernet uses MAC addresses for delivery on a local link. For a remote destination, the host sends the frame to its gateway’s MAC address while the IP destination remains the remote host. DNS translates names into addresses.

Linux:
ip -brief address
ip route

Windows CMD:
ipconfig /all
route print

What to expect

Find your own address, prefix or mask, default gateway, and DNS servers. Values depend on your network; record them without changing them.

It is outside 192.168.10.0/24. The frame goes to the configured default gateway on the local link; the packet’s destination is still 192.168.20.5.

Watch for: A switch usually forwards Ethernet frames within a VLAN. Routing connects IP networks. A home router may combine switching, routing, Wi-Fi, DHCP, and NAT in one box.

2. Subnet by block size

An IPv4 address has 32 bits. /26 leaves 6 host bits: 64 addresses per block. In a conventional LAN, one address names the network and one is broadcast, leaving 62 host addresses. /31 point-to-point links and /32 host routes are special cases.

192.168.10.0/26     .0–.63
192.168.10.64/26    .64–.127
192.168.10.128/26   .128–.191
192.168.10.192/26   .192–.255

What to expect

For 192.168.10.70/26: network .64, hosts .65–.126, broadcast .127; mask 255.255.255.192.

A /27 block has 32 addresses. .150 falls in .128–.159. Network .128; usable hosts .129–.158; broadcast .159; mask 255.255.255.224.

Watch for: An address ending in .0 is not always a network address. Prefix length determines the boundary.

3. Build a two-host LAN

In Packet Tracer, add a switch and two PCs. Connect both PCs to switch access ports. Set PC A to 192.168.10.10/24 and PC B to 192.168.10.20/24. Leave gateways blank: this lab stays within one subnet. Hosts use ARP to discover the destination’s MAC address.

On PC A:
ping 192.168.10.20

On the switch CLI:
enable
show interfaces status
show mac address-table

What to expect

After links converge and ARP resolves, pings should succeed. The switch learns source MAC addresses against the connected ports.

The hosts now consider each other remote, but no router or gateway exists. Restore PC B to 192.168.10.20/24 and verify connectivity again.

Watch for: An initial ping can fail during ARP or link convergence. Repeated failures need investigation; do not treat every lost first packet as a configuration fault.

4. Troubleshoot in layers

Use a hypothesis, one test, and an observation. Start with link state and addressing, then local reachability, routing, DNS, and the application’s port. A successful ping demonstrates some IP reachability; it does not prove DNS, HTTPS, or authentication works.

Linux lab inspection:
ip -brief link
ip route
ping -c 3 192.168.10.20

Windows lab inspection:
ipconfig
ping -n 3 192.168.10.20

What to expect

Each command answers a narrower question: link up, route present, peer reachable. Capture the exact error instead of recording only “network broken.”

Investigate name resolution and compare the intended DNS answer with the configured resolver. Be careful with HTTPS: certificates and virtual hosting mean raw-IP browsing is not generally an equivalent test.

Watch for: ICMP may be filtered. Ping failure alone cannot establish that a host or service is down.

5. Carry two VLANs across one trunk

Before this lesson: Complete the first four networking lessons. Use a new Packet Tracer file with two 2960 switches, S1 and S2, and four PCs. These are legacy IOS-style learning commands, not instructions for a production or newly purchased switch. Outcome: distinguish a VLAN, a subnet, an access port and a trunk by predicting which hosts can communicate.

A VLAN divides a switched network into separate layer-2 broadcast domains. An access port carries one data VLAN to an ordinary endpoint. A trunk carries multiple VLANs across a switch-to-switch link; 802.1Q tags identify most of those frames. The native VLAN normally carries untagged traffic on this lab's trunk and must match at both ends. A VLAN number is not an IP subnet, although our simple design assigns one subnet to each VLAN.

Connect S1 Gi0/1 to S2 Gi0/1. On each switch connect one PC to Fa0/1 (VLAN 10) and one to Fa0/2 (VLAN 20). Give S1's PCs 192.168.10.11/24 and 192.168.20.11/24; give S2's PCs .12 in the corresponding subnet. Leave gateways blank. There is no router. VLAN-10 peers should communicate across the trunk; a VLAN-10 PC cannot communicate with a VLAN-20 PC.

Enter the common configuration below on BOTH switches, then give them their own hostnames if desired. VLAN 999 is an otherwise-unused native VLAN, not a magic security feature. Explicit access/trunk modes make the intended role visible. switchport nonegotiate suppresses DTP negotiation on this statically configured link. Some simulated models omit a command; use interface ? and the matching device documentation rather than changing unrelated settings.

Use three distinct checks: show vlan brief for VLAN existence and access membership, show interfaces trunk for operational trunks and allowed/forwarding VLANs, and ping for end-to-end behavior. A configured trunk with a down cable is not an operational trunk. A ping result alone cannot tell you which configuration mistake caused failure.

! Apply on S1 and S2; these are switch CLI commands.
enable
configure terminal
vlan 10
 name NOTES
vlan 20
 name AUDIO
vlan 999
 name UNUSED_NATIVE
exit
interface fastethernet0/1
 switchport mode access
 switchport access vlan 10
 no shutdown
exit
interface fastethernet0/2
 switchport mode access
 switchport access vlan 20
 no shutdown
exit
interface gigabitethernet0/1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,999
 switchport nonegotiate
 no shutdown
end
show vlan brief
show interfaces trunk
show interfaces gigabitethernet0/1 switchport

Run it

Set the four PC addresses in Desktop → IP Configuration. From S1's VLAN-10 PC, ping 192.168.10.12, then 192.168.20.12. From S1's VLAN-20 PC, ping 192.168.20.12. Wait for links/STP/ARP to settle and repeat before diagnosing an initial dropped packet. Save the working simulator file as the baseline.

What to expect

The two same-VLAN tests succeed after convergence. Cross-VLAN traffic fails because no inter-VLAN routing exists. The trunk reports VLANs 10,20,999 as allowed; forwarding output additionally depends on VLAN existence and STP state. Access ports appear in their assigned VLANs. Do not expect trunk membership to be listed like an access port in show vlan brief.

! S2 only, lab failure:
configure terminal
interface gigabitethernet0/1
 switchport trunk allowed vlan remove 20
end
show interfaces trunk
! VLAN 10 still works; VLAN 20 fails across switches.
! Repair:
configure terminal
interface gigabitethernet0/1
 switchport trunk allowed vlan add 20
end
show interfaces trunk
! Repeat the pings. IP renumbering does not change switch VLAN
! membership; same-subnet hosts in separated VLANs still cannot ARP
! across those domains. Independent check: explain a working VLAN 10
! and broken VLAN 20 without blaming DNS (these pings use addresses).

Watch for: An allowed-list command without add/remove replaces the list. Create VLANs on both switches; allowing a number does not create it. Native-VLAN mismatches cause incorrect traffic classification. Never enable PortFast on these switch-to-switch trunks. Keep saved lab files; hardware procedures and exact interface names depend on platform.

Lesson references

• Cisco IOS 15.2(2)E: VLAN trunks; reviewed 14 September 2026 ↗
• Cisco VLAN configuration ↗

6. Explain a blocked link before you fix it

Before this lesson: Complete lesson 5 and save a copy of its working two-switch lab. Add a second cable, S1 Gi0/2 to S2 Gi0/2. Outcome: identify the root bridge, distinguish a redundant physical path from a forwarding path, and observe reconvergence without disabling loop prevention.

Two parallel forwarding links create a layer-2 loop unless the network coordinates their use. Broadcast frames have no IP-style hop limit at the Ethernet switching layer. Spanning Tree Protocol (STP) creates a loop-free forwarding topology while keeping alternate physical paths available. A blocked or discarding port can therefore be evidence of healthy redundancy.

For a VLAN, switches elect the lowest bridge ID as root. The priority component wins before the MAC-address tie-breaker. Set S1's base priority to 4096 and S2's to 8192 for VLANs 10 and 20 so the result does not depend on whichever virtual MACs the simulator assigned. With the extended system ID, show output may display base priority plus VLAN ID: 4106 for S1 in VLAN 10 is expected, not a configuration typo.

On each non-root switch a root port provides its best path toward the root. A designated port forwards for its segment. An alternate path is held out of ordinary data forwarding. Rapid-PVST+ applies rapid spanning-tree behavior per VLAN. It can reconverge faster than classic STP in suitable point-to-point/edge conditions, but never promise zero packet loss or one universal recovery time.

Use both links as identical trunks, retaining VLAN 999 as native. Configure the common block on both switches and the separate priority block on each named switch. With equal link costs, S2 should select one root port and hold the other alternate/discarding. Identify the chosen port from show output rather than assuming it from the cable's appearance.

! BOTH switches:
enable
configure terminal
spanning-tree mode rapid-pvst
interface range gigabitethernet0/1 - 2
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,999
 switchport nonegotiate
 no shutdown
end

! S1 ONLY:
configure terminal
spanning-tree vlan 10,20 priority 4096
end

! S2 ONLY:
configure terminal
spanning-tree vlan 10,20 priority 8192
end

! Inspect on BOTH:
show spanning-tree vlan 10
show spanning-tree vlan 20
show interfaces trunk

Run it

Record the root ID, local bridge ID, root port and role/state of each uplink on S2. Repeat a same-VLAN PC ping. Disconnect the cable attached to S2's current root port, observe role changes, then reconnect it. Record whether packets were lost and how long recovery took in your simulator. Do not disable STP.

What to expect

S1 is root for VLANs 10 and 20. S2 has one forwarding root port and an alternate path after convergence. Losing the current root link leaves a usable surviving trunk that can become the root path. Reconnecting the preferred path can trigger another transition. VLAN 999's root was not explicitly set by these priority commands; do not assume its topology matches the teaching VLANs.

! S1:
configure terminal
spanning-tree vlan 20 priority 8192
end
! S2:
configure terminal
spanning-tree vlan 20 priority 4096
end
show spanning-tree vlan 10
show spanning-tree vlan 20
! VLAN 10 still roots at S1; VLAN 20 roots at S2.
! Per-VLAN trees are separate elections, not one global port state.
! Restore S1 VLAN 20 to 4096 and S2 VLAN 20 to 8192.
! Checkpoint: explain why removing redundancy can make a blocked
! port disappear while making the network less resilient.

Watch for: Do not 'repair' an alternate port by disabling STP or applying PortFast to an inter-switch link. Root selection is not based on hostname or highest CPU performance. Link speeds, port costs and bridge IDs affect roles. A simulator's timing is not a production convergence guarantee.

Lesson references

• Cisco STP and rapid-PVST+ configuration; reviewed 14 September 2026 ↗

7. Bundle links with LACP and verify the members

Before this lesson: Complete VLAN/trunk and STP lessons. Start a separate two-switch lab copy with the same four-PC/VLAN address plan. Use Gi0/1 and Gi0/2 between S1 and S2. Keep those uplinks shut while configuring both ends. Outcome: distinguish physical members, the logical port-channel and per-flow capacity.

An EtherChannel groups compatible physical links into one logical interface. STP sees the bundle as one logical path instead of treating its members as independent parallel paths. LACP is the negotiation protocol used here. Active initiates negotiation; passive responds. Active/active and active/passive can form a channel; passive/passive cannot initiate one. Static mode on does not provide that negotiation check.

The member ports need compatible characteristics: speed, duplex and layer-2 trunk settings must agree. Configure the same intended VLAN list and native VLAN on the logical Port-channel as well as consistent member settings. The channel-group number is locally significant, but using 1 on both switches makes this small lab easier to read.

A two-link bundle offers multiple paths for multiple flows; it does not make every single TCP transfer run at the sum of both link speeds. The hashing policy assigns traffic across members to keep a flow's packets ordered. A successful ping proves reachability, not load-balancing fairness or doubled throughput.

Use a separate lab so old STP failure experiments and partially configured bundles cannot obscure your observation. Shut both member ports on both switches, apply the configuration below on each end, then bring the members up on both ends. Check negotiated state before assuming the logical interface is carrying traffic.

! BOTH switches; VLANs/access ports already match lesson 5:
enable
configure terminal
interface range gigabitethernet0/1 - 2
 shutdown
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,999
 switchport nonegotiate
 channel-group 1 mode active
exit
interface port-channel1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,999
exit
end
! After BOTH ends are configured, on BOTH:
configure terminal
interface range gigabitethernet0/1 - 2
 no shutdown
end
show etherchannel summary
show interfaces trunk
show spanning-tree vlan 10
! Where supported:
show lacp neighbor

Run it

Verify both members are bundled before testing same-VLAN pings. On S1 shut Gi0/2 only, inspect the channel summary and repeat the ping. Restore it with no shutdown and verify that it rejoins. Save observations and the working lab; do not erase unrelated switch configurations.

What to expect

The summary should show a layer-2 port-channel in use, commonly Po1(SU), and bundled members commonly marked (P); read your output's legend. After one member is shut, a bundle without a two-member minimum-links policy can remain available through its surviving link. STP displays the logical port-channel. Brief loss can occur during failure handling.

Negotiation predictions:
active + active  -> can form (if other settings match)
active + passive -> can form
passive + passive -> neither initiates; no negotiated bundle

On one end, with members shut:
interface range gigabitethernet0/1 - 2
 no channel-group 1
 channel-group 1 mode active
 no shutdown

Inspect show etherchannel summary and repeat the same-VLAN test.
Static mode on can force an inconsistent configuration into service;
it hides the negotiation failure instead of explaining it.
Checkpoint: describe the surviving capacity after one of two equal
members fails, and why a single flow was not guaranteed both links.

Watch for: A configured Port-channel is not proof that members joined it. Suspended or individual members need investigation of both ends. Match the channel protocol and VLAN settings. Platform member limits, hashing and minimum-links support vary; the legacy Catalyst documentation is a syntax reference for this lab, not a hardware purchasing recommendation.

Lesson references

• Cisco Catalyst 2960-X IOS 15.2(7)E: EtherChannel and LACP; reviewed 14 September 2026 ↗

8. Devices, topologies and the physical path

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

A router chooses between IP networks; an L2 switch learns and forwards within a broadcast domain. An L3 switch can do both. A firewall adds policy and often application awareness; an IPS inspects for harmful traffic. An AP bridges wireless clients to a distribution network, while a controller centralizes selected management/control functions. Servers, clients and PoE-powered phones/cameras impose different power and traffic requirements.

A two-tier campus combines core and distribution; a three-tier design separates them. Spine-leaf designs provide predictable leaf-to-leaf paths through spines. A WAN joins sites through provider services; cloud and on-premises refer to deployment models, not a guarantee of a particular topology. Decide failure domains, capacity, management access and power before drawing boxes.

Copper Ethernet has length, category and electromagnetic constraints. Single-mode and multimode fiber require matching optics, wavelength, fiber and connector arrangements; a connector that fits does not prove compatibility. Full-duplex switched links should not have ordinary collisions. CRC errors, rising discards and duplex mismatches describe different failures: take counter deltas and compare both ends.

show interfaces status
show interfaces GigabitEthernet0/1
show interfaces counters errors
show power inline
! Availability varies by model. Record unsupported commands.

What to expect

Record speed/duplex on both ends, CRC/error deltas, link flaps and PoE budget. Do not replace a cable solely because a lifetime counter is nonzero.

Verify AP power requirements, switch PoE standard/class, per-port and total power budgets, cabling and negotiated power. A data VLAN change cannot provide missing watts. Then check the data path after power is stable.

Watch for: A topology sketch is not a bill of materials. Include optic type, fiber mode, reach, power, spare ports and independent failure paths.

Lesson references

• Upstream reference ↗

9. Transport, ports and packet evidence

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

TCP supplies a reliable ordered byte stream with acknowledgments, sequence numbers, retransmission, flow control and congestion control. UDP supplies datagrams without those TCP mechanisms; applications can implement their own reliability, as QUIC does. “UDP is always faster” is not a troubleshooting conclusion.

A connection is identified by protocol, source/destination addresses and ports. The server usually listens on a known port; a client generally uses an ephemeral source port. A SYN followed by SYN-ACK and ACK establishes ordinary TCP communication. Repeated SYNs without replies suggest loss/filtering/unreachable service, but a capture from one point cannot locate the fault by itself. A reset and a timeout are different observations.

Record client settings on Windows with ipconfig /all, on Linux with ip address/ip route/resolvectl, and on macOS with ifconfig, route -n get default and scutil --dns. Compare the route and DNS actually used by the failing application, especially with VPNs and split DNS.

Wireshark display filters for an authorized lab capture:
tcp.port == 443
tcp.flags.syn == 1
tcp.analysis.retransmission
dns

Linux: ss -lntup
Windows PowerShell: Get-NetTCPConnection
macOS: netstat -an

What to expect

A listening socket is local state; the handshake is evidence of a path. TLS and application authentication happen after TCP establishment and can fail independently.

No. TCP establishment already demonstrates that flow at that moment. Inspect certificate name, trust, time, TLS interception and the intended server. Preserve the successful transport evidence.

Watch for: Captures may contain credentials and personal traffic. Capture only your authorized lab; a NIC offload artifact can look like an invalid checksum.

Lesson references

• Upstream reference ↗

10. VLSM and an address plan you can grow

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

An IPv4 prefix reserves leading network bits. For ordinary broadcast subnets, choose host bits h so 2^h−2 meets the requirement; /31 point-to-point and /32 host routes are exceptions. Allocate the largest block first on a proper boundary, then place smaller ones without overlap. RFC1918 space is 10/8, 172.16/12 and 192.168/16; private addresses are not automatically secure or globally unique between organizations.

Allocate 192.168.50.0/24 for 100, 50 and 20 hosts: .0/25 supplies 126 usable addresses, .128/26 supplies 62, .192/27 supplies 30, and .224/27 remains. Gateways consume addresses too. Reserve documented growth space and keep infrastructure addressing separate from an accidental DHCP choice.

Summarization covers a common binary prefix. It can include unused space, so an aggregate must be paired with correct reachability and loop prevention. Two adjacent /25s on the correct /24 boundary can summarize; arbitrary adjacent-looking decimal ranges may not.

192.168.50.0/25:   hosts .1–.126, broadcast .127
192.168.50.128/26: hosts .129–.190, broadcast .191
192.168.50.192/27: hosts .193–.222, broadcast .223
192.168.50.224/27: reserved

What to expect

Check each network alignment and ensure that no usable address is assigned twice. The first three blocks fit without overlap.

One valid plan: .0/26 (255.255.255.192, .1–.62), .64/27 (.224, .65–.94), .96/28 (.240, .97–.110). .112/28 and .128/25 remain. Document network/broadcast boundaries, not only usable ranges.

Watch for: NAT does not solve overlapping internal address plans cleanly. Consider mergers, VPN peers and cloud networks before choosing common ranges.

Lesson references

• Upstream reference ↗

11. IPv6 addressing, neighbor discovery and host setup

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

IPv6 addresses contain 128 bits. Remove leading zeros in a hextet and compress one run of zero hextets with ::; using :: twice makes the expansion ambiguous. A typical SLAAC LAN uses /64. Global unicast, unique-local and link-local addresses have different scopes. Link-local fe80::/10 addresses require an interface scope when the same destination could exist on more than one link. Multicast replaces broadcast functions; anycast is a unicast address assigned at multiple locations and reached according to routing.

Neighbor Discovery uses ICMPv6, including router/neighbor solicitations and advertisements. SLAAC learns a prefix and default-router information from RAs; DHCPv6 does not by itself provide the default gateway. Do not block all ICMPv6: ND and path-MTU discovery need it. Modified EUI-64 flips the universal/local bit and inserts fffe in a 48-bit MAC-derived identifier; modern hosts often use other privacy/stable-address methods.

! Two routers directly connected on G0/0; lab documentation prefix:
! R1
configure terminal
ipv6 unicast-routing
interface g0/0
 ipv6 address 2001:db8:12::1/64
 no shutdown
end
! R2: same setup, address 2001:db8:12::2/64
show ipv6 interface brief
show ipv6 neighbors
ping 2001:db8:12::2

What to expect

Both interfaces should be up/up with global documentation-prefix and link-local addresses. A successful neighbor entry and ping demonstrate this local link, not Internet IPv6 service.

2001:0db8:0010:0000:0000:0000:0000:0025. The same link-local address can occur on different links, so identify the outgoing interface/zone.

Watch for: 2001:db8::/32 is documentation space. A missing RA is not repaired simply by adding a DHCPv6 address.

Lesson references

• Upstream reference ↗

12. Build the routed lab and route between VLANs

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Use two 2960 switches S1/S2 from the earlier VLAN labs and three 2911 routers R1/R2/R3. Save a separate file. R1 G0/0 connects to a static trunk on S1 G0/2; allow VLANs 10,20,999 and make 999 the native VLAN at both ends. VLAN 10 and 20 carry 192.168.10.0/24 and 192.168.20.0/24. The PCs use .1 as their gateway.

Router subinterfaces associate 802.1Q tags with L3 interfaces. A switch virtual interface on an L3 switch is another architecture; merely creating an SVI on an L2-only switch does not provide inter-VLAN routing. Voice VLAN configuration can put a phone and attached PC into distinct VLANs on one access port; the phone’s tagging and QoS policy must match the switch design.

For subsequent routing labs connect R1 G0/1 10.0.12.1/30 to R2 G0/0 10.0.12.2/30, and R2 G0/1 10.0.23.1/30 to R3 G0/1 10.0.23.2/30. R3 G0/0 is 10.30.0.1/24, with a PC at 10.30.0.10/24 and gateway 10.30.0.1. Configure those addresses and no shutdown on both ends.

! R1
configure terminal
interface g0/0
 no shutdown
interface g0/0.10
 encapsulation dot1Q 10
 ip address 192.168.10.1 255.255.255.0
interface g0/0.20
 encapsulation dot1Q 20
 ip address 192.168.20.1 255.255.255.0
interface g0/0.999
 encapsulation dot1Q 999 native
interface g0/1
 ip address 10.0.12.1 255.255.255.252
 no shutdown
end
show ip interface brief
show ip route connected

What to expect

VLAN-10 and VLAN-20 hosts can now communicate through R1 if access membership, trunk, addresses and gateways are correct. R3 LAN connectivity needs routes in a later lesson.

VLAN-20 frames cannot traverse that trunk to the router, while VLAN 10 can still work. show interfaces trunk reveals the missing VLAN; restore the allowed list and retest the VLAN-20 gateway.

Watch for: An ACL is not needed to cause this failure. Confirm L2 carriage and gateway reachability before investigating inter-site routing.

Lesson references

• Upstream reference ↗

13. Discovery, STP protections and routed EtherChannel

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

CDP and LLDP advertise neighboring-device information on a link. They help confirm cable endpoints, platform identity and interface relationships, but they are not a routing protocol or proof of the intended topology. Disable disclosure on untrusted edges where policy requires it.

Rapid PVST+ runs a spanning-tree instance per VLAN. Root election uses bridge ID; port roles and cost choose forwarding paths. PortFast is for appropriate edge ports and bypasses normal initial listening/learning delay; it does not disable spanning tree. BPDU guard can err-disable an edge port receiving a BPDU. Root guard prevents an unexpected superior root on a designated boundary; loop guard helps keep a port from forwarding after expected BPDUs disappear. BPDU filtering can remove protection and create a loop if misused.

A Layer-3 EtherChannel uses routed members and an IP address on the logical port-channel, supported on suitable L3 devices. Members must agree on mode and key parameters. LACP bundles are not guaranteed to make one flow run at the sum of member speeds.

show cdp neighbors detail
show lldp neighbors detail
show spanning-tree vlan 10
show etherchannel summary

! Only on a dedicated PC-facing access port:
configure terminal
interface fa0/3
 switchport mode access
 spanning-tree portfast
 spanning-tree bpduguard enable
end
! Routed LACP on two matching L3 lab switches:
! interface range g1/0/1-2
!  no switchport
!  channel-group 2 mode active
! interface port-channel 2
!  no switchport
!  ip address 10.0.34.1 255.255.255.252
! Peer uses 10.0.34.2/30; verify model/interface support.

What to expect

Neighbors should match your cabling record; edge BPDU guard intentionally stops a port receiving an unexpected BPDU. Routed members belong to one L3 logical interface.

No. Establish whether the downstream switch is authorized, remove the cause or redesign the port intentionally, then recover under the platform procedure. The event is evidence of a policy boundary being crossed.

Watch for: Do not put PortFast/BPDU filter on every trunk to make links come up faster. Protection roles depend on the topology.

Lesson references

• Upstream reference ↗

14. Read a routing table and predict forwarding

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

For a packet, forwarding selects the longest matching installed prefix. Administrative distance selects between sources of a route to the same prefix; protocol metrics compare paths according to that protocol. Do not compare a /24’s AD against a /16’s AD to decide which prefix matches an individual packet. Connected, local, static and OSPF codes describe different route sources. A default /0 is the least-specific match, not a promise that a return route exists.

The routing table describes reachable prefixes and next hops; recursive resolution must still identify an outgoing adjacency. Ethernet delivery then requires ARP/ND. A route can look correct while the next-hop path is broken. Separate control-plane route selection from data-plane forwarding and policy.

S 10.20.0.0/16 [1/0] via 10.0.12.2
O 10.20.30.0/24 [110/20] via 10.0.12.6
S* 0.0.0.0/0 [1/0] via 10.0.12.10

! Inspection commands:
show ip route
show ip route 10.20.30.7
show ip arp

What to expect

10.20.30.7 matches the OSPF /24, despite its higher AD. 10.20.40.7 matches the static /16. A destination outside both matches /0.

The /32, because it is more specific. A different host in 10.20.30.0/24 still follows the /24. AD did not override longest-prefix forwarding.

Watch for: A lower metric in one protocol is not directly comparable with a metric in another. A route printed here is a teaching fixture, not live router output.

Lesson references

• Upstream reference ↗

15. Static IPv4/IPv6 and floating routes

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Use the three-router topology from the inter-VLAN lesson. A remote network needs a route on every forwarding router and a return path. A network route covers a subnet, a host route one address, and a default covers otherwise unmatched destinations. A floating static route has a less-preferred AD than the primary route to that same prefix; it is installed when the preferred route disappears, not necessarily when a remote application stops responding.

For Ethernet next hops, a fully specified static can identify both interface and next-hop address where supported. IPv6 link-local next hops require an interface. Do not confuse “interface up” with usable end-to-end reachability. Track-based failover requires additional mechanisms beyond the basic floating static pattern.

! R1:
ip route 10.30.0.0 255.255.255.0 10.0.12.2
! R2:
ip route 192.168.10.0 255.255.255.0 10.0.12.1
ip route 192.168.20.0 255.255.255.0 10.0.12.1
ip route 10.30.0.0 255.255.255.0 10.0.23.2
! R3:
ip route 192.168.10.0 255.255.255.0 10.0.23.1
ip route 192.168.20.0 255.255.255.0 10.0.23.1

! Separate IPv6 two-router lab, after configuring the remote loopback:
! ipv6 route 2001:db8:30::/64 2001:db8:12::2
! ipv6 route ::/0 GigabitEthernet0/0 fe80::2 200
show ip route static
show ipv6 route static

What to expect

A PC in VLAN 10 should reach 10.30.0.10 and receive replies once all five static directions and interfaces exist. Verify with source-specific ping and traceroute.

Replies to VLAN 10 lack the specific return route (unless another route such as a default covers it); VLAN 20 can still work. Restore the deleted route and verify both directions.

Watch for: Do not retain these AD-1 statics while expecting OSPF routes to the same prefixes to appear later. Remove them in the OSPF copy of the lab.

Lesson references

• Upstream reference ↗

16. Single-area OSPF: establish and verify

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Copy the routed lab and remove its static inter-LAN routes. OSPFv2 advertises IPv4 reachability within the area and runs a shortest-path calculation using cost. The process ID is locally significant; area IDs and compatible interface parameters matter for neighbors. Give each router a unique stable router ID. Passive interfaces advertise attached networks without forming adjacencies toward PCs.

Use interface-based OSPF activation for clarity. On R1/R2 link interfaces choose point-to-point OSPF network type on both ends; broadcast Ethernet defaults are explored next. Neighbor states and the link-state database explain whether the control plane converged. A FULL neighbor does not prove an ACL allows an application.

! R1 (configure mode):
router ospf 10
 router-id 1.1.1.1
 passive-interface default
 no passive-interface g0/1
interface g0/1
 ip ospf 10 area 0
 ip ospf network point-to-point
interface g0/0.10
 ip ospf 10 area 0
interface g0/0.20
 ip ospf 10 area 0
! R2: unique router-id 2.2.2.2; activate both routed links,
! un-passive both, set point-to-point on both.
! R3: router-id 3.3.3.3; activate G0/1 point-to-point,
! advertise G0/0 passively. All in area 0.
end
show ip ospf neighbor
show ip ospf interface brief
show ip route ospf

What to expect

Each point-to-point pair should reach FULL after convergence. R1 learns 10.30.0.0/24 and R3 learns both VLAN subnets. Inspect next hops, costs and actual ping/traceroute results.

The R1–R2 OSPF adjacency fails and interface/OSPF diagnostics show an area mismatch. A PC gateway error does not change router-to-router OSPF area settings or prevent their adjacency. Restore area 0.

Watch for: Check area, subnet, timers, authentication, MTU and passive status systematically. Avoid changing several parameters at once.

Lesson references

• Upstream reference ↗

17. Broadcast OSPF, costs and first-hop redundancy

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

On a broadcast multiaccess segment, OSPF elects a designated router and backup designated router. Interface priority and router ID participate; priority zero makes a router ineligible. Existing DR/BDR elections are not simply preempted when a higher-priority newcomer arrives. DROther routers commonly remain 2-WAY with each other while becoming FULL with DR/BDR, so 2-WAY is not universally a fault.

OSPF cost is additive along a path and can depend on configured reference bandwidth. Keep assumptions consistent across routers. First-hop redundancy solves a different problem: hosts use a virtual gateway address while multiple routers coordinate its service. HSRP, VRRP and GLBP have different mechanics; CCNA requires the purpose and concepts, not assuming every implementation is identical.

Build a separate three-router Ethernet segment on a switch to observe DR/BDR. Do not reuse point-to-point network-type commands there. Keep packet captures or show-output snapshots from before and after removing the DR.

show ip ospf interface g0/0
show ip ospf neighbor
! On the separate broadcast segment, in interface config:
ip ospf priority 0
! This makes that interface ineligible for DR/BDR.

! First-hop design fixture:
! Gateway A 192.168.60.2/24
! Gateway B 192.168.60.3/24
! Virtual gateway 192.168.60.1/24 (host default gateway)

What to expect

On the broadcast lab, identify DR, BDR and DROther roles from actual output. A gateway redundancy design preserves a host’s configured virtual next hop during a supported failover.

No. The host must use the virtual gateway for that mechanism’s benefit. Routing beyond the gateway and upstream tracking also affect whether the surviving path is useful.

Watch for: A working OSPF neighbor and a working default-gateway redundancy group solve different failures. Do not infer one from the other.

Lesson references

• Upstream reference ↗

18. DHCP, relay and DNS as separate services

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

DHCPv4 normally uses discover, offer, request and acknowledgment, with UDP server/client ports 67/68. A relay forwards requests between a client broadcast domain and a remote server, adding information used to choose the correct scope. A DHCP client on a router interface is different from configuring a DHCP server or relay. Exclude infrastructure addresses and supply the correct default gateway and resolver.

DNS separates recursive resolution from authoritative data. A/AAAA are address records; CNAME aliases another name; MX and other record types have different purposes. Caching and TTLs mean a corrected authoritative value may not appear immediately at every resolver. A hostname resolving correctly does not prove the service is listening.

Use a Packet Tracer server in 10.30.0.0/24 at .53 with gateway .1. Configure a DHCP pool for VLAN 10 on that server: network 192.168.10.0/24, gateway .1, DNS 10.30.0.53, start .100. Ensure routing works before adding the relay.

! R1 on VLAN 10 interface:
configure terminal
interface g0/0.10
 ip helper-address 10.30.0.53
end
! A separate uplink DHCP-client example:
! interface g0/0
!  ip address dhcp

! Client checks:
ipconfig /all
nslookup lab.example 10.30.0.53

What to expect

A VLAN-10 client obtains an address from the intended pool with its correct gateway. Configure an A record for lab.example on the lab DNS server and verify both name and direct-address service reachability.

Check the client’s actual resolver, the server’s DNS service/zone/record, and whether UDP/TCP DNS traffic is permitted. DHCP and ICMP success do not prove DNS correctness.

Watch for: Some helper implementations relay more than DHCP. Review the platform’s forwarded UDP services; do not expose management networks accidentally.

Lesson references

• Upstream reference ↗

19. Static NAT, pools and overload

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Inside-source NAT changes a source address when traffic crosses the configured inside/outside boundary; return translations reverse the mapping. Static NAT is a fixed one-to-one mapping. A dynamic pool lends addresses to inside hosts; PAT/overload can share an outside address by distinguishing transport ports. NAT is not a substitute for a security policy or a return route.

Use a separate edge lab. Inside is 192.168.10.0/24; outside R1 G0/1 is 198.51.100.1/24 and the simulated ISP is .254. Both are documentation addresses. The ISP must route any translated pool back toward R1; a simulated server can be 203.0.113.10/24 behind the ISP. First prove routing without confusing a failed NAT policy with a missing ISP route.

! Edge R1 configuration; choose ONE dynamic method:
access-list 10 permit 192.168.10.0 0.0.0.255
interface g0/0
 ip nat inside
interface g0/1
 ip nat outside
ip route 0.0.0.0 0.0.0.0 198.51.100.254
! PAT:
ip nat inside source list 10 interface g0/1 overload
! Alternative pool, after removing the PAT statement:
! ip nat pool LAB 198.51.100.100 198.51.100.109 netmask 255.255.255.0
! ip nat inside source list 10 pool LAB
! Separate fixed mapping example:
! ip nat inside source static 192.168.10.50 198.51.100.50
show ip nat translations
show ip nat statistics

What to expect

Generate traffic before looking for dynamic translations. Compare inside-local and inside-global fields; inspect translation hits and return traffic. A static mapping can appear even without an active session.

Without overload, distinct inside hosts can consume one pool address each. Port multiplexing is a separate choice. Inspect active translations and timeouts rather than assuming connection count equals available addresses.

Watch for: The NAT selection ACL is not automatically an interface filtering ACL. Label each ACL’s purpose.

Lesson references

• Upstream reference ↗

20. NTP, syslog, SNMP and transfer protocols

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

NTP aligns device clocks so events can be correlated. A configured server is not necessarily a synchronized peer; inspect associations and reachability. In an isolated exercise an NTP master can supply lab time, but its local clock is not an authoritative real-world source. Syslog severity runs from 0 (emergency) to 7 (debug); a configured threshold includes that level and numerically lower, more severe levels. Facilities classify message sources.

SNMP can poll counters and receive traps/informs. Prefer appropriately configured SNMPv3 authentication/privacy rather than assuming a community string encrypts anything. Monitor deltas and counter widths. Collect link state, errors, utilization, CPU/memory, routing neighbors and environmental state in context.

TFTP has no built-in authentication or encryption; FTP can expose credentials and data unless a secure variant is deliberately used. Prefer secure transfer appropriate to the platform. Back up configurations and test restoration in a lab, while excluding secrets from public examples.

! Isolated R2 lab time source:
ntp master 5
! R1 client:
ntp server 10.0.12.2
service timestamps log datetime msec
logging host 10.30.0.53
logging trap warnings
show ntp associations
show ntp status
show logging
show snmp

What to expect

After convergence, NTP status should show synchronization to the intended lab source. The warnings threshold admits severity 0–4, not informational/debug messages.

Clock synchronization, timezones, timestamp precision, buffering and log transport delay. Correlation depends on comparable time, not the order messages happened to arrive at a collector.

Watch for: Do not put a production switch into ntp master merely to make “synchronized” appear. An accurate hierarchy and authenticated trusted peers matter.

Lesson references

• Upstream reference ↗

21. QoS: classify, mark, queue and measure

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

QoS manages treatment when resources contend. Classification identifies traffic; marking writes an agreed label; queuing decides which waiting packets are served; shaping buffers/delays to a rate, while policing typically drops or remarks excess. Congestion avoidance is different from scheduling. DSCP markings describe intended per-hop treatment but require devices and trust boundaries to honor policy.

A priority queue can protect delay-sensitive traffic, but an unbounded priority class can starve other traffic. Voice bandwidth includes packet headers and encapsulation, not only codec payload. A 1-Gbit access link does not prevent a downstream 50-Mbit bottleneck.

Start with a measured path and explicit service requirements: acceptable delay, jitter, loss and throughput. Classify on evidence, set a trust boundary, apply an appropriate policy where congestion occurs, and verify class counters and user experience. Exact policy syntax is platform-specific; do not transplant a campus-switch command into an unrelated WAN router.

show policy-map interface
show interfaces g0/1

Teaching calculation:
50 Mbit/s link × 0.20 reserved share = 10 Mbit/s
10,000,000 bit/s ÷ 100,000 bit/s per modeled call = 100 calls
(The per-call figure is an explicit exercise assumption.)

What to expect

The arithmetic gives a capacity estimate under the model, not a real call-admission guarantee. Verify packet overhead, burst behavior and the actual service policy.

It removes useful classification and can overload the priority treatment. Traffic classes and admission limits must distinguish the workload they are protecting.

Watch for: A traffic mark does not create bandwidth. Observe queue drops, jitter and the true bottleneck.

Lesson references

• Upstream reference ↗

22. Secure management, local access and AAA

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Management is its own plane: use authorized administrators, restricted source networks, encrypted sessions, strong unique credentials and recoverable out-of-band access. Console access can help when the network path fails. Telnet and ordinary HTTP expose content; prefer SSH/HTTPS where supported. Certificates, MFA and hardware-backed credentials solve different identity risks from password complexity alone.

Authentication establishes identity, authorization governs permitted actions and accounting records activity. RADIUS is commonly used for network access; TACACS+ is commonly used for device administration with separate authorization/accounting capabilities. Behavior depends on policy and platform. A central AAA outage requires a deliberately tested fallback, not a surprise blanket bypass.

Threat is a possible harmful event/actor, vulnerability a weakness, exploit a method using it and mitigation a risk-reducing control. Training, physical access, inventory, patching and incident response support the command configuration. Do not test remote-access changes without a recovery path.

! Dedicated lab router; substitute a unique lab-only secret:
configure terminal
hostname R1
ip domain-name lab.example
username labadmin privilege 15 secret ReplaceWithUniqueLabSecret
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 login local
 transport input ssh
 exec-timeout 5 0
end
show ip ssh
show users

What to expect

SSH works from the authorized lab client with the local account; Telnet should no longer be accepted on those VTY lines. Confirm all available VTY ranges on the chosen platform.

A wrong source prefix, direction or AAA policy can lock administrators out. Preserve recovery access, verify a new session and then complete the change.

Watch for: service password-encryption is not strong encryption of all stored secrets. Secret hashing and platform capabilities differ.

Lesson references

• Upstream reference ↗

23. Standard and extended ACLs: predict before applying

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

An ACL is evaluated top to bottom and normally stops at the first match. An implicit deny follows the explicit entries. A standard IPv4 ACL mainly matches source; an extended ACL can match protocol, source/destination and ports. Wildcard bits of 0 must match, and bits of 1 are ignored. Direction is relative to the interface: inbound traffic enters the router there, outbound traffic leaves it.

Stateful firewalls track flows; an ordinary stateless ACL does not become stateful because it permits TCP established. Placement depends on the purpose and topology. Extended filters often work near the source to avoid carrying unwanted traffic, but management, asymmetric paths and operational constraints matter.

In the isolated routed lab, permit VLAN-10 clients to the lab server 10.30.0.53 only for DNS and HTTPS, while keeping an explicit final deny. Apply inbound on R1 G0/0.10. The policy intentionally blocks other VLAN-10 traffic, including ping; validate it with the intended application tests and counters.

ip access-list extended V10-SERVICES
 permit udp 192.168.10.0 0.0.0.255 host 10.30.0.53 eq 53
 permit tcp 192.168.10.0 0.0.0.255 host 10.30.0.53 eq 53
 permit tcp 192.168.10.0 0.0.0.255 host 10.30.0.53 eq 443
 deny ip any any log
interface g0/0.10
 ip access-group V10-SERVICES in
end
show access-lists V10-SERVICES
show ip interface g0/0.10

What to expect

DNS and HTTPS to that server can pass when the services and return route exist. ICMP fails by design. Counters identify the matched rule; empty counters can mean the test never crossed this interface.

The earlier permit matches first. Move or narrow rules according to the intended policy, then retest both allowed and denied traffic.

Watch for: Do not paste this intentionally restrictive lab ACL into a real user VLAN. DHCP relay, infrastructure access and return traffic need a complete production policy.

Lesson references

• Upstream reference ↗

24. DHCP snooping, ARP inspection and port security

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

DHCP snooping classifies trusted paths to legitimate servers and learns address bindings on untrusted client ports. Dynamic ARP Inspection can validate ARP against that binding database and configured policy. Static hosts may require explicit bindings/ARP ACL handling; enabling DAI without a complete design can break valid traffic. Port security limits permitted source MAC behavior and has violation modes such as protect, restrict and shutdown.

Trust the actual server/uplink path, not every trunk indiscriminately. A downstream switch with a rogue server can still be an attack path. Rate limits, persistence of bindings across reload and recovery procedures require platform-specific planning. A phone-plus-PC port needs a different MAC limit than a single directly connected PC.

Use a separate L2 lab with DHCP server reached via G0/1 and clients on access ports. Verify binding formation first, then add inspection. Keep console access and record a known-good lease before intentionally testing a rogue DHCP response.

ip dhcp snooping
ip dhcp snooping vlan 10
interface g0/1
 ip dhcp snooping trust
 ip arp inspection trust
exit
ip arp inspection vlan 10
interface fa0/3
 switchport mode access
 switchport access vlan 10
 switchport port-security
 switchport port-security maximum 1
 switchport port-security violation restrict
end
show ip dhcp snooping binding
show ip arp inspection statistics
show port-security interface fa0/3

What to expect

The legitimate leased host has a binding. Unauthorized server replies on untrusted ports and invalid ARP should be rejected according to policy. Exact simulator support varies; unsupported commands are not successful tests.

Its ARP may not have a DHCP snooping binding or approved static policy. Inspect drops and add the appropriate authorized static treatment; do not disable inspection globally without investigating.

Watch for: Restoring an err-disabled port without removing the cause can repeat the failure. Keep recovery intentional.

Lesson references

• Upstream reference ↗

25. Wireless RF, channels and security choices

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

An SSID names a wireless network, not a unique AP. Multiple APs can advertise the same SSID with different BSSIDs. RF coverage and capacity depend on channel width, power, interference, client capabilities, building materials and contention. Wider channels trade channel reuse for peak per-client capacity; transmit power alone cannot overcome a weak client return path.

In 2.4 GHz, a common 20-MHz reuse plan in regulatory domains such as the US is channels 1, 6 and 11. Channel availability and nonoverlap assumptions depend on local rules and width. 5/6-GHz planning and DFS requirements need the actual regulatory domain. Encryption and authentication are separate choices: WPA2-Personal uses a shared secret, Enterprise uses 802.1X/EAP with an authentication service, and WPA3 changes important authentication/security requirements. Avoid legacy WEP/TKIP.

Measure coverage, SNR, utilization, retries and roaming behavior rather than treating “full bars” as proof of good service. A client may associate successfully but fail DHCP, DNS or policy.

Record for each lab AP/client:
SSID / BSSID / band / channel / width
RSSI / SNR / retry rate / client count
Authentication / encryption / VLAN mapping
DHCP result / DNS result / application result

What to expect

The record separates radio association from IP configuration and application success. A busy channel can perform poorly even with strong signal.

Try a channel/reuse plan and narrower widths appropriate to the regulatory domain and capacity need. Measure contention/retries and client experience before and after.

Watch for: Do not treat channels 1/6/11 as a universal rule for every band or country.

Lesson references

• Upstream reference ↗

26. AP architecture and a WLAN configuration lab

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Autonomous APs, controller-based lightweight APs, cloud management and distributed designs place control/forwarding functions differently. Local-mode APs commonly tunnel client traffic toward a controller; FlexConnect can provide local switching depending on configuration. Monitor/sniffer/rogue-detection modes serve specialized roles and do not all accept ordinary clients. CAPWAP control and data paths must be permitted in the selected architecture.

In Packet Tracer, use a supported WLC and lightweight AP, a management VLAN with DHCP, a wired server and a wireless laptop. Establish AP discovery/join before diagnosing a WLAN. Controller management, AP management and client VLANs have separate purposes. Controller uplinks, port channels and trunks must match the intended design.

In the available WLC GUI, create an enabled WLAN with SSID AUWEN-LAB, associate the intended client interface/VLAN, choose WPA2-Personal/PSK with AES, enter a unique lab-only secret and apply changes. Set a matching wireless client profile. Screens differ by WLC generation; record the actual model and field names instead of pretending one screenshot is universal.

Lab verification sequence:
1. AP has management address and joined the WLC.
2. WLAN is enabled; SSID and interface/VLAN mapping are correct.
3. Client uses matching WPA2-PSK/AES settings.
4. Client receives the intended address, gateway and DNS.
5. Client reaches a wired lab application.
6. Review QoS profile and advanced settings without guessing defaults.

What to expect

Association, security negotiation, DHCP and application reachability must each succeed. Capture your actual GUI configuration and a working client result.

Wrong PSK prevents successful security authentication. Wrong VLAN can allow association but prevent the expected IP lease/reachability. Inspect the stage that failed rather than restarting everything.

Watch for: This is a GUI task for an actual simulator/controller. Reading the steps alone does not satisfy a configure-and-verify objective.

Lesson references

• Upstream reference ↗

27. VPNs, VRFs, containers and cloud boundaries

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

A VRF separates routing tables on a device; it does not automatically encrypt traffic. A VLAN separates L2 broadcast domains; a VRF can contain multiple routed interfaces/VLANs. A VM has a virtualized hardware environment and its own guest OS; containers share a host kernel while isolating processes and namespaces. Hypervisors, vSwitches and container bridges still need addressing, routing and policy.

A site-to-site IPsec VPN joins network security domains; remote-access VPNs connect individual clients under authentication and authorization policy. IPsec uses security associations and cryptographic negotiation, commonly via IKE. A tunnel can be up while traffic selectors, routes, NAT exemption, MTU or policy prevent an application. Encryption alone does not authorize all connected networks.

Cloud route tables, security groups, network ACLs and load balancers add distinct control points. Document which component owns each policy and whether rules are stateful. Hybrid networks must consider overlap, DNS split views, asymmetric paths and identity.

Design exercise (no real tunnel is created):
Branch LAN 10.10.0.0/24
HQ LAN 10.20.0.0/24
Encrypted traffic policy: branch to HQ approved services
Management VRF: independent administrative routes
Test: selector match, routes both ways, allowed ports, MTU, DNS

What to expect

A complete diagram labels underlay reachability, encrypted overlay, selectors, identities and routing domains. “VPN connected” is only one checkpoint.

The overlapping destinations are ambiguous to hosts/routers. Renumbering, carefully designed translation or separated routing domains may be needed; each affects DNS, policies and operations.

Watch for: A VRF is isolation, not cryptography. A cloud security group is not automatically equivalent to a stateless router ACL.

Lesson references

• Upstream reference ↗

28. Controllers, APIs and structured state

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

The data plane forwards traffic; the control plane determines paths and policy; the management plane configures and observes. Controller-based networking can centralize selected decisions without moving every packet through one server. An underlay provides transport; overlays create logical connectivity on top; a fabric coordinates a wider system. Northbound APIs expose intent/state to applications, while southbound interfaces interact with devices.

REST-style APIs use resources, HTTP methods, status codes and representations. GET reads, POST commonly creates/actions, PUT replaces, PATCH partially updates and DELETE removes, but exact semantics come from the API. Authentication, authorization, TLS, timeouts, pagination and rate limits are part of correctness. A successful HTTP status does not guarantee the requested network state converged.

JSON distinguishes objects, arrays, strings, numbers, booleans and null. Parse it as data rather than splitting lines. Validate schema and compare intended state to observed state before making changes.

import json
payload = '{"interfaces":[{"name":"Gi0/1","enabled":true,"mtu":1500}]}'
data = json.loads(payload)
port = data["interfaces"][0]
assert isinstance(port["enabled"], bool)
assert port["mtu"] == 1500
print(port["name"], port["enabled"])

What to expect

Python prints Gi0/1 True. No network request or configuration change occurs in this fixture.

data["interfaces"].append({"name":"Gi0/2","enabled":False,"mtu":1500})
print(sum(1 for p in data["interfaces"] if p["enabled"] is True))
# 1. JSON booleans parse to Python bool values.

Watch for: Do not log bearer tokens or accept certificates blindly to make an API request work. A 429 means rate policy, not an invitation to retry in a tight loop.

Lesson references

• Upstream reference ↗

29. Ansible, Terraform and trustworthy automation

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Ansible commonly expresses tasks and configuration through inventories, modules and playbooks; idempotent modules aim to converge state without repeating unnecessary changes. Terraform describes desired resources and tracks state through providers; plans show proposed changes, but state and secrets need protection. Neither tool makes an unsafe intent safe. Back up, validate, stage, compare and provide rollback.

Predictive ML can estimate anomalies or trends from observations; generative systems can draft explanations or configuration. Both can fail because of bad data, distribution changes or plausible but incorrect output. A model-generated command requires validation against the exact platform/version and lab evidence. Never give an assistant unrestricted production write access merely because a draft looks familiar.

A useful automation loop discovers current state, computes a bounded difference, reviews policy constraints, applies to a canary, checks behavior and either expands or rolls back. Keep audit records of who/what changed which version and why.

Change workflow fixture:
Inventory → observed state → desired state → diff
→ syntax/policy check → lab → canary → verification
→ rollout or rollback → audit record

Review question: does “changed: false” prove the application works?

What to expect

No. It reports the automation tool’s change assessment, not end-to-end service health. Pair configuration convergence with actual reachability and policy tests.

Reject it at validation, consult the matching platform reference, test a corrected policy in the lab including denied and allowed paths, and retain recovery access. Do not treat confident prose as device evidence.

Watch for: A Terraform plan can contain sensitive values. Version control and state access need deliberate secret handling.

Lesson references

• Upstream reference ↗

30. Engineering beyond the exam: circuits, changes and incidents

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

A working network needs ownership, addressing, topology, service dependencies, monitoring, backups, support contacts and change history. For a provider circuit record the circuit ID, demarcation, bandwidth/commit, handoff, routing, MTU, SLA, escalation path and test method. Two circuits are not independent if they share a duct, power supply or upstream failure domain.

A change plan states purpose, scope, prechecks, commands or source revision, expected behavior, validation, rollback trigger and recovery path. A maintenance window is not permission to improvise. During an incident, preserve a timeline, identify affected users/services, compare against a baseline, test one hypothesis at a time and communicate what is known versus inferred.

A post-incident review should explain contributing conditions and durable corrective actions, not merely record that a reboot helped. Track capacity trends, configuration drift, software lifecycle and backup restorability. CCNA is a foundation; BGP policy, advanced WANs, data-center fabrics, wireless design and multi-vendor operations require further depth.

Change record template:
Purpose / owner / affected services
Current topology and config revision
Prechecks and recovery access
Change steps
Allowed + denied traffic tests
Rollback trigger / steps / time budget
Monitoring window / result / follow-up

What to expect

The record lets another engineer execute or reverse a bounded change and understand the evidence. It is part of the technical deliverable, not optional paperwork.

MTU/fragmentation, DNS, source NAT/public-IP allowlists, asymmetric routing, security policy, VPN selectors, bandwidth and application sessions. Test the real services under a controlled failover.

Watch for: Do not equate link-up, BGP-up or successful ICMP with business-service availability.

Lesson references

• Upstream reference ↗

31. Engineering beyond the exam: BGP, MTU and failure domains

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

BGP exchanges reachability with policy between autonomous systems and within large networks. Unlike simply choosing the shortest physical path, operators influence advertisement, acceptance and preference. Prefix filters, maximum-prefix limits, origin validation and clear transit/peering policy protect against leaks. This is a design introduction; production BGP configuration needs provider requirements and a separate tested lab.

MTU is the largest link-layer payload supported on a segment; encapsulation consumes space. IPv4 may fragment when permitted, while IPv6 routers do not fragment transit packets. Path-MTU discovery depends on usable feedback. A small ping can pass while large packets stall. MSS adjustment affects TCP segments and does not fix every UDP or encapsulation problem.

Resilience requires independent failure domains, observable failover and a tested recovery time. Add redundant power, diverse paths and failure detection only where their combined behavior is understood. Measure convergence and application recovery; a control-plane event can be brief while sessions take much longer to recover.

MTU model:
Underlay IP MTU 1500 bytes
Illustrative encapsulation overhead 60 bytes
Available inner packet budget = 1440 bytes
(Use the exact protocol stack to calculate real overhead.)

What to expect

The model shows why copying an underlay MTU into an overlay can exceed the budget. It is not a universal VPN overhead value.

They may share physical routes, facilities, power or upstream dependencies. Small packets fit below the limiting MTU; use controlled size/DF tests and captures appropriate to the platform to investigate larger traffic.

Watch for: Never announce a real public prefix in a casual lab. Use isolated emulation and documentation/private addressing.

Lesson references

• Upstream reference ↗

32. Capstone: build, break, explain and recover

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Return to the three-router/two-switch lab. Deliver a network in which VLANs 10 and 20 span the switches, inter-VLAN routing occurs on R1, OSPF area 0 carries the remote LAN, DHCP relay supplies VLAN-10 clients, DNS resolves a lab service and SSH management is restricted to an explicitly chosen administrative host/subnet. Keep a separate copy for edge NAT and a separate WLC lab; not every simulator model supports every feature in one topology.

Before each fault save a known-good file and prediction. Inject exactly one fault: wrong access VLAN, missing allowed VLAN, mismatched native VLAN, disabled LACP member, duplicate OSPF router ID, area mismatch, missing advertised network, incorrect DHCP scope gateway, reversed ACL direction or failed DNS record. Capture symptoms and decisive evidence, repair only the cause, and repeat the original acceptance test.

An independent checkpoint is an unfamiliar variation: different subnets/interface names and a fault selected by another person. Explain the packet path, not just the command that happened to fix it. Keep the failed prediction when you were wrong; it is useful evidence for the next study session.

Acceptance record per test:
Source → destination / protocol / expected permit or deny
Observed result / timestamp / device outputs
Hypothesis / one changed variable / result
Restored baseline / reason the repair is sufficient

What to expect

A completed submission includes topology, address plan, sanitized configurations, successful and intentionally denied tests, fault reports and recovery instructions. Unsupported simulator features remain explicitly untested.

Inspect lease/gateway/DNS; confirm access VLAN and trunk; reach local gateway; inspect forward and return routes; check ACL counters/direction; test destination port and name separately. Use observations to narrow the next test. Do not reset all devices.

Watch for: A memorized command list is not proof of independent diagnosis. Use a changed topology and explain why competing hypotheses were rejected.

Lesson references

• Upstream reference ↗

33. Exam readiness and the next engineering depth

Before this lesson: Complete lessons 1–7, then the preceding lessons in this extension. Use only the isolated lab described here.

Use the published coverage map to identify every objective in the current CCNA v1.1 blueprint. For “explain/describe/compare,” explain the concept with a counterexample. For “configure/verify,” produce a working lab from a blank or unfamiliar state and show the evidence. For “interpret,” work from unseen routing, interface, ACL, WLAN or JSON output. A chapter being published is not the same as the learner passing its checkpoint.

Current exam baseline was checked on 15 September 2026: Cisco states v1.1 testing ends 2 February 2027 and v2.0 begins 3 February 2027. The v2.0 landing page did not expose its full objective list in this review, so this course does not claim a completed v2.0 mapping. Recheck the official version before booking.

Use timed mixed practice from legitimate sources, record errors by concept and return to the relevant lab. Cisco does not publish a universal promise that one practice score guarantees a pass. Certification readiness also includes pacing and reading the question precisely. Beyond the exam, build deeper labs for BGP, enterprise wireless, IPv6 operations, observability, automation testing, security architecture and multi-vendor failure recovery.

Self-check:
Can I subnet and choose routes without guessing?
Can I configure then prove L2/L3/services/security behavior?
Can I explain output I have not memorized?
Can I identify a symptom that contradicts my first hypothesis?
Can another engineer reproduce and reverse my work?

What to expect

All configure-and-verify objectives need actual lab evidence. Reading-only or unsupported features stay open on your readiness checklist. This course cannot guarantee an exam result.

Return to neighbor formation and the capstone, diagnose an unfamiliar variant and explain the evidence. Repeated-question recognition is insufficient evidence of transferable skill.

Watch for: No exam dumps or recalled live exam items are included. The exercises are original teaching scenarios.

Lesson references

• Upstream reference ↗