clifford.network / toolbox

free labs

Practice Labs

Twenty-nine labs covering the work a network team does every week, from VLANs, trunks and port forwarding to OSPF stub areas, PPPoE, QoS on a sub-rate WAN, two-way redistribution, GRE, HSRP with spanning tree, a dual-hub DMVPN, a Nexus vPC pair, three capstone builds that join it all up, and seven break-fix tickets. Each has the topology, the addressing, the tasks, the checks that prove it works, and the full solution. Then you break it on purpose, because that is where the learning is. Every ticket ends the way real ones do: you write the update, and the page checks it.

How to use them

Any simulator

Built for Cisco Packet Tracer 8 with 2911 routers, 2960-24TT switches and a 3560-24PS. They also run in CML, GNS3 or EVE-NG with interface names changed. The BGP ticket, the DMVPN, redistribution and vPC labs need one of those, and say so.

Try before you look

Work from the tasks and the addressing table. Open the solution only to compare.

Prove it

A lab is done when every check matches, not when the ping works once.

Then break it

Each lab ends with faults to inject. They are the faults that turn up on real changes.

Then write it up

Fixing it is half the job. The tickets end with a closure note, checked in your browser for the things a manager needs to read.

All 29 labs at a glance

What each lab covers, the tasks and the checks that prove it works. Pick a lab in the list above for the topology, the addressing table and the full solution.

VLANs and an 802.1Q trunk

Foundation · about 30 minutes

Every campus change starts here. Most trunk outages come from an allowed list typed without "add", or a native VLAN that does not match at both ends.

Kit: Two 2960-24TT switches and four PCs.

Tasks

  1. Create VLAN 10 STAFF, VLAN 20 GUEST and VLAN 999 NATIVE-UNUSED on both switches.
  2. Make Fa0/1 an access port in VLAN 10 and Fa0/2 an access port in VLAN 20 on each switch, with PortFast.
  3. Make Gi0/1 a static trunk with DTP off, native VLAN 999 and only VLANs 10, 20 and 999 allowed.
  4. Prove that PC1 reaches PC3 and that PC1 cannot reach PC2.

Checks

  • show vlan brief: VLAN 10 lists Fa0/1, VLAN 20 lists Fa0/2. Gi0/1 is not listed: trunks never appear here.
  • show interfaces trunk: Gi0/1 mode on, encapsulation 802.1q, native vlan 999, and 10,20,999 in all three VLAN lists.
  • ping 192.168.10.12 (from PC1): Replies. Same VLAN across the trunk.
  • ping 192.168.20.11 (from PC1): Fails. Different VLAN and no router yet; that is the next lab.

Then break it

  • On SW1 Gi0/1, type "switchport trunk allowed vlan 30". PC1 can no longer reach PC3, and PC2 loses PC4.
  • Change the native VLAN on SW2 Gi0/1 to 1. CDP logs a native VLAN mismatch on both switches. Tagged VLANs keep working, which is why this one hides.

Router-on-a-stick between two VLANs

Foundation · about 30 minutes

Still the quickest way to route a couple of VLANs at a small site, and the cleanest way to see what 802.1Q tagging actually does.

Kit: One 2911 router, one 2960-24TT switch and two PCs.

Tasks

  1. Build VLANs 10, 20 and 999 on SW1 and put PC1 and PC2 in VLANs 10 and 20.
  2. Make SW1 Gi0/1 a trunk with native VLAN 999.
  3. Bring up R1 G0/0 with no address, then add a subinterface per VLAN, including one for the native VLAN.
  4. Prove PC1 can ping PC2 and that the traceroute goes through R1.

Checks

  • show ip interface brief: G0/0 up/up with no address; G0/0.10 and G0/0.20 up/up with their gateways.
  • show ip route connected: C 192.168.10.0/24 via G0/0.10 and C 192.168.20.0/24 via G0/0.20.
  • tracert 192.168.20.11 (from PC1): First hop 192.168.10.1, then PC2.

Then break it

  • Shut down R1 G0/0 (the physical interface, not a subinterface). Both subinterfaces go down with it and both VLANs lose their gateway.
  • Change G0/0.20 to "encapsulation dot1Q 30". PC2 cannot ping its gateway. The subinterface still shows up/up.

Layer 3 switch with DHCP relay

Foundation · about 40 minutes

The DHCP relay is the part people forget at cutover: the helper address goes on every SVI, and the DHCP server needs a route back to the relay address or offers never return.

Kit: One 3560-24PS switch, one 2911 router as the DHCP server, two PCs set to DHCP.

Tasks

  1. Turn on IP routing on DSW1, create VLANs 10 and 20, their SVIs, and the access ports.
  2. Make Gi0/1 a routed port to R1.
  3. On R1, build a DHCP pool per VLAN, excluding .1 to .10, with the right default router.
  4. Point both SVIs at R1 with a helper address, and give R1 a route back to both VLANs.
  5. Prove both PCs get an address and can ping each other.

Checks

  • show ip route (DSW1): C 10.10.10.0/24, C 10.10.20.0/24 and C 10.0.0.0/30. If the SVIs are missing, "ip routing" is off or the VLAN has no active port.
  • show ip dhcp binding (R1): One lease in each pool, from .11 upwards.
  • ipconfig (each PC): An address in its VLAN with the SVI as the gateway.

Then break it

  • Remove R1's route to 10.10.20.0/24. PC2 stays on a 169.254 address. PC1 still works.
  • Delete VLAN 20 on DSW1 with "no vlan 20". Fa0/2 goes inactive, Vlan20 goes down/down and PC2 drops off.

LACP EtherChannel trunk

Foundation · about 35 minutes

The fault in the second "break it" step took a client's server VLANs down for fifteen minutes on one of my changes. Configure the port-channel, never the members.

Kit: Two 2960-24TT switches joined on Gi0/1 and Gi0/2, one PC each.

Tasks

  1. Create VLANs 10, 20 and 999 on both switches and put each PC in VLAN 10.
  2. Bundle Gi0/1 and Gi0/2 into Port-channel1 with LACP active at both ends.
  3. Make Port-channel1 a trunk with native VLAN 999 and VLANs 10, 20 and 999 allowed. Configure the port-channel interface only.
  4. Prove the bundle is up with both members, and that PC1 still reaches PC2 with one cable pulled.

Checks

  • show etherchannel summary: Po1(SU) with Gi0/1(P) and Gi0/2(P), protocol LACP.
  • show lacp neighbor: A neighbour on both ports, with the partner port numbers.
  • show interfaces trunk: Po1 listed as the trunk, not the member ports.

Then break it

  • Change SW2's members to "channel-group 1 mode on". SW2 bundles regardless, while SW1's members show (I) stand-alone because nothing answers its LACP. On real switches EtherChannel guard err-disables the "on" side.
  • Add VLAN 30 to Gi0/1 only: "interface Gi0/1", then "switchport trunk allowed vlan add 30". On real IOS: %EC-5-CANNOT_BUNDLE2 ... will be suspended (vlan mask is different), and Gi0/1 shows (s). Packet Tracer does not always enforce this, so try it on CML or real kit if you can.

Floating static routes for a backup link

Foundation · about 30 minutes

A floating static is the cheapest failover there is. Know its limit: it only moves when the next hop disappears from a directly connected interface.

Kit: Two 2911 routers joined by two links, a PC on one side and a server on the other.

Tasks

  1. Address everything and check each link pings end to end.
  2. On both routers add a static route to the far LAN over the primary link.
  3. Add a second static route over the backup link with an administrative distance of 10.
  4. Prove the backup is not in the table, then shut R1 G0/0 and watch it take over.

Checks

  • show ip route static: Only the route via the primary next hop (10.1.12.2 on R1).
  • shutdown on R1 G0/0, then show ip route static: S 192.168.2.0/24 [10/0] via 10.2.12.2.
  • ping 192.168.2.10 (from PC1, during the failover): A few drops, then replies.

Then break it

  • Put a switch in the middle of the primary link, then pull the cable between the switch and R2. R1 G0/0 stays up, the primary route stays in the table and traffic is black-holed.
  • Give the backup route a distance of 1. Both routes appear and traffic shares the links.

Port forwarding: publish one server, safely

Foundation · about 40 minutes

Publishing a web server through the router's single public address is one of the first things a small site asks for. It is also where people write an inbound access list against the wrong address, block their own users' return traffic, or expose the whole server when they meant one port.

Kit: Two 2911 routers (R1 and ISP), one 2960 switch, one PC and one server inside, one PC outside.

Tasks

  1. Addresses as in the table. DHCP on R1 for the inside LAN (exclude .1 to .20). Default route on R1 to the ISP.
  2. PAT for 10.0.10.0/24 on Gi0/1.
  3. Static port translations: TCP 80 and 443 on R1's outside interface to SRV1, and TCP 2222 on the outside to TCP 22 on SRV1.
  4. An inbound access list on Gi0/1 that allows only the published services and return traffic for inside users' sessions. Work out which address the access list must match.
  5. Prove it from PC-OUT: the web page loads at 203.0.113.2, SSH to port 2222 reaches SRV1, and nothing else answers.

Checks

  • From PC-OUT, browse to http://203.0.113.2: SRV1's web page.
  • show ip nat translations (R1): Static entries for tcp 203.0.113.2:80, :443 and :2222 to 10.0.10.10:80, :443 and :22, plus dynamic PAT entries for PC1.
  • From PC1, browse to http://198.51.100.1 or ping 198.51.100.50: Works. The inbound access list lets the replies back in.
  • show access-lists OUTSIDE-IN (R1): Matches on the 80, 443 and 2222 lines and on the return-traffic lines. Nothing has hit a line written for 10.0.10.10.
  • From PC-OUT, telnet 203.0.113.2 22: Refused or times out. Only 2222 is published for SSH.

Then break it

  • Rewrite the 80 and 443 lines of OUTSIDE-IN with host 10.0.10.10 as the destination. The web page stops loading from outside. Those lines show no matches.
  • Remove the "established" line. PC1 can no longer browse, though nothing about NAT has changed.
  • Replace the three port translations with "ip nat inside source static 10.0.10.10 203.0.113.3" and give R1 a route for it. Every port on SRV1 is now reachable on 203.0.113.3, unless the access list happens to stop it.
  • Remove "ip nat outside" from Gi0/1. Nothing is translated at all. Inside users and the published server both fail.

Multi-area OSPF with a summary at the ABR

Intermediate · about 45 minutes

Summarising at the area border is what keeps a flapping branch from rippling across the whole network. It only works if the addressing was planned for it.

Kit: Three 2911 routers and two PCs.

Tasks

  1. Give each router a fixed router ID (1.1.1.1, 2.2.2.2, 3.3.3.3).
  2. Put the R1-R2 link and R2's LAN in area 0, and the R1-R3 link and both of R3's LANs in area 1.
  3. Make the LAN interfaces passive.
  4. Advertise R3's loopback as a /24, not a /32.
  5. Summarise 172.16.0.0/24 and 172.16.1.0/24 as one /23 on R1.

Checks

  • show ip ospf neighbor: FULL on both of R1's links. A DR and BDR on each, since they are Ethernet.
  • show ip route ospf (R2): O IA 172.16.0.0/23 via 10.0.12.1, and no separate /24s for R3's LANs.
  • show ip ospf interface brief (R3): Lo1 in area 1, network type P2P.

Then break it

  • On R3, change the 10.1.13.0 network statement to area 0. The R1-R3 neighbour never forms, and R1 logs a mismatched area ID.
  • Remove "ip ospf network point-to-point" from R3 Lo1. R1 still sends the /23 summary, but on R1 itself the loopback appears as 172.16.1.1/32.

OSPF stub, totally stubby and NSSA areas

Intermediate · about 60 minutes

Stub areas are how you stop a small branch router learning every route in the company. The commands are short; what trips people up is which router they go on, what each type really blocks, and that an NSSA does not get a default route unless you give it one.

Kit: Five 2911 routers. Packet Tracer 8 handles stub and totally stubby areas. If your version refuses the NSSA commands, do part 3 in CML with IOSv.

Tasks

  1. Part 1: build all three areas as normal areas. On R0, originate a default route (always) and redistribute a static 172.16.0.0/16 to Null0. Record R2's routing table: O, O IA and O E2 routes.
  2. Part 2: make area 1 a stub on R1 and R2. Then make it totally stubby. Record R2's table after each step, and note which router the extra keyword went on.
  3. Part 3: make area 2 an NSSA on R3 and R4. On R4, redistribute a static 10.99.0.0/16 to Null0. Check how it appears on R4, R3 and R0.
  4. Give R4 a default route through OSPF without making area 2 totally stubby.

Checks

  • show ip route ospf (R2), part 1: O IA routes for the other areas, O*E2 0.0.0.0/0 and O E2 172.16.0.0/16.
  • show ip route ospf (R2), stub: The E2 routes are gone. An O*IA 0.0.0.0/0 from R1 has appeared. The O IA routes are still there.
  • show ip route ospf (R2), totally stubby: Only O*IA 0.0.0.0/0. Every other inter-area route is gone.
  • show ip ospf database nssa-external (R3): A type 7 LSA for 10.99.0.0/16 from R4.
  • show ip route 10.99.0.0 (R0): O E2, translated to type 5 by R3.
  • show ip route 0.0.0.0 (R4), before and after the last task: Nothing before. O*N2 0.0.0.0/0 via R3 after.

Then break it

  • Configure "area 1 stub" on R1 only. The R1 to R2 adjacency drops and does not come back.
  • Move "no-summary" from R1 to R2. Nothing changes on R2. The inter-area routes are still there.
  • Remove "default-information-originate" from R3. R4 loses its default route. Anything outside the company becomes unreachable from area 2.
  • Make area 2 a plain stub instead of an NSSA. R4 refuses to redistribute 10.99.0.0/16 into the area: the partner network vanishes from the company.

Two-way redistribution between OSPF and EIGRP, without the loop

Intermediate · about 60 minutes

Mergers, migrations and old WAN designs leave two routing protocols side by side. Redistributing at one point is easy. Redistributing at two points, which you need for resilience, is where routes go the long way round or flip back and forth. This lab builds it properly and then shows you what each safeguard is for.

Kit: Four IOSv routers. Loopbacks stand in for the LANs.

Tasks

  1. Address the routers and bring up OSPF between R1, R2 and R3, and EIGRP between R2, R3 and R4. Prove each protocol works on its own before you redistribute anything.
  2. On R4, redistribute Loopback100 into EIGRP with a route-map, so 10.40.40.0/24 is an external EIGRP route.
  3. Build the two route-maps on R2 and R3, and redistribute in both directions with them.
  4. Add the OSPF external distance on R2 and R3.
  5. Check every route on every router, then work through the break-it steps one at a time.

Checks

  • show ip route ospf (R1): 10.4.4.0/24 and 10.40.40.0/24 as O E2, each with two paths, via 10.0.12.2 and 10.0.13.2.
  • show ip ospf database external 10.40.40.0 (R1): Two LSAs, advertised by 2.2.2.2 and 3.3.3.3, each with External Route Tag 90.
  • show ip route eigrp (R4): 10.1.1.0/24 as D EX via both R2 and R3.
  • show ip eigrp topology 10.1.1.0/24 (R4): An external route with administrator tag 110, through both R2 and R3.
  • show ip route 10.40.40.0 (R2 and R3): D EX at distance 170, straight to R4. Neither router reaches it through the other.
  • traceroute 10.40.40.1 source Loopback0 (R1): Two hops: R2 or R3, then R4.

Then break it

  • On R2, replace the EIGRP redistribution with one that has no metric: no redistribute ospf 1, then redistribute ospf 1 route-map OSPF-TO-EIGRP. show ip eigrp topology 10.1.1.0/24 on R4 now lists one path, via R3 only. There is no error message on R2.
  • On R2 and R3, remove distance ospf external 171. Then shut and re-enable R2 G0/2 and check show ip route 10.40.40.0 on R2 and R3 a few times. One or both routers now reach 10.40.40.0 through OSPF, the long way round via R1 and the other router, and the route can change between EIGRP and OSPF from one check to the next.
  • On R1, remove ip ospf network point-to-point from Loopback0. R4 now has 10.1.1.1/32 instead of 10.1.1.0/24.

PAT for users and a static NAT for a server

Intermediate · about 40 minutes

Most NAT tickets are a missing "ip nat inside" or "outside", or a pool without overload that works until the twentieth user logs on.

Kit: Two 2911 routers (R1 as the edge, ISP as the provider), a 2960 switch, a PC and a server.

Tasks

  1. Address everything. Give R1 a default route to the ISP. The ISP gets no route to 192.168.1.0/24, just like a real one.
  2. Mark R1 G0/1 as NAT inside and G0/0 as NAT outside.
  3. Translate the whole inside LAN to R1's outside address with PAT.
  4. Publish SRV1 as 203.0.113.5 with a static translation.
  5. Prove PC1 reaches 198.51.100.1 and the ISP reaches the server on 203.0.113.5.

Checks

  • show ip nat translations: A "--- 203.0.113.5 192.168.1.10 ---" static entry, plus an icmp entry from 192.168.1.11 to 203.0.113.2 while PC1 pings.
  • show ip nat statistics: G0/1 under inside interfaces, G0/0 under outside, and hits counting up.
  • ping 203.0.113.5 (from ISP): Replies from the server.

Then break it

  • Remove "ip nat inside" from R1 G0/1. PC1 can no longer reach 198.51.100.1, and no new translations appear.
  • Replace the PAT line with a two-address pool and no "overload". The first two hosts work, the third gets nothing until a translation times out.

PPPoE: a broadband router that dials its own address

Intermediate · about 45 minutes

Many broadband and fibre services still hand you PPPoE: the router authenticates, gets its address from the provider, and everything rides inside a dialer interface with eight bytes less room in every packet. Get the MTU wrong and pages half-load while ping works perfectly.

Kit: Two 2911 routers (R1 as the customer router, BRAS as the provider's PPPoE server), one 2960 switch and one PC.

Tasks

  1. On BRAS: a local user for branch1, an address pool, a virtual template that is unnumbered to Loopback0 and uses CHAP, a bba-group, and PPPoE enabled on Gi0/0.
  2. On R1: PPPoE client on Gi0/1 in dial pool 1, and a Dialer1 interface that negotiates its address, uses CHAP and has an MTU of 1492.
  3. A default route out of Dialer1, PAT for the LAN on Dialer1, and DHCP on the LAN.
  4. Clamp TCP MSS to 1452 so hosts that send 1,500-byte packets still work. If your Packet Tracer version rejects the command, note it: real IOS needs it.
  5. Prove the session, the address, the route, and a ping to 192.0.2.1 from PC1.

Checks

  • show pppoe session (R1): One session, state UP, on Gi0/1 and Dialer1.
  • show ip interface brief | include Dialer: Dialer1 up with an address from 198.51.100.10 to .50.
  • show ip route (R1): A default route out of Dialer1, and a connected /32 for the BRAS (the PPP peer route).
  • ping 192.0.2.1 from PC1: Replies. show ip nat translations on R1 shows PC1 translated to the Dialer1 address.
  • show interfaces Dialer1 | include MTU: MTU 1492 bytes.

Then break it

  • Change R1's CHAP password by one character. No PPPoE session, or one that keeps coming up and dropping. debug ppp authentication shows a CHAP failure.
  • Set the Dialer1 MTU back to 1500 and remove adjust-mss. Pings work and small pages load, but large downloads and some HTTPS sites stall.
  • Remove "pppoe-client dial-pool-number 1" from Gi0/1. Dialer1 stays down and no session starts.
  • Point PAT at Gi0/1 instead of Dialer1. The session is up, but the LAN cannot reach anything.

IPv6 with SLAAC and link-local next hops

Intermediate · about 35 minutes

Most IPv6 tickets come down to three things: routing not turned on, a LAN that is not a /64, or a static route that does not name its exit interface. This lab hits all three.

Kit: Two 2911 routers and two PCs set to IPv6 automatic configuration.

Tasks

  1. Turn on IPv6 routing on both routers.
  2. Address every interface, and set the link-local addresses by hand to fe80::1 on R1 and fe80::2 on R2.
  3. Set both PCs to automatic IPv6 configuration and check they build an address in their LAN prefix.
  4. Add a static route on each router to the far LAN, using the neighbour's link-local address as the next hop.
  5. Prove PC1 can ping PC2 over IPv6.

Checks

  • show ipv6 interface brief: Each interface up/up with its fe80:: address and its global address.
  • ipv6config (each PC): A global address inside its LAN /64, and the router's fe80:: address as the default gateway.
  • show ipv6 route static: S 2001:db8:acad:2::/64 via FE80::2, GigabitEthernet0/0 on R1, and the mirror on R2.
  • ping 2001:db8:acad:2:... (PC1 to PC2's address): Replies.

Then break it

  • Remove "ipv6 unicast-routing" from R1, then set PC1 to static and back to automatic. PC1 comes back with only a link-local address and no gateway.
  • Change R1 G0/1 to 2001:db8:acad:1::1/80 and renew PC1. PC1 does not build a global address.
  • Type the static route without the interface: "ipv6 route 2001:db8:acad:2::/64 fe80::2". IOS refuses the line.

Guest isolation and management ACLs

Intermediate · about 45 minutes

Write the ACL as the policy in plain words first, then as lines. Extended ACLs go close to the source; anything protecting the router itself goes on the VTY lines.

Kit: One 2911 router, three PCs (staff, guest, admin) and a server running HTTP.

Tasks

  1. Write the policy above as one named extended ACL, inbound on the guest interface.
  2. Set up SSH on R1 with a local user.
  3. Restrict the VTY lines with a standard ACL, on every VTY line the router has.
  4. Prove each rule with a test that should pass and one that should fail.

Checks

  • show access-lists: Counters rising on the lines your tests should hit, and on the deny when the guest pings the server.
  • Web browser on GUEST to 10.8.30.10: The page loads.
  • ping 10.8.30.10 (from GUEST): Fails: reply "Destination host unreachable" from 10.8.20.1.
  • ssh -l admin 10.8.10.1 (from STAFF, then from GUEST): STAFF gets a prompt; GUEST is refused.

Then break it

  • Apply GUEST-IN outbound on G0/1 instead of inbound. Guests lose everything, including the web page that worked before.
  • Restrict only "line vty 0 4". An outsider is refused while lines 0 to 4 are free. Once five sessions are open, the next one lands on line 5 and gets a login prompt.

Lock down an access switch

Intermediate · about 40 minutes

The baseline to apply before an access switch goes anywhere near a user, and the settings an audit checks first.

Kit: One 2960-24TT switch, a user PC, an admin PC, and a spare switch for the "break it" step.

Tasks

  1. Management only in VLAN 99, with SSH version 2, a local user and no Telnet.
  2. Port security on Fa0/1: one sticky MAC, violation mode restrict.
  3. PortFast and BPDU guard on every access port.
  4. Move every unused port into an unused VLAN 666 and shut it down.
  5. Add a login banner and encrypt the plain-text passwords.

Checks

  • show port-security interface fa0/1: Port Security Enabled, Violation Mode Restrict, one sticky MAC learned.
  • show ip ssh: SSH Enabled - version 2.0.
  • show interfaces status: Unused ports in VLAN 666 and disabled.

Then break it

  • Connect a second switch to Fa0/1 in place of the PC. Fa0/1 goes err-disabled the moment a BPDU arrives.
  • Swap PC1 for a different PC. No traffic from the new PC, and the violation counter rises. The port stays up because the mode is restrict.

Two distribution switches: spanning tree and HSRP that agree

Intermediate · about 45 minutes

Two distribution switches share the load: DS1 is the gateway and the spanning tree root for VLAN 10, DS2 for VLAN 20. When root and gateway disagree, nothing breaks; the traffic just takes the long way, which is why it survives for years.

Kit: Two 3560-24PS switches, one 2960-24TT access switch and two PCs.

Tasks

  1. Create VLANs 10 and 20 on all three switches, set Rapid PVST+, and make every inter-switch link a trunk.
  2. Set explicit spanning tree priorities on DS1 and DS2 as the design says. Do not use root primary.
  3. Configure the SVIs and HSRP on both distribution switches, with preempt on the primary for each VLAN, and turn on ip routing.
  4. Prove each VLAN uses a different uplink from AS1, and that each gateway sits on the same switch as its root.

Checks

  • show spanning-tree root (AS1): VLAN 10 root is DS1, VLAN 20 root is DS2.
  • show spanning-tree vlan 10 (AS1): Gi0/1 (to DS1) is the root port. Gi0/2 is alternate, blocking. VLAN 20 is the reverse.
  • show standby brief (DS1 and DS2): DS1 active for group 10, DS2 active for group 20, each standby for the other.
  • show mac address-table address 0000.0c07.ac0a (DS1): No interface entry: DS1 is active, so it owns the VLAN 10 virtual MAC itself.
  • ping 10.10.20.11 from PC1, then shut DS1 Gi0/2: Replies, a short loss while spanning tree moves to Gi0/2, then replies again.

Then break it

  • On DS2, set standby 10 priority 120 and standby 10 preempt. Pings still work. show standby brief shows DS2 active for VLAN 10, while AS1 still forwards VLAN 10 up Gi0/1 to the DS1 root. On DS1, the VLAN 10 virtual MAC is now learned on Gi0/1, the link to DS2: every frame to the gateway goes through DS1 to get there.
  • Remove standby 10 preempt from DS1, shut DS1 Vlan10, then bring it back. DS2 takes over, as it should. When DS1 Vlan10 comes back, DS2 stays active for VLAN 10 and you have the misalignment above.
  • On DS2, change VLAN 10's HSRP group from 10 to 11 (remove standby 10, add standby 11 ip 10.10.10.1). show standby brief shows DS1 active for group 10 and DS2 active for group 11, both for 10.10.10.1. The logs report a duplicate address, and PCs flip between two virtual MACs.
  • On DS1, use spanning-tree vlan 10 root primary instead of an explicit priority, and paste DS2 after it. Depending on the order and the existing priorities, the root can end up on either switch, and the result changes on the next rebuild.

GRE tunnel between two sites, with OSPF over it

Intermediate · about 40 minutes

A GRE tunnel is the quickest way to join two sites across a network that will not route your private addresses. It is also easy to make flap, or to leave silently broken while it shows up/up.

Kit: Three 2911 routers (ISP plays the internet) and two PCs.

Tasks

  1. Address every interface and give HQ and BR a default route to the ISP. Prove HQ can ping BR's G0/1 address, and that PC1 cannot reach PC2 yet.
  2. Build Tunnel0 at both ends, sourced from G0/1, and set ip mtu 1476. Add ip tcp adjust-mss 1436 too; if Packet Tracer refuses it, leave it out.
  3. Run OSPF over the tunnel. Advertise the LAN and the tunnel subnet, make the LAN passive, and set router IDs.
  4. Prove PC1 reaches PC2 through the tunnel, and that the ISP still has no route to either LAN.

Checks

  • show interfaces Tunnel0 (HQ): Tunnel0 up/up, tunnel source 203.0.113.2, destination 198.51.100.2, MTU 1476.
  • show ip ospf neighbor (HQ): BR (router ID 2.2.2.2) FULL on Tunnel0.
  • show ip route ospf (HQ): 10.2.0.0/24 via 172.16.0.2, Tunnel0. Nothing for 198.51.100.0.
  • tracert 10.2.0.10 (PC1): Three hops: 10.1.0.1, 172.16.0.2, 10.2.0.10. The ISP never appears.
  • show ip route (ISP): Only the two connected /30s.

Then break it

  • On both routers, add the WAN /30 to OSPF (network 203.0.113.0 0.0.0.3 area 0 on HQ, 198.51.100.0 0.0.0.3 on BR). On real IOS the tunnel and the adjacency come up, then drop, over and over, with %TUN-5-RECURDOWN in the log. Each router has learned the /30 holding the other end of the tunnel through the tunnel itself, and the /30 beats the default route.
  • On BR, change the tunnel destination to 203.0.113.9. Tunnel0 on BR stays up/up. The OSPF neighbour drops and PC1 cannot reach PC2.
  • Remove ip mtu 1476 and ip tcp adjust-mss 1436 from both tunnels. On real IOS, ping 10.2.0.1 source 10.1.0.1 size 1500 df-bit from HQ. Small pings work, the 1500-byte ping with DF set fails. With the MTU back at 1476, IOS sends "fragmentation needed" and TCP adapts instead of stalling.
  • On ISP, apply an inbound ACL on G0/0 that permits only TCP, UDP and ICMP. Pings between the routers' public addresses still work, but the tunnel carries nothing.

QoS on a sub-rate WAN: mark at the edge, shape, then prioritise

Intermediate · about 60 minutes

A branch with a 1 Gbps handoff and a 10 Mbps contract is where most QoS goes wrong. The router never sees congestion, so its priority queue never acts, and the carrier drops whatever arrives over the contract, voice included. This lab builds the policy that actually protects calls, and uses NetFlow to see what is filling the link.

Kit: Two 2911 routers, one 2960 switch, a PC and an IP phone or second PC on the voice VLAN, and two servers at HQ.

Tasks

  1. Router-on-a-stick for VLANs 10 and 20, OSPF or static routing to HQ.
  2. NetFlow on R1 Gi0/1 in both directions, exported to 10.20.0.50 port 9996. Generate traffic and find the top talker.
  3. Access lists and class maps that classify voice by the voice subnet and RTP port range, signalling by SIP, the business application by server and port, and bulk by SMB and FTP. Mark them on the LAN subinterfaces, inbound.
  4. Queueing classes that match DSCP values, and a child policy: priority 1000 kbps for voice, bandwidth remaining percentages for the rest.
  5. A parent policy that shapes class-default to 9.5 Mbps and carries the child policy. Apply it outbound on Gi0/1.
  6. Prove each class is counting the traffic you expect.

Checks

  • show ip cache flow (R1): Flows listed by source and destination. The largest is the bulk copy, not the calls.
  • show policy-map interface GigabitEthernet0/0.20 input: Voice packets counted in class VOICE and marked EF.
  • show policy-map interface GigabitEthernet0/1 output: The parent shaper at 9500000 bps, and the child classes counting packets. In CML under load: drops in BULK or class-default, none in Q-VOICE.
  • Start a large file copy during a call (CML): The copy slows. The call stays clear.

Then break it

  • Change VOICE-RTP to "permit udp any any range 16384 32767". Video calls and some games now land in the priority queue. Real voice starts dropping when the queue fills.
  • Apply WAN-CHILD directly to Gi0/1 without the shaper (CML). The policy counts traffic but never drops or queues anything, and calls still break up when the link is busy.
  • Reduce "priority 1000" to "priority 200" and make three calls during a file copy (CML). All three calls break up, not just the third.
  • Add "permit tcp any any" to the BULK access list. Every TCP session, including the business application, is marked CS1 and gets the bulk share.

Capstone: build a branch from a blank config

Intermediate · about 90 minutes

Every single-topic lab practises one skill. A real branch needs all of them at once, in the right order, with the management and logging that nobody remembers until the audit. This one starts from factory defaults and ends with a site you could hand over.

Kit: One 2911 router (R1), one 2911 as the ISP, two 2960-24TT switches, two PCs, an admin PC and one server (SRV1) running DNS, TFTP, NTP and syslog.

Tasks

  1. Basics on every device: hostname, domain branch.example, enable secret, encrypted passwords, no DNS lookup on typos, a login banner, and logging synchronous plus a 10-minute exec timeout on the console.
  2. VLANs 10, 20, 30, 99 and 999 on both switches. Trunks R1 to SW1 and SW1 to SW2 carrying 10, 20, 30 and 99 only. Access ports as in the table. Every unused port into VLAN 999 and shut.
  3. Router-on-a-stick on R1 for all four VLANs.
  4. DHCP on R1 for Users and Finance: keep .1 to .20 out of each pool, hand out DNS 10.1.30.10 and the domain name, and option 150 pointing at the TFTP server for the phones you will add later.
  5. Management interfaces on both switches in VLAN 99, with a default gateway so they can be reached from other VLANs.
  6. SSH version 2 on R1, SW1 and SW2: a local admin user, a 60-second negotiation timeout, two authentication retries, SSH only on all sixteen VTY lines, and an access list so only VLAN 99 can log in.
  7. Services: NTP and syslog to SRV1 (informational level, with millisecond timestamps), SNMP read-only with an access list (never read-write), and a copy of each running config on SRV1 by TFTP.
  8. Internet: default route to the ISP, PAT for 10.1.0.0/16 on Gi0/1, and SRV1 published as 198.51.100.3 with a static NAT.
  9. CDP off on Gi0/1 towards the ISP, LLDP on for the inside.
  10. Prove the whole site: every check below, then reload R1 and check it all comes back on its own.

Checks

  • show ip dhcp binding (R1): PC1 has an address in 10.1.10.21 to .254, PC2 in 10.1.20.21 to .254.
  • ipconfig /all on PC1: Gateway 10.1.10.1, DNS 10.1.30.10, domain branch.example.
  • ssh -l admin 10.1.99.12 from ADMIN, then from PC1: ADMIN gets a login. PC1 is refused by the access list.
  • show ntp associations (SW1): An asterisk next to 10.1.30.10: synchronised.
  • SRV1 Syslog service: Messages from R1, SW1 and SW2 with timestamps, including the interface you shut and re-enabled to test it.
  • ping 192.0.2.1 from PC2, then show ip nat translations (R1): Replies. Translations to 198.51.100.2 for PC2, and the static entry 198.51.100.3 to 10.1.30.10.
  • show cdp neighbors (ISP): No R1. CDP is off on the link.
  • show interfaces status | include 999 (SW1): Every unused port in VLAN 999 and disabled.

Then break it

  • On SW2, remove "ip default-gateway 10.1.99.1". ADMIN can still SSH to SW2: it is in the same VLAN. SSH to SW2 from anywhere else fails, and SW2 stops syncing NTP and logging to SRV1.
  • Remove VLAN 99 from the allowed list on the SW1 to SW2 trunk. SW2 is unreachable for management, but users on SW2 are fine.
  • Change "access-class MGMT in" to "access-class MGMT out" on R1. SSH to R1 from PC1 now works, and ADMIN can no longer SSH onward from R1 to the switches.
  • Delete the "ip dhcp excluded-address" lines and reload SRV1 with a static address inside the pool. Sooner or later a PC is handed SRV1's address and both drop off intermittently.

Dual stack: OSPF for IPv4, static routes then OSPFv3 for IPv6

Intermediate · about 60 minutes

Most networks will run IPv4 and IPv6 side by side for years. This lab builds both on the same three routers: OSPF in a single non-backbone area for IPv4, IPv6 static routes first so you see what each one needs, then OSPFv3 to replace them.

Kit: Three 2911 routers, one PC and one server.

Tasks

  1. Addresses on every interface, both families. On R2 Gi0/1, build the IPv6 address from the prefix with EUI-64 and note what it becomes.
  2. Turn on ipv6 unicast-routing on all three routers.
  3. OSPF for IPv4 in area 10 with the router IDs in the table. PC1 reaches SRV1 over IPv4.
  4. IPv6 statics: on R3 a default route to R1; on R1 a route to 2001:db8:20:2::/64 via R2; on R2 a route to 2001:db8:20:1::/64 via R1. Use a global next hop on one and a link-local next hop with the exit interface on the other.
  5. Prove PC1 reaches SRV1 over IPv6. Then remove every IPv6 static route.
  6. OSPFv3: ipv6 router ospf 1 with the same router IDs, and ipv6 ospf 1 area 0 on every IPv6 interface. PC1 reaches SRV1 again.

Checks

  • show ip ospf neighbor (R1): R2 and R3 FULL. R3 is DR or BDR on LAN A with R1.
  • show ip route ospf (R3): 10.20.12.0/30 and 10.20.2.0/24 as O routes (intra-area: there is only one area).
  • show ipv6 interface brief (R2): Gi0/1 global address 2001:db8:20:12: followed by the interface ID built from the MAC.
  • show ipv6 route static (R1), part 1: S 2001:db8:20:2::/64 via the next hop you chose.
  • show ipv6 ospf neighbor (R1), part 2: R2 and R3 FULL, listed by router ID, with link-local addresses as the neighbour address.
  • ping 2001:db8:20:2::100 from PC1: Replies in both parts.

Then break it

  • Remove "ipv6 unicast-routing" from R1. R1 still answers pings to its own IPv6 addresses, but stops forwarding IPv6 between interfaces, and PC1 loses IPv6 to SRV1.
  • On R2, configure the IPv6 static route with a link-local next hop but no exit interface. The command is rejected, or the route never becomes usable.
  • Add a second OSPF area for IPv4 on R2 (area 20 on a new loopback) without any area 0. R1 and R3 never learn the area 20 route.
  • Remove the IPv4 address from R3 entirely and the OSPFv3 router-id line. OSPFv3 on R3 does not start.

Capstone: a small campus with LACP, SVIs, relay, HSRP and edge security

Advanced · about 120 minutes

The joined-up version of a real campus build: an access layer that defends itself, a distribution switch doing the routing, a DHCP server two hops away, a redundant pair of edge routers with HSRP, and access lists that protect a server without breaking it. Packet Tracer handles all of it.

Kit: Two 3650-24PS switches (MLS1 access, MLS2 distribution), two 2911 routers (R1, R2), one 2960 (SW3) on the services LAN, one 2911 as the ISP, two PCs and one server. In Packet Tracer, the 3650 arrives without a power supply: add one in the Physical tab before you start. Check that your Packet Tracer version supports HSRP interface tracking on the 2911; if not, use priority alone for that step.

Tasks

  1. VLANs 10, 20, 99 and 999 on MLS1 and MLS2. PC ports in 10 and 20, every unused port in 999 and shut.
  2. Po10 with LACP between Gi1/0/23 and 24, MLS1 active and MLS2 passive, as a trunk carrying 10, 20 and 99 only.
  3. On MLS2: ip routing, SVIs for VLANs 10, 20 and 99, and Gi1/0/3 as a routed port to R1. On MLS1, a management SVI and default gateway.
  4. R1 as DHCP server for VLAN 10 (10.30.10.100 to .150, DNS 10.30.50.10), with MLS2 relaying. PC1 gets its address across two hops.
  5. OSPF area 0 on MLS2, R1 and R2, with passive-interface default and only the links between routers active. R1 priority 0 on the services LAN. R2 originates the default route.
  6. HSRP version 2 group 1 on R1 and R2: virtual 10.30.50.1, R2 priority 110 with preempt, tracking Gi0/0 with a decrement big enough to hand over to R1.
  7. Access port security on MLS1 Gi1/0/1 and 2: PortFast, BPDU guard, sticky MAC maximum 1, violation shutdown, no CDP. Save the config so the sticky MACs survive a reload.
  8. R2 VTY: SSH only, from SRV1 and VLAN 99 only, and no onward Telnet or SSH from R2.
  9. An access list so SRV1 can ping anything, but nothing outside the services LAN can ping SRV1. Everything else to SRV1 still works.
  10. PAT on R2 for 10.30.0.0/16, logging and NTP to SRV1 on every device, and an OSPFv2 router ID on each router you can recognise.

Checks

  • show etherchannel summary (MLS1): Po10(SU) with Gi1/0/23 and 24 both (P). Protocol LACP.
  • show interfaces trunk (MLS1): Po10 trunking, VLANs allowed 10,20,99. No 999.
  • ipconfig on PC1: An address in 10.30.10.100 to .150 from R1, gateway 10.30.10.1.
  • show ip ospf neighbor (R2): R1 FULL/DROTHER on the services LAN (priority 0). R2 is DR.
  • show standby brief (R1 and R2): R2 Active, R1 Standby, virtual 10.30.50.1.
  • shut R2 Gi0/0, then show standby brief: R1 becomes Active. When Gi0/0 comes back, R2 preempts.
  • show port-security interface Gi1/0/1 (MLS1): Secure-up, maximum 1, one sticky address.
  • ping 10.30.50.10 from PC1; ping 10.30.10.x from SRV1: PC1 gets no reply. SRV1 gets replies.
  • SSH to R2 from PC2, then from SRV1, then onward from R2 to R1: PC2 refused. SRV1 logs in. The onward connection is refused.

Then break it

  • Set MLS1's channel-group to passive, matching MLS2. Po10 never forms. Both sides wait for the other to start LACP.
  • Change R2's tracking decrement to 5, then shut R2 Gi0/0. R2 stays active with priority 105, above R1's 100. The server's gateway now leads to a router with no internet.
  • Remove "ip helper-address" from MLS2 Vlan10. PC1 falls back to a 169.254 address. PC2 is unaffected because it is static.
  • Unplug PC1 and plug a different PC into Gi1/0/1. The port goes err-disabled immediately: the sticky MAC belongs to PC1.
  • Move the PROTECT-SRV1 access list to "in" on R1 Gi0/1. SRV1 can no longer ping out at all, and the campus can ping it again.

Dual-hub DMVPN with IPsec, front-door VRFs and spoke-to-spoke tunnels

Advanced · about 75 minutes

The standard way to put broadband branches on a private network: every branch keeps encrypted tunnels to a hub in each of two data centres, and builds tunnels to other branches only when it needs them. There are a lot of moving parts, and most of the faults look the same from a PC.

Kit: Five IOSv routers (INET plays the internet), an unmanaged switch, a server and two PCs.

Tasks

  1. Address every interface, put the internet-facing ones in VRF INET and add the VRF default routes. Prove each spoke can ping both hubs with ping vrf INET, and that the global routing tables are still empty.
  2. Configure the crypto on all four routers: the keyring in VRF INET, the ISAKMP policy, the transform set and the profile.
  3. Build Tunnel10 on the hubs (with ip nhrp map multicast dynamic, which IOSv needs) and on the spokes (two next-hop servers, shortcut, registration no-unique, hold time 600).
  4. Run EIGRP: the hubs over the tunnel and the DC LAN with a default summary on the tunnel, the spokes as stubs. Add HSRP on the DC LAN with HUB1 active.
  5. Prove branch-to-branch traffic goes direct after the first packets, and that a branch keeps working when HUB1's internet link goes down.

Checks

  • show crypto isakmp sa (SPOKE1): Two QM_IDLE entries, to 198.51.100.2 and 198.51.100.6.
  • show dmvpn (SPOKE1): Both hubs listed, state UP, attribute S (static, from the nhs lines).
  • show ip eigrp neighbors (SPOKE1): 172.16.10.1 and 172.16.10.2, both on Tu10.
  • show ip route eigrp (SPOKE1): Only D* 0.0.0.0/0, via both hubs. No route for 10.0.0.0/24 or 10.1.2.0/24.
  • traceroute 10.1.2.10 from PC1, then again: The first passes through a hub's tunnel address. The second goes 10.1.1.1, 172.16.10.12, 10.1.2.10.
  • show ip route nhrp (SPOKE1, after the traceroute): H 10.1.2.0/24 via 172.16.10.12, learned from NHRP.
  • ping 10.0.0.10 from PC1 continuously, then shut HUB1 G0/0: Up to 15 seconds of loss while SPOKE1 drops HUB1 as a neighbour, then replies through HUB2.

Then break it

  • On HUB2, remove ip summary-address eigrp 100 0.0.0.0 0.0.0.0 from Tunnel10. SPOKE1 now has 10.0.0.0/24 via 172.16.10.2 only, as well as the default via both hubs. All traffic to the data centre goes through HUB2.
  • On INET, apply an inbound ACL on G0/2 that permits only ICMP and GRE (permit icmp any any, permit gre any any). Within 15 seconds SPOKE1 loses both EIGRP neighbours. Pings between the public addresses still work, and show crypto ipsec sa on SPOKE1 shows the encrypt counter rising and the decrypt counter stuck.
  • Remove ip nhrp registration no-unique from SPOKE2. Then give SPOKE2 a new public address: on INET add ip address 203.0.113.9 255.255.255.252 secondary to G0/3; on SPOKE2 change G0/0 to 203.0.113.10/30 and its VRF default to 203.0.113.9. IPsec to both hubs comes back, but SPOKE2 does not register. show ip nhrp on the hubs still maps 172.16.10.12 to 203.0.113.6, and SPOKE2 is unreachable until that entry expires, up to 10 minutes here.

A vPC pair with routed uplinks and a backup path

Advanced · about 90 minutes

Most data centre and many campus cores are now a pair of Nexus switches running vPC. It looks like a port-channel, but it has its own rules, and most vPC outages come from breaking one of them: the keepalive, the peer-link VLANs, a setting changed on one switch only, or a missing routed path between the two.

Kit: Two Nexus 9000v switches, one IOSvL2 access switch, one IOSv router as the core, and two PCs.

Tasks

  1. Turn on the features, give mgmt0 its addresses and configure the vPC domain on both switches. Prove the keepalive is alive before you build anything else.
  2. Build the peer-link. Check show vpc brief says peer adjacency formed ok.
  3. Build vPC 20 on both Nexus switches and the LACP port-channel on ACC. Prove ACC sees one partner on both links.
  4. Add the SVIs with HSRP, the routed uplinks to CORE, the routed backup link, and OSPF. Prove both PCs can reach 10.99.99.1.
  5. Test the failures: the peer-link, a whole switch, and one switch's uplink. Note what each switch does and why.

Checks

  • show vpc brief (N9K-1): Peer adjacency formed ok, peer is alive, consistency success, role primary, and vPC 20 up with active VLANs 10,20.
  • show lacp neighbor (ACC): Gi0/1 and Gi0/2 both report the same partner system ID, 0023.04ee.be0a: the vPC system MAC built from domain 10.
  • show spanning-tree vlan 10 (ACC): Po1 is the root port and forwarding. No blocked ports.
  • show hsrp brief (N9K-1 and N9K-2): N9K-1 active and N9K-2 standby for both groups.
  • show ip ospf neighbors (N9K-1): FULL to CORE on Eth1/4 and to N9K-2 on Eth1/5. No neighbours on Vlan10 or Vlan20.
  • Continuous ping from PC1 to 10.99.99.1, then shut Eth1/1-2 on N9K-1: N9K-2, the secondary, suspends vPC 20 and its SVIs. The ping carries on through N9K-1 after a short loss. Bring the peer-link back.
  • Reload N9K-1, then show vpc role on both: Traffic carries on through N9K-2 while N9K-1 reloads. When it returns, N9K-2 is operational primary and stays so, because vPC roles do not pre-empt.

Then break it

  • On N9K-2 only, set mtu 9216 on port-channel20. show vpc brief shows vPC 20 failing its consistency check, and show vpc consistency-parameters vpc 20 shows the MTU differing. N9K-2 suspends its leg of vPC 20, so ACC is left with one working link.
  • Shut mgmt0 on N9K-2. Wait a minute. Then shut Eth1/1-2 on N9K-1. With only mgmt0 down, nothing changes for traffic, and show vpc reports the peer as not alive. Once the peer-link goes too, each switch can no longer tell whether its partner is dead, and both end up acting as primary with their vPCs up.
  • Shut Eth1/4 on N9K-1 and test from both PCs. Then shut Eth1/5 on N9K-1 as well and test again. With only the uplink down, everything works: traffic that ACC hashes to N9K-1 is routed over Eth1/5 to N9K-2, and traceroute shows 10.255.0.2. With the backup link down too, whatever ACC hashes to N9K-1 is dropped. Which flows fail depends on the hash, so test from both PCs.

Ticket: the far LAN vanished after last night's change

Troubleshooting · about 45 minutes

A break-fix lab. Load the starting configs exactly as given. There are three faults, and each one on its own stops the routes appearing. Work bottom up and fix one thing at a time.

Kit: Three 2911 routers in a line, a PC and a server.

Tasks

  1. Load the starting configs. Confirm the symptom from PC1 first.
  2. Check each link at layer 1 to 3 before you look at OSPF.
  3. Find all three faults. Write down the evidence for each before you change anything.
  4. Fix them one at a time and re-test after each.

Checks

  • show ip ospf neighbor: When fixed: R2 shows FULL to both R1 and R3.
  • show ip ospf interface GigabitEthernet0/0 (R1 and R2): Hello 10, Dead 40 at both ends.
  • show ip protocols (R3): When fixed: G0/1 listed as passive, G0/0 not.
  • ping 192.168.3.10 (from PC1): Replies once all three are fixed.

Then break it

  • Fault 1 evidence No neighbour on R1-R2. "show ip ospf interface" shows Hello 5, Dead 20 on R2 and Hello 10, Dead 40 on R1.
  • Fault 2 evidence Once R3 sends hellos, R2 logs a mismatched area ID for packets from 10.10.23.2.
  • Fault 3 evidence R3 is not sending hellos on G0/0 at all; "show ip protocols" lists it as passive.

Ticket: the new branch has no network and no internet

Troubleshooting · about 60 minutes

A break-fix lab across DHCP, HSRP and NAT. There are four faults, and fixing each one reveals the next, which is how these tickets go in real life. Rules: do not change the PCs or the server, and do not add static routes on R1 or R2.

Kit: Three 2911 routers (R3 plays the provider), a 2960 switch, two PCs set to DHCP and a server.

Tasks

  1. Load the starting configs and set both PCs to DHCP. Confirm the symptom first.
  2. Work the ticket in order: addresses, then the gateway, then the internet. Write down the evidence for each fault before you change anything.
  3. Find all four faults. The ticket says what the design should be, so the design is your reference, not the configs.
  4. Fix one thing at a time and re-test from a PC after each. Finish by shutting R1 G0/0 to prove R2 takes over, then bring it back and watch R1 take the gateway back.

Checks

  • ipconfig (PC1 and PC2): An address from 192.168.10.10 upwards and gateway 192.168.10.1.
  • show standby brief (R1): R1 Active, R2 Standby, priority 110 on R1 and 100 on R2.
  • show ip nat translations (R1): icmp entries from 192.168.10.x to 203.0.113.65 while a PC pings the server.
  • ping 198.51.100.10 (from PC1): Replies, through R1.
  • shutdown R1 G0/0, then ping again: A few lost pings, then replies through R2, translated to 203.0.113.5.

Then break it

  • Fault 1 evidence The PCs get nothing (or a 169.254 address). show ip dhcp binding on R1 is empty, and debug ip dhcp server packet shows DISCOVERs but no OFFERs.
  • Fault 2 evidence Once the PCs have addresses, they reach the server, but show standby brief says R2 is Active. The ticket says R1.
  • Fault 3 evidence With R1 active, pings from the PCs fail. show ip nat translations on R1 is empty, and show access-lists shows no hits on 101.
  • Fault 4 evidence Translations to 203.0.113.65 now appear on R1, but the pings still fail. R3 has no route to 203.0.113.65 (show ip route 203.0.113.65).

Ticket: floor 1 has been slow since the cabling tidy-up

Troubleshooting · about 60 minutes

A layer 2 break-fix lab across spanning tree, EtherChannel and trunks. There are four faults. Two show up as complaints, one only when you test resilience, and one sits quietly in the logs. Rules: do not change the PCs, and do not change any port or cable assignments.

Kit: A 3560-24PS (DS1, the gateway), two 2960-24TT access switches and four PCs with static addresses.

Tasks

  1. Build the topology, paste the starting configs and set the PC addresses. Wait a minute for spanning tree to settle, then confirm both complaints: where does floor 1 traffic actually go, and what happens to PC2 when you shut AS1 Fa0/24?
  2. Use the design rules above as the reference, not the configs. For each fault, write down the evidence before you change anything.
  3. Fix one thing at a time. After each fix, re-check the spanning tree on all three switches, because each fault changes the tree.
  4. Finish with the resilience test: shut AS1 Fa0/24 and prove all four PCs can still reach each other and both gateways, then bring it back.

Checks

  • show spanning-tree vlan 10 (DS1): "This bridge is the root", priority 24586 (24576 plus the VLAN number). Same for VLANs 20 and 99.
  • show etherchannel summary (AS1 and DS1): Po1(SU) with Gi0/1(P) and Gi0/2(P), protocol LACP.
  • show spanning-tree vlan 20 (AS1): Root port Po1. Fa0/24 is designated and forwarding.
  • show spanning-tree vlan 20 (AS2): Root port Gi0/1. Fa0/24 is the alternate port, blocking.
  • show interfaces trunk (DS1): Po1 and Fa0/24 both native 99, both allowing 10, 20 and 99.
  • shutdown AS1 Fa0/24, then ping 10.10.20.1 and 10.10.10.12 from PC2: Both reply, with no loss after the first try. Bring Fa0/24 back afterwards.
  • Watch the DS1 console for five minutes: No more %CDP-4-NATIVE_VLAN_MISMATCH messages.

Then break it

  • Fault 1 evidence show spanning-tree vlan 10 on any switch names AS2 as the root, priority 4106. On AS1 the root port is Fa0/24, the 100 Mb spare, and both gigabit links are blocking.
  • Fault 2 evidence With the root fixed, show etherchannel summary shows Po1 down and the gigabit ports as (I), individual. Spanning tree forwards on Gi0/1 and blocks Gi0/2, so floor 1 gets half the bandwidth it was promised.
  • Fault 3 evidence Everything works until you shut AS1 Fa0/24. Then PC2 loses its gateway while PC1 is fine. show interfaces trunk on DS1 shows Po1 allowing only 10 and 99, and show spanning-tree vlan 20 on AS1 had the spare as its root port all along.
  • Fault 4 evidence DS1 logs %CDP-4-NATIVE_VLAN_MISMATCH for Fa0/24. show interfaces trunk shows native 99 on DS1 and native 1 on AS2 Gi0/1.

Ticket: R1 was replaced and nobody can log in to it

Troubleshooting · about 45 minutes

A management access break-fix lab: SSH, TACACS+ with local fallback, and VTY lines. There are four faults, three that stop people logging in and one an auditor found. Rules: AAA1 is correct, so change only R1.

Kit: A 2911 router, a 2960 switch, a jump host PC, a user PC and a server running the AAA service.

Tasks

  1. Build AAA1 the way the server team did, then leave it alone: Services, AAA, service on; client R1, 192.168.50.1, key LabKey-2026, type TACACS; user netadmin with password LabUser-2026.
  2. Paste the R1 starting config and read every line it prints back. A restored backup tells you what it could not apply.
  3. Confirm the symptom from JUMP (ssh -l netadmin 192.168.50.1), then work through the faults. Write down the evidence for each before you change anything.
  4. Fix one thing at a time and test from JUMP after each. Finish with the fallback test: switch off AAA1's switch port and prove breakglass works, then bring it back.

Checks

  • show ip ssh (R1): SSH Enabled, version 2.0.
  • ssh -l netadmin 192.168.50.1 (from JUMP): Logs in with LabUser-2026, straight away, with no pause.
  • ssh -l netadmin 192.168.10.1 and telnet 192.168.10.1 (from USERPC): Both refused.
  • show running-config | section line vty (R1): access-class 10 in and transport input ssh on every line, 0 to 15.
  • shutdown SW1 Fa0/3, then ssh -l breakglass 192.168.50.1 from JUMP: Logs in after a short wait while R1 gives up on AAA1. netadmin does not work. Bring Fa0/3 back.
  • With AAA1 back, ssh -l breakglass 192.168.50.1: On real IOS this is rejected: AAA1 answers "no such user" and a reject is final. Packet Tracer does not always copy this exactly, so treat real IOS as the reference.

Then break it

  • Fault 1 evidence JUMP gets "Connection refused". show ip ssh says SSH Disabled, and the paste printed "Please create RSA keys to enable SSH" against the ip ssh version 2 line.
  • Fault 2 evidence SSH now connects, but netadmin fails after a long pause. breakglass gets in after the same pause. show tacacs lists 192.168.50.30 with failed connections, and R1 has no ARP entry for it.
  • Fault 3 evidence With the server address fixed, netadmin still fails, now without the pause. On real IOS, debug tacacs reports invalid packets and says to check the keys. In Packet Tracer, compare R1's key with the client entry on AAA1.
  • Fault 4 evidence show running-config | section line vty: lines 0 to 4 are locked down, but lines 5 to 15 take Telnet and have no access-class.

Ticket: the branch has no internet, and failover was never tested

Troubleshooting · about 75 minutes

A BGP break-fix lab on a branch with two internet hubs. There are four faults. One stops everything, one only shows when the main line fails, one only once that is fixed, and one only when the main line comes back. Rules: do not change INET, and do not add static routes on BR.

Kit: Four IOSv routers (INET plays both ISPs and holds the test address on a loopback) and a PC or desktop node.

Tasks

  1. Build the topology with IOSv, or any IOS 15 or IOS XE image with the interface names changed. Paste the starting configs, address PC1, and confirm the symptom.
  2. Use the design as the reference, not the configs. Write down the evidence for each fault before you change anything.
  3. Test failover the way an ISP fails: shut INET G0/0 and HUB1 G0/1 together. In a simulator, shutting one end of a link does not always bring the other end down. Allow up to a minute for BGP to react.
  4. Bring ISP A back (no shutdown on both) and prove the branch returns to HUB1. If it does not, that is the last fault.

Checks

  • show ip bgp (BR): Two paths to 0.0.0.0. The best is via 10.255.1.1 with LocPrf 200.
  • show ip bgp 10.20.1.0 (HUB1 and HUB2): The branch LAN, learned from BR with AS path 64512.
  • ping 198.51.100.10 and traceroute 198.51.100.10 (PC1): Replies. The hop after BR is 10.255.1.1.
  • shut INET G0/0 and HUB1 G0/1, wait, then show ip bgp (BR) and ping again: One default, via 10.255.2.1. The ping still replies.
  • no shut both, wait, then show ip bgp (BR): Best path back via 10.255.1.1, LocPrf 200.

Then break it

  • Fault 1 evidence PC1 cannot reach 198.51.100.10 at all. show ip bgp on BR has no entry for the branch LAN, and on HUB1, show ip route 10.20.1.10 finds only the default route, so replies go back towards INET.
  • Fault 2 evidence With ISP A down, BR still has 0.0.0.0 via 10.255.1.1 as its best path, and traceroute from PC1 dies at HUB1.
  • Fault 3 evidence Once HUB1 withdraws its default, BR has no default at all. HUB2 has a static default in its routing table, but show ip bgp on HUB2 has no 0.0.0.0.
  • Fault 4 evidence With both lines up, BR's best default is via 10.255.2.1. show ip bgp shows LocPrf 200 on the paths from HUB2.

Ticket: after last night's hardening, staff get no addresses

Troubleshooting · about 50 minutes

A switch security break-fix lab: DHCP snooping, option 82 and port security. There are four faults. Two stop DHCP, one kills the meeting room port, and one leaves the door open that the hardening was meant to close. Rules: change only SW1, and do not turn snooping off.

Kit: A 2911 router (DHCP server for both VLANs), a 2960 switch, a hub standing in for the meeting room desk switch, four PCs, and a server playing the auditor's rogue DHCP server.

Tasks

  1. Build the topology, paste the configs, set every PC to DHCP and leave ROGUE's DHCP service off. Confirm the symptom: PC1 gets nothing, PC2 gets a 10.1.20.x address, and Fa0/5 is down.
  2. Follow one DISCOVER from PC1 to R1 and back. Where is it changed, and where is it dropped? Write the evidence down before you change anything.
  3. Fix one thing at a time, and renew PC1 after each (ipconfig /renew in the PC command prompt).
  4. Finish with the auditor's test: give ROGUE a DHCP pool of 10.99.99.0/24, switch its service on, renew PC2, and prove PC2 still gets a 10.1.20.x address.

Checks

  • show ip dhcp snooping (SW1): Snooping on for VLANs 10 and 20, option insertion disabled, and only Gi0/1 trusted.
  • ipconfig (PC1, PC2, MR1, MR2): PC1, MR1 and MR2 in 10.1.10.10 and up, PC2 in 10.1.20.10 and up, each with gateway .1.
  • show ip dhcp snooping binding (SW1): One binding per PC, on the right port and VLAN.
  • show port-security interface FastEthernet0/5: Secure-up, maximum 3, two addresses learned.
  • ROGUE DHCP on, then ipconfig /renew on PC2: PC2 still gets 10.1.20.x. show ip dhcp snooping statistics counts the dropped offers from Fa0/20.

Then break it

  • Fault 1 evidence PC1 gets nothing. debug ip dhcp server packet on R1 shows each DISCOVER rejected as inconsistent relay information: option 82 is present but the relay address (giaddr) is zero. R1 never sends an OFFER. VLAN 20 is not snooped, so its requests arrive untouched, which is why Finance works.
  • Fault 2 evidence R1 now sends OFFERs, and show ip dhcp server statistics counts them, but PC1 still gets nothing. show ip dhcp snooping lists no trusted interfaces, and the statistics show packets dropped.
  • Fault 3 evidence show interfaces status err-disabled lists Fa0/5 as psecure-violation. show port-security interface Fa0/5 shows maximum 1 and a violation count.
  • Fault 4 evidence With ROGUE's DHCP service on, PC2 can get a 10.99.99.x address. show ip dhcp snooping lists only VLAN 10.

Ticket: the new branch cannot reach the data centre over the DMVPN

Troubleshooting · about 75 minutes

A break-fix lab on a dual-hub DMVPN with IPsec. There are four faults, and fixing one reveals the next. Rules: do not change INET, the server or the PCs, and do not add static routes.

Kit: Five IOSv routers (INET plays the internet), an unmanaged switch, a server and two PCs.

Tasks

  1. Load the starting configs and confirm the symptom from both PCs.
  2. Work from the bottom up on each path that fails: internet reachability, IKE, IPsec, NHRP registration, routing neighbours, then the forwarding path. Write down the evidence for each fault before you change anything.
  3. Find all four faults. The ticket and the design are your reference, not the configs.
  4. Fix one thing at a time and re-test. Finish by shutting HUB1 G0/0 to prove both branches survive on HUB2, then traceroute between the PCs in both directions.

Checks

  • show dmvpn (SPOKE1 and SPOKE2): Both hubs UP on each spoke.
  • show ip eigrp neighbors (SPOKE1 and SPOKE2): Two neighbours each: 172.16.10.1 and 172.16.10.2.
  • ping 10.0.0.10 (from PC2): Replies.
  • traceroute 10.1.2.10 from PC1, and 10.1.1.10 from PC2, each twice: The second run in each direction has no hub address in it.
  • shut HUB1 G0/0, then ping 10.0.0.10 from both PCs: Replies through HUB2 after at most 15 seconds.

Then break it

  • Fault 1 evidence show crypto isakmp sa on SPOKE1 shows QM_IDLE to 198.51.100.2 but MM_NO_STATE to 198.51.100.6. ping vrf INET 198.51.100.6 works. debug crypto isakmp on HUB2 says it has no pre-shared key for the spoke.
  • Fault 2 evidence SPOKE2 has IPsec up to HUB1, and show crypto ipsec sa shows its encrypt counter rising. But show dmvpn on HUB1 has no entry for 172.16.10.12, and show interfaces Tunnel10 on SPOKE2 shows key 12 where the hubs use 10.
  • Fault 3 evidence With fault 1 fixed, both spokes register with HUB2 (show dmvpn shows it UP) but form no EIGRP neighbour with it. HUB2 logs neighbours going down with "retry limit exceeded", and show ip nhrp multicast on HUB2 is empty, where HUB1 lists both spokes.
  • Fault 4 evidence With branch 2 working, traceroute from PC2 to PC1 goes direct on the second attempt, but from PC1 to PC2 it always passes through a hub. show ip route nhrp lists 10.1.1.0/24 on SPOKE2 and nothing on SPOKE1.