WAN outages are the kind of problem that get an engineer paged at 2 a.m., and I have been on the receiving end of that call more times than I care to count. Over the years I have developed a fairly consistent methodology for diagnosing WAN connectivity issues on Cisco routers, whether the circuit is MPLS, a leased line, a broadband internet handoff, or a point-to-point Metro Ethernet link. In this guide I want to share that methodology in full, starting with the fundamentals and working up to the advanced diagnostic techniques I rely on in enterprise networks.
Networking Fundamentals: What “WAN Connectivity” Actually Means
A WAN link on a Cisco router usually terminates in one of a few common ways:
- A physical serial or T1/E1 interface (legacy, but still out there)
- An Ethernet handoff from a provider (very common today for MPLS and internet circuits)
- A DSL, cable, or cellular (LTE/5G) interface for branch connectivity
- A GRE or IPsec tunnel riding over an underlying internet connection (SD-WAN style overlays)
Regardless of the physical medium, WAN troubleshooting follows the OSI model bottom-up: physical layer, data link layer, network layer, then application/service layer. I have found that engineers who skip straight to “let me ping and see” often miss an obvious Layer 1 problem that would have taken ten seconds to spot.
Step 1: Verify Layer 1 and Layer 2 Status
The very first thing I check is interface status:
Router# show interface GigabitEthernet0/0/1
I am looking specifically at:
line protocol is up/down- Input/output errors, CRC errors, collisions
- Carrier transitions (a high count suggests a flapping physical link)
If the interface is administratively down, that is an easy fix — someone forgot to no shutdown it. If it is down/down, that is almost always a physical layer problem: bad cable, SFP mismatch, or a carrier-side issue. If it is up/down (line protocol down while the interface itself is up), that usually points to a Layer 2 encapsulation mismatch or a keepalive/clock issue on serial links.
For serial interfaces specifically, I check clocking:
Router# show controllers serial0/0/0
Step 2: Check Routing Protocol Adjacencies
Once Layer 1/2 is confirmed healthy, I move to routing. Depending on the WAN design, this could be BGP with a provider, OSPF/EIGRP internally, or static routes.
For BGP:
Router# show ip bgp summary
I look at the state column. Idle, Active, or a low uptime with flapping tells me the session is not stable. Common causes include:
- TCP port 179 blocked somewhere in the path
- Mismatched AS numbers
- Authentication mismatch (MD5 password)
- MTU mismatch causing large updates to be silently dropped
For OSPF neighbor issues over WAN links:
Router# show ip ospf neighbor
If neighbors are stuck in EXSTART or EXCHANGE, this is a classic MTU mismatch symptom — one side’s OSPF database description packets are too large and get dropped.
Step 3: Confirm End-to-End Reachability
With Layer 2 and routing confirmed, I validate actual reachability using extended ping and traceroute, sourcing from the correct interface to avoid asymmetric routing confusion:
Router# ping 8.8.8.8 source GigabitEthernet0/0/1
Router# traceroute 8.8.8.8 source GigabitEthernet0/0/1
If ping fails but the interface and routing look fine, I check for an ACL or zone-based firewall policy silently dropping ICMP, and I check NAT translations if the router is doing NAT at the WAN edge:
Router# show ip nat translations
Router# show access-lists
Step 4: Diagnose Intermittent or Degraded WAN Performance
Not every WAN issue is a hard outage. Slow application performance, jitter, and packet loss are common complaints, especially with VoIP or video over the WAN. My approach here:
- Baseline the circuit with extended pings including size and count:
Router# ping 8.8.8.8 size 1400 repeat 100
- Check for interface errors accumulating over time, not just a single snapshot:
Router# show interface GigabitEthernet0/0/1 | include error
- Check QoS policy application and drops if QoS is configured on the WAN edge:
Router# show policy-map interface GigabitEthernet0/0/1
- For provider-suspected issues, I use IP SLA to continuously measure latency, jitter, and loss so I have hard data when opening a carrier ticket:
Router(config)# ip sla 1
Router(config-ip-sla)# udp-jitter 203.0.113.1 16384
Router(config-ip-sla)# frequency 30
Router(config)# ip sla schedule 1 life forever start-time now
Router# show ip sla statistics
Having this kind of objective, timestamped data has saved me countless arguments with carriers who initially claimed “everything looks fine on our end.”
Real-World Enterprise Scenario: Dual WAN with Failover
A scenario I encounter constantly is a branch site with two WAN circuits — say, an MPLS primary and a broadband internet backup — configured with either PBR (policy-based routing) or a routing protocol with different administrative distances for failover.
When failover does not happen as expected, my checklist is:
- Confirm the primary route is actually being removed from the routing table when the circuit fails (not just the interface going down, but the routing protocol converging):
Router# show ip route 0.0.0.0
- Check tracking objects if IP SLA-based tracking is used to trigger failover:
Router# show track 1
- Verify the backup route’s administrative distance is correctly higher than the primary, or the router will always prefer the wrong path once both are technically reachable:
Router(config)# ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/2 200
Advanced Diagnostics: Packet Capture on the WAN Edge
When show commands are not enough, I capture traffic directly on the router using embedded packet capture (EPC):
Router(config)# monitor capture WANCAP interface GigabitEthernet0/0/1 both
Router(config)# monitor capture WANCAP match any
Router# monitor capture WANCAP start
Router# monitor capture WANCAP stop
Router# show monitor capture WANCAP buffer detail
This has repeatedly helped me catch problems like malformed BGP updates, unexpected fragmentation, or asymmetric traffic patterns that show commands alone could not reveal.
Common Configuration Mistakes
- MTU mismatches between the router and provider edge, especially on GRE/IPsec overlays where the effective MTU is smaller than expected
- Forgetting
ip tcp adjust-msson tunnel interfaces, causing large TCP sessions to hang - Static default routes left in place without proper floating administrative distance, breaking automatic failover
- Duplex/speed mismatches on legacy copper handoffs causing high error rates
- Not verifying provider-assigned VLAN tagging (dot1q) matches router subinterface configuration
Security Considerations
WAN edges are prime targets, so I always make sure:
- Unused WAN-facing services (like HTTP management) are disabled
- Control-plane policing (CoPP) is applied to protect the router CPU from WAN-sourced floods
- BGP sessions use MD5 authentication and, where possible, TTL security (GTSM)
Router(config-router)# neighbor 203.0.113.1 password CiscoSecureBGP
Router(config-router)# neighbor 203.0.113.1 ttl-security hops 1
Performance Tuning
For high-throughput WAN links, I always check whether the router is doing CEF switching (it should be, in virtually every modern deployment):
Router# show ip cef
Router# show cef interface GigabitEthernet0/0/1
If traffic is falling back to process switching, CPU utilization spikes and throughput suffers badly. I also check queue drops on the interface, since default queuing may not be appropriate for WAN links carrying mixed traffic types.
Troubleshooting Cellular and LTE/5G WAN Backup Links
Cellular WAN backup circuits have become extremely common at branch sites, and they come with their own set of quirks I have had to learn the hard way. On a router with a cellular interface, I start with:
Router# show cellular 0/1/0 all
This gives me signal strength (RSSI, RSRP, RSRQ), SIM status, and registration state with the carrier. If the modem shows “not registered,” the issue is almost always at the carrier/SIM level rather than router configuration — I check the SIM is active, the correct APN is configured, and that the account is in good standing before digging any further into router-side config.
Router(config)# controller Cellular 0/1/0
Router(config-controller)# lte profile 1 apn broadband.carrier.com
For weak signal issues, I physically check antenna connections and placement before assuming a configuration problem — I have seen more than one “intermittent cellular WAN” ticket resolved simply by relocating an external antenna a few feet or reseating a loose connector.
A Structured WAN Troubleshooting Checklist
When I get paged for a WAN outage, I run through the same checklist every time, in this order, so I never skip a layer:
- Physical layer:
show interface— line protocol status, errors, carrier transitions - Data link layer: encapsulation match, keepalives, clocking (for serial), VLAN tagging (for Ethernet handoffs)
- Network layer reachability: can I ping the provider’s next-hop address directly?
- Routing: is the expected route present in the routing table, and is the routing protocol adjacency healthy?
- NAT/ACL/firewall: is anything on the router itself filtering or translating traffic unexpectedly?
- End-to-end path: traceroute to identify exactly where in the path traffic stops flowing
- Performance characteristics: if reachability is fine but performance is poor, move to IP SLA and QoS analysis
Working through this list methodically, rather than jumping straight to “let me call the carrier,” has saved me from opening unnecessary carrier tickets more times than I can count — a large percentage of “WAN is down” tickets turn out to be a local misconfiguration, an accidental ACL change, or a routing issue entirely within our own control.
Frequently Asked Questions
Why does my WAN interface show up/up but I still cannot reach the internet? Check routing next — a healthy Layer 1/2 state does not guarantee a route exists or that the correct next hop is being used.
How do I tell if a WAN problem is on my end or the provider’s end? IP SLA statistics collected over time give you objective data (latency, jitter, loss) to share with the carrier, which is far more effective than describing symptoms verbally.
What is the most common cause of OSPF neighbors stuck in EXSTART over a WAN link? In my experience it is almost always an MTU mismatch between the two routers.
Should I use BFD for faster WAN failure detection? Yes, where supported — BFD detects link failures in milliseconds compared to standard routing protocol hello/dead timers, which can take seconds.
Summary
Troubleshooting WAN connectivity on Cisco routers is fundamentally a layered process: confirm physical and data link health first, then routing adjacencies, then end-to-end reachability, and finally performance characteristics. Having a consistent, repeatable methodology — rather than jumping straight to guesswork — is what lets you resolve outages quickly and back up carrier escalations with real data.
References
- Cisco IOS Troubleshooting Guide — cisco.com
- Cisco IP SLA Configuration Guide — cisco.com
- Cisco Embedded Packet Capture Configuration Guide — cisco.com
