A real-world troubleshooting challenge — built a complex multi-site WAN topology, diagnosed IP overlap errors and missing return routes, and restored full bidirectional connectivity across 6 subnets using systematic Cisco IOS fault-isolation techniques.
Unlike labs that work perfectly from the start, this project reflects real-world networking — things break, and engineers must diagnose and fix them under pressure. This topology started with connectivity failures, 75% packet loss, and IP overlap errors before being fully resolved.
The key skills demonstrated here are not just configuration, but systematic troubleshooting: reading routing tables, identifying missing routes, spotting interface misconfigurations, and verifying fixes with ping and show commands.
The multi-site WAN topology built in Cisco Packet Tracer 8.2. The network spans 4 routers (R1, R2, R3 — Cisco ISR4331, and R4 — Cisco 2901), 2 switches (Switch3, Switch4, Switch5 — Cisco 2960-24TT), 2 servers (Server0, Server1), and end-user PCs (PC3, PC4, PC5) across 6 subnets. Orange link indicators show interfaces still initialising at startup — not yet fully connected.
R1's routing table after initial configuration. R1 has GigabitEthernet0/0/0 at 192.168.1.1 (LAN) and Serial0/1/0 at 192.168.2.1 (WAN). Static routes to 192.168.3.0/24, 192.168.4.0/24, and 192.168.5.0/24 are configured via next-hop 192.168.2.2. At this stage the remote subnets 192.168.4.0 and 192.168.5.0 are reachable via R2 — but full end-to-end reachability is not yet verified.
R2's routing table showing static routes and a default route (S* 0.0.0.0/0 via 192.168.2.1). R2 knows about 192.168.1.0/24 via R1, is directly connected to 192.168.2.0/24 and 192.168.3.0/24, and has routes to 192.168.4.0/24 and 192.168.5.0/24 via R3. The default route via 192.168.2.1 sends all unknown traffic back toward R1 — a key design decision for this topology.
R3's routing table confirms static routes to all remote subnets. R3 has static routes to 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 via next-hop 192.168.4.1 (R2). R3 is directly connected to 192.168.4.0/24 (Serial WAN to R2), 192.168.5.0/24 (LAN via GigabitEthernet), and 192.168.6.0/24 (Serial WAN to R4). This confirms R3 has full routing awareness of the network.
Static routes must be configured on ALL routers bidirectionally. A one-way route means traffic can reach a destination but replies have no path back — causing silent failures.
Running 'show ip interface brief' on R1 reveals a problem. GigabitEthernet0/0/0 is UP at 192.168.1.1 and Serial0/1/0 is UP at 192.168.2.1 — but GigabitEthernet0/0/1 is administratively down and shows no IP address. This is the first sign of a misconfiguration — PC3 is connected to Gi0/0/1 which is down, causing PC3 connectivity to fail completely.
Always run 'show ip interface brief' first when troubleshooting. Administratively down interfaces are a common cause of connectivity failures and are immediately visible in this output.
During the fix attempt on R1, a critical error appears: '% 192.168.1.0 overlaps with GigabitEthernet0/0/0'. Trying to assign 192.168.1.1/24 to Gi0/0/1 fails because Gi0/0/0 already owns that subnet. This confirms the interface was wrongly configured. The correct fix was to bring up Gi0/0/1 with a unique subnet (192.168.1.2/24 for the PC3 segment) and update the routing table accordingly.
Assigning the same subnet to two interfaces on the same router causes an overlap error. Each interface must belong to a unique, non-overlapping subnet — a fundamental rule of IP addressing.
After the interface fix, PC3 attempts to ping 192.168.1.1. Result: 1 out of 4 packets received — 75% packet loss. The single successful reply confirms routing is partially working but the path is unstable. This indicates a timing issue during interface convergence or a missing return route somewhere in the chain. Further investigation is needed on R4 which still had no return routes at this stage.
75% packet loss with one successful reply indicates partial convergence. This pattern points to a missing return route rather than a complete misconfiguration — the path exists one way but not the other.
After adding missing static return routes on R4 and allowing interfaces to fully converge, PC3 successfully pings both 192.168.1.1 (R1 LAN) and 192.168.3.1 (R2 LAN). Both return 4/4 packets with 0% loss. The 192.168.3.1 ping shows 10–17ms round-trip time — confirming traffic is traversing multiple routers across the WAN links. Full bidirectional reachability is now established.
0% packet loss across multiple hops confirms full bidirectional routing. The 10–17ms RTT to 192.168.3.1 proves traffic is traversing multiple WAN Serial links and returning correctly.
R4's routing table before the final fix shows only directly connected routes — 192.168.6.0/24 via Serial0/3/0. R4 had no knowledge of any remote subnets, meaning return traffic from Server1 (connected to R4) had nowhere to go. Static return routes to all five remote subnets (192.168.1–5.0/24) were added via next-hop 192.168.6.2 (R3), restoring full bidirectional end-to-end connectivity across all 6 subnets.
R4 had no static return routes — it could receive packets but had no path to send replies back. Adding return routes to all 5 remote subnets via 192.168.6.2 was the final fix that completed the network.
The completed network topology with all links showing green — confirming every interface is UP and all routes are converged. All 4 routers, 3 switches, 2 servers, and 3 PCs are fully connected across 6 subnets. The network successfully demonstrates multi-site static routing, WAN troubleshooting, IP overlap diagnosis, missing route identification, and full end-to-end reachability verification using Cisco IOS ping and show commands.
