The final exam of the series. Take the campus you built in part 24, hand it to a colleague (or your own future self), and let them plant these eight faults while you're not looking. Then sit down with the tickets — "guests can't get online in the west wing" — and find every one, using nothing but show commands and a method. This is the closest a lab gets to a real Tuesday.
Building a network teaches you commands. Fixing one teaches you the network. Troubleshooting is a search problem, and amateurs search badly — they jump to the layer they last read about, change three things at once, and can't say afterwards what the fault was. Professionals compress the search space methodically: which users, which VLANs, which switch, which layer? Every answer halves the territory.
This scenario gives you eight faults planted in the part-24 campus, presented the way reality presents them — as user complaints, not config diffs. For each: the ticket, the diagnosis walk with real command output, the root cause, the fix, and the habit to keep. Do it honestly: load your saved part-24 file, have someone (or a random-number generator and this list) break it, and work the tickets before reading each answer.
01
Before any command: turn the complaint into a boundary. What works, what doesn't, and where is the line between them? The fault always lives on the line.
Three questions turn a vague ticket into a located fault:
1. Scope — one user, one switch's users, one VLAN everywhere, or everyone? One user = port problem. One switch = that switch or its uplinks. One VLAN across switches = SVI/gateway/DHCP for that VLAN. Everyone = edge or core. You've eliminated ~80% of the network before touching a keyboard.
2. Layer — walk up from the bottom, and stop at the first broken layer: link light (show interfaces status) → VLAN membership → can it reach its gateway? → does it have a DHCP lease? → can it reach the internet? Each test assumes the ones below it passed.
3. What changed? — networks don't rot; they get changed. show logging is the closest thing to a confession you'll get.
The iron rule when you start fixing: change one thing, retest, write it down. Fix two things at once and something starts working, and you've learned nothing — worse, one of your two changes may be a new latent fault. In Packet Tracer this discipline feels pedantic. At 2 a.m. on a production switch it's the difference between an incident report and a second incident.
02
The two smallest scopes — a single user, then a single switch's guests. Access-layer faults, found from the access layer.
ACC-1# show interfaces status | include Fa0/7 Fa0/7 room114 connected 100 a-full a-100 10/100BaseTX ↑ VLAN 100? The staff VLAN is 10. ACC-1# show vlan brief | include 100 100 VLAN0100 active Fa0/7 ← VLAN 100 exists but routes nowhere — a typo'd access VLAN, classic fat-finger ACC-1(config)# interface Fa0/7 ACC-1(config-if)# switchport access vlan 10 ← fixed; PC pulls DHCP instantly
Root cause: switchport access vlan 100 instead of 10. IOS "helpfully" created VLAN 100 when it was assigned, so nothing even logged an error. Habit: after any port change, show interfaces status — the VLAN column catches typos your eyes skipped in config mode.
ACC-2# show interfaces status err-disabled Port Name Status Reason Fa0/18 err-disabled bpduguard ACC-2# show logging | include Fa0/18 %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/18 with BPDU Guard enabled. Disabling port. # The contractor's box was a cheap switch — it spoke STP, BPDU Guard fired. # Remove the offending device, then: ACC-2(config)# interface Fa0/18 ACC-2(config-if)# shutdown ACC-2(config-if)# no shutdown ← err-disabled needs a manual bounce
Root cause: none — the network worked. BPDU Guard (part 6) did exactly its job when a rogue switch appeared; the "fault" is that nobody knew what err-disabled means. Habit: show interfaces status err-disabled belongs in your first-five commands on any "port suddenly dead" ticket, and the Reason column names the guilty protection.
03
Scope: "one VLAN, one switch" and "weird noise in the logs". Both are trunk misconfigurations — the place where a fault can hide because most traffic still flows.
Guests (VLAN 20) work on ACC-1, fail on ACC-2 — but staff on ACC-2 are fine. One VLAN, one switch, other VLANs healthy: that's a trunk carrying a partial VLAN list.
ACC-2# show interfaces trunk Port Vlans allowed on trunk Gi0/1 10,30,99 ← 20 is missing. Someone "cleaned up" the allowed list and dropped GUEST. Gi0/2 10,20,30,99 ← the CORE-2 uplink still has it — but STP blocks that path in steady state, so no luck ACC-2(config)# interface Gi0/1 ACC-2(config-if)# switchport trunk allowed vlan add 20 ← ADD, not a bare list!
Root cause: an edited allowed-VLAN list. Note the fix uses add — typing switchport trunk allowed vlan 20 would replace the whole list with just 20 and take the other three VLANs down with it. That one missing word has caused real outages everywhere. Habit: when one VLAN dies on one switch, show interfaces trunk before anything else.
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/2 (99), with CORE-2 GigabitEthernet1/0/2 (1). # CORE-2's downlink was rebuilt and lost its native-vlan setting: CORE-2(config)# interface GigabitEthernet1/0/2 CORE-2(config-if)# switchport trunk native vlan 99
Root cause: native VLAN 99 on one end, 1 on the other. Untagged frames — including some control traffic — cross the trunk and land in different VLANs on each side. Today it's log noise; the day someone actually uses those VLANs, it becomes a leak between segments that no ACL saw coming. Habit: warnings that "don't break anything" are faults with a delayed fuse. Fix them the day they appear.
04
Scope: one VLAN everywhere, or intermittent everything. When the access layer checks out, suspect the things both cores must agree on — HSRP and the DHCP relay.
CORE-1# show standby brief Interface Grp Pri P State Active Standby Virtual IP Vl10 10 110 P Active local unknown 10.10.10.1 ↑ CORE-1 can't see its peer… CORE-2# show standby brief Vl10 10 90 P Active local unknown 10.10.10.1 # BOTH claim Active for the same VIP = split brain. HSRP hellos aren't # crossing the interlink. Is VLAN 10 still allowed on Po1? CORE-1# show interfaces trunk | include Po1 Po1 20,30,99 ← VLAN 10 pruned from the port-channel! CORE-1(config)# interface Port-channel1 CORE-1(config-if)# switchport trunk allowed vlan add 10
Root cause: VLAN 10 was dropped from the interlink trunk, so the two cores stopped hearing each other's HSRP hellos on that VLAN and both went active — duplicate virtual MAC, ARP chaos, intermittent everything. Habit: "two Actives" in show standby brief never means HSRP is broken; it means the path between the peers is. Chase the trunk, not the protocol.
CORE-2# show running-config interface vlan 30 interface Vlan30 ip address 10.10.30.3 255.255.255.0 standby 30 ip 10.10.30.1 standby 30 priority 110 standby 30 preempt # No ip helper-address — and CORE-2 is the ACTIVE gateway for VLAN 30, # so it's the router that receives (and drops) every phone's DISCOVER. CORE-2(config)# interface vlan 30 CORE-2(config-if)# ip helper-address 10.255.0.5
Root cause: the helper was configured on CORE-1 (standby for VLAN 30) but forgotten on CORE-2 (active). Broadcasts die at the active gateway; a relay on the standby helps nobody. A 169.254.x.x self-assigned address is always the same sentence: "my DHCP broadcast got no answer" — the fault is the relay, the trunk to the DHCP server, or the pool, in that order of likelihood. Habit: anything configured per-SVI must exist on both cores — audit with show run | include helper on each.
05
Scope: "we can reach everything internal, but not the internet" — the boundary is EDGE, and the two usual suspects there are NAT and the return route.
# From a phone: ping 10.255.0.1 works (internal routing fine), 8.8.8.8 dies. # On EDGE — is NAT translating VLAN 30 at all? EDGE# show ip nat translations | include 10.10.30 (nothing) EDGE# show access-list 1 Standard IP access list 1 10 permit 10.10.10.0, wildcard bits 0.0.0.255 (8231 matches) 20 permit 10.10.20.0, wildcard bits 0.0.0.255 (5044 matches) # The NAT ACL enumerates subnets — and VLAN 30 was added to the network # after the ACL was written. Packets route to EDGE, fail the ACL, exit # UNTRANSLATED with a 10.x source, and the ISP silently discards them. EDGE(config)# access-list 1 permit 10.10.30.0 0.0.0.255
Root cause: a NAT ACL written as a list of specific subnets instead of the 10.10.0.0 0.0.255.255 summary from part 24 — so every future VLAN is born broken. Habit: "internal works, internet doesn't, for one subnet" is a NAT-scope problem until proven otherwise, and show ip nat translations filtered by the subnet settles it in one command.
EDGE# show ip route | include 10.10.0.0 S 10.10.0.0/16 [1/0] via 10.255.0.2 S 10.10.0.0/16 [1/0] via 10.255.0.9 ← .9? Our core links are .2 and .6 — a mistyped next-hop from the weekend # Half of EDGE's return traffic (ECMP alternates flows) is routed at a # next-hop that answers ARP for nothing. Those flows die; the rest work. EDGE(config)# no ip route 10.10.0.0 255.255.0.0 10.255.0.9 EDGE(config)# ip route 10.10.0.0 255.255.0.0 10.255.0.6
Root cause: a fat-fingered static during maintenance. The cruel detail: with ECMP, half the flows still work, so the network feels "slow and flaky" rather than "down", and everyone blames Wi-Fi for a day. Habit: "intermittent by session, consistent per session" screams one of several equal paths is broken. Check every ECMP next-hop; a route that installs is not a route that works.
06
Eight tickets distilled into the reflex table. The first command doesn't find every fault — it eliminates half the possibilities in ten seconds, which is better.
| Symptom | First command & what it rules out |
|---|---|
| One user dead | show interfaces status — link, speed/duplex, and the VLAN column (ticket 1) |
| Port suddenly dead after someone plugged in | show interfaces status err-disabled — protections that fired, by name (ticket 2) |
| One VLAN dead on one switch only | show interfaces trunk — allowed lists on every uplink (ticket 3) |
| Native-VLAN log noise | show interfaces trunk on both ends — native columns must match (ticket 4) |
| Everyone intermittent / ARP weirdness | show standby brief on BOTH cores — two Actives = broken peer path (ticket 5) |
| Clients on 169.254.x.x | show run interface vlan N on the ACTIVE core — helper-address present? (ticket 6) |
| Internal fine, internet dead, one subnet | show ip nat translations | include <subnet> — NAT scope (ticket 7) |
| Flaky per-flow after a change | show ip route — verify every ECMP next-hop actually exists (ticket 8) |
The best version of this lab is adversarial: two people, one Packet Tracer file. Each plants two faults from this list (or invents ones in the same spirit — config-only, no deleted cables), saves, and swaps. Score by tickets closed per thirty minutes, and require a written root cause for each — "I reloaded it and it works now" scores zero. This is, not coincidentally, exactly how we interview network engineers at NOCTIS.
Takeaways
allowed vlan add.NOCTIS troubleshoots and rehabilitates business networks across Crete — root-cause diagnosis, not reboot-and-hope, with a written report of what was wrong and what we changed. And if it's the whole series applied: we build them too.
Book a Discovery Call →