Routing protocol troubleshooting is where I feel like a real network engineer earns their keep. Anyone can configure OSPF from a template, but figuring out why two routers refuse to form an adjacency, or why BGP is advertising the wrong path, requires actually understanding what is happening under the hood. I want to walk through my complete diagnostic approach for the three protocols I deal with most in enterprise networks: OSPF, EIGRP, and BGP.
Networking Fundamentals: How These Protocols Actually Work
OSPF is a link-state protocol. Routers exchange link-state advertisements (LSAs) and build an identical topology database (LSDB), then run Dijkstra’s SPF algorithm independently to calculate the shortest path. Neighbors must match area type, hello/dead timers, MTU, and authentication before they can exchange the full database.
EIGRP is often called a “hybrid” protocol — it uses distance-vector principles but incorporates the DUAL (Diffusing Update Algorithm) for loop-free, fast convergence. EIGRP neighbors must match the autonomous system number and K-values (metric weights) before forming an adjacency.
BGP is a path-vector protocol used primarily for inter-domain routing (though iBGP is also common inside large enterprises). BGP relies on a reliable TCP session (port 179) and makes path decisions using a well-defined best-path selection algorithm based on attributes like AS-path length, local preference, MED, and origin type.
Understanding these fundamentals matters because each protocol fails differently, and the show/debug commands you reach for depend entirely on which stage of the process is broken.
Troubleshooting OSPF
Step 1: Verify Neighbor State
Router# show ip ospf neighbor
Healthy neighbors should settle in FULL state (or 2WAY for DR-other relationships on broadcast segments). If neighbors are stuck:
- INIT: The router is receiving hellos but not seeing itself listed in the neighbor’s hello packet — often a one-way communication problem or ACL blocking traffic in one direction.
- EXSTART/EXCHANGE: Almost always an MTU mismatch between the two routers.
- Neighbor never appears at all: Check hello/dead timer mismatch, area ID mismatch, or authentication mismatch.
Router# show ip ospf interface GigabitEthernet0/0/1
This shows the configured area, hello/dead intervals, and network type, all of which must match the neighboring router.
Step 2: Verify the LSDB Is Synchronized
Router# show ip ospf database
If two routers report different LSDB contents for the same area, something is preventing full synchronization — usually a neighbor stuck in EXSTART/EXCHANGE as mentioned above.
Step 3: Confirm Routes Are Installed
Router# show ip route ospf
If a route you expect is missing, check for route summarization suppressing it, or a distribute-list/route-map filtering it out:
Router# show run | section router ospf
Common OSPF Debug Commands
Router# debug ip ospf adj
Router# debug ip ospf hello
I use these sparingly on production routers with a lot of neighbors, since OSPF debugging can be verbose.
Troubleshooting EIGRP
Step 1: Verify Neighbor State
Router# show ip eigrp neighbors
If a neighbor is missing entirely, I check autonomous system number match, K-value match, and whether the interface is passive:
Router# show run | section router eigrp
A passive interface will never form an adjacency — this trips people up constantly, especially after a template-based configuration marks interfaces passive by default and someone forgets to explicitly enable EIGRP on the correct interface.
Step 2: Check the Topology Table
Router# show ip eigrp topology
Routes in this table can be in the “Passive” state (stable, best path selected) or “Active” state (currently recalculating due to a lost route with no feasible successor). A route stuck in “Active” for an extended period is a serious problem — it indicates SIA (Stuck-In-Active), which can cause the neighbor relationship to be torn down entirely.
Router# show ip eigrp topology active
Step 3: Confirm Routes Are Installed
Router# show ip route eigrp
If a route is present in the topology table as a successor but not in the routing table, check for a route-map or distribute-list filtering redistribution or advertisement.
Common EIGRP Debug Commands
Router# debug eigrp packets hello
Router# debug ip eigrp neighbor
Troubleshooting BGP
Step 1: Verify Session State
Router# show ip bgp summary
Session states I watch for:
- Idle: BGP is not even attempting a TCP connection — often means the neighbor statement itself, or a routing/reachability issue to the peer address.
- Active: BGP is trying to establish a TCP session but has not succeeded — check for an ACL/firewall blocking TCP 179, or an incorrect peer IP.
- Established with low uptime and flapping: Look for a hold-timer expiration, MTU issue on large updates, or a duplicate router-id causing resets.
Router# show ip bgp neighbors 203.0.113.1
This gives detailed session information including capabilities negotiated, message counts, and the last reset reason — that last part is invaluable for diagnosing flapping sessions.
Step 2: Verify Prefixes Are Being Received and Advertised
Router# show ip bgp neighbors 203.0.113.1 received-routes
Router# show ip bgp neighbors 203.0.113.1 advertised-routes
If expected prefixes are missing, check inbound/outbound route-maps and prefix-lists applied to the neighbor:
Router# show run | section router bgp
Step 3: Diagnose Best-Path Selection Issues
When multiple paths exist and the “wrong” one is being chosen, I walk through the BGP best-path algorithm in order: highest weight, highest local preference, locally originated preferred, shortest AS-path, lowest origin type, lowest MED, eBGP over iBGP, lowest IGP metric to next hop, and so on.
Router# show ip bgp 198.51.100.0/24
This command shows every attribute for the prefix, letting me walk through exactly why one path was chosen over another rather than guessing.
Real-World Enterprise Scenario: Redistribution Loop Between OSPF and EIGRP
I once inherited a network where OSPF and EIGRP were mutually redistributed at two separate boundary routers without route tagging, and routes were bouncing back and forth, occasionally causing suboptimal paths and, in one case, a routing loop during a link failure. The fix was to implement route tagging on redistribution and filter based on tags to prevent routes from being re-redistributed back into their original protocol:
Router(config-router)# redistribute ospf 1 metric 100 route-map TAG-FROM-OSPF
Router(config)# route-map TAG-FROM-OSPF permit 10
Router(config-route-map)# set tag 100
And on the return redistribution point, filtering out anything already tagged 100 to prevent the loop:
Router(config)# route-map BLOCK-RETAG deny 10
Router(config-route-map)# match tag 100
Router(config)# route-map BLOCK-RETAG permit 20
This is a pattern I now apply by default any time I am asked to design mutual redistribution between two protocols.
Common Configuration Mistakes
- Mismatched OSPF area type (e.g., one side stub, other side normal) preventing adjacency
- EIGRP passive-interface applied to an interface that should be forming neighbors
- Missing or mismatched BGP AS numbers, or forgetting
neighbor remote-asentirely - Not filtering redistributed routes between protocols, leading to routing loops or suboptimal paths
- Summarizing routes at the wrong boundary, causing black holes for subnets that do not actually exist behind the summarizing router
Security Best Practices
- Always authenticate routing protocol sessions (MD5 for OSPF/EIGRP, MD5 or TCP-AO for BGP)
- Use
passive-interface defaultand explicitly enable only the interfaces that should participate, reducing attack surface - Apply prefix-lists and AS-path filters on eBGP sessions to prevent accepting unexpected or malicious routes
- Use maximum-prefix limits on BGP sessions to protect against route table exhaustion from a misbehaving peer
Router(config-router)# neighbor 203.0.113.1 maximum-prefix 500 80
Performance Tuning
For faster convergence, I frequently deploy BFD alongside OSPF, EIGRP, or BGP rather than relying solely on protocol-native hello/dead timers, since BFD can detect a link failure in tens of milliseconds:
Router(config-if)# bfd interval 100 min_rx 100 multiplier 3
Router(config-router)# neighbor 203.0.113.1 fall-over bfd
Frequently Asked Questions
Why are my OSPF neighbors stuck in EXSTART? This is almost always an MTU mismatch between the two routers — verify with show ip ospf interface and match MTU on both sides.
Why does my EIGRP neighbor never come up even though the interface is up? Check whether the interface is marked passive under the EIGRP process — a very common oversight.
Why is my BGP session stuck in Active state? This typically means BGP cannot complete the TCP three-way handshake — check for an ACL or firewall blocking TCP port 179, or confirm the neighbor IP is correct and reachable.
How do I figure out why BGP chose one path over another? Use show ip bgp <prefix> and walk through the best-path selection order attribute by attribute rather than guessing.
Summary
Routing protocol troubleshooting on Cisco routers requires understanding the specific mechanics of each protocol — OSPF’s link-state synchronization, EIGRP’s DUAL-based topology table, and BGP’s path-vector best-path algorithm. In every case, the process is the same at a high level: verify the neighbor/session state, verify the routing database or table contents, then verify what is actually installed in the routing table and why.
References
- Cisco IP Routing: OSPF Configuration Guide — cisco.com
- Cisco IP Routing: EIGRP Configuration Guide — cisco.com
- Cisco IP Routing: BGP Configuration Guide — cisco.com