Lab Objective
Diagnose and resolve three independently introduced faults across a small multi-device topology — a VLAN mismatch, a static route pointing at the wrong next hop, and a missing NAT interface designation — using the systematic troubleshooting methodology covered earlier in this series.
Lab Purpose
Real-world outages rarely involve a single, isolated misconfiguration. This lab combines faults across three different layers and technologies simultaneously, requiring the same layer-by-layer diagnostic discipline covered in the troubleshooting methodology article, rather than any single specific command or fix.
Lab Topology
PC-A (VLAN 10) ---- Switch1 ---- R1 ---- R2 (simulated ISP)
|
Internal server (NAT'd)
Expected working state:
- PC-A should reach R1's SVI (its gateway)
- R1 should route toward R2 for any external
destination
- The internal server should be reachable
from "outside" via its NAT'd public address
Three faults have been deliberately introduced
somewhere in this topologyTask 1: Confirm the Reported Symptom
PC-A reports it cannot reach the internet, and external testers report the internal server is unreachable via its public address. Confirm both symptoms.
Task 2: Apply Bottom-Up Troubleshooting Starting at Layer 1/2
Check physical and Layer 2 status on the path from PC-A toward R1.
Task 3: Continue Through Layer 3
Once Layer 2 is confirmed healthy, verify R1's routing table and static route configuration toward R2.
Task 4: Check NAT Configuration
Once basic routing is confirmed working, verify the NAT configuration allowing the internal server to be reached externally.
Task 5: Verify All Symptoms Are Resolved
Confirm PC-A can reach the internet and the internal server is reachable from outside.
Solution and Verification
PC-A> ping 8.8.8.8
Request timed out.
ExternalTester> curl http://[server's public IP]
Connection timed out.
-- Both symptoms confirmed as reported-- Fault 1: Layer 2 check
Switch1# show vlan brief
VLAN Name Status Ports
10 Data active Gi1/0/2
20 Servers active Gi1/0/1
Switch1# show interfaces gigabitethernet1/0/2 switchport | include VLAN
Access Mode VLAN: 20 (Servers)
-- PC-A is physically connected expecting
-- VLAN 10, but the port is assigned to
-- VLAN 20 -- FAULT 1 IDENTIFIED
Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# switchport access vlan 10
-- Corrected-- Fault 2: Layer 3 check
PC-A> ping 192.168.1.1
Reply from 192.168.1.1
-- Gateway now reachable after fixing VLAN
R1# show ip route
S* 0.0.0.0/0 [1/0] via 203.0.113.99
-- Comparing against the documented design
-- (R2's address should be 203.0.113.2):
-- FAULT 2 IDENTIFIED -- wrong next hop
R1(config)# no ip route 0.0.0.0 0.0.0.0 203.0.113.99
R1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.2
-- Corrected
PC-A> ping 8.8.8.8
!!!!!
Success rate is 100 percent (5/5)
-- First reported symptom now resolved-- Fault 3: NAT check
R1# show ip nat translations
-- (no output, even after generating traffic)
R1# show ip interface gigabitethernet0/1 | include NAT
NAT: not enabled
-- FAULT 3 IDENTIFIED -- the inside interface
-- was never marked as NAT inside
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip nat inside
-- Corrected (outside interface was already
-- correctly marked)
ExternalTester> curl http://[server's public IP]
-- Successful connectionKey Takeaway
Each fault in this lab produced a distinct signature at a specific layer — a VLAN mismatch visible in switchport status, a routing fault visible in the routing table's next hop, and a NAT fault visible as a missing interface designation — reinforcing that systematic, layer-by-layer verification isolates each independent problem efficiently, rather than randomly guessing at a single root cause when multiple unrelated faults exist simultaneously.