Perspectives on Troubleshooting Routing Protocol Problems
Given basic information about an internetwork, including the routers, their IP addresses and masks, and the routing protocol, you could calculate the subnet numbers that should be in the router’s routing tables and list the likely next-hop router(s) for each route.
One possible troubleshooting process would be to analyze the internetwork, look at the routing table, and look for missing routes. If one or more expected routes are missing, the next step would be to determine if that router has learned any routes from the expected next-hop router. The next steps to isolate the problem differ greatly if a router is having problems forming a neighbor relationship with another router, versus having a working neighbor relationship but not being able to learn all routes.
If an exam question appears to be related to a problem with a routing protocol, you can quickly identify some common configuration errors with the following process – even without the configuration or the ability to use the show running-config command. The process has three main branches:
Step 1: Examine the internetwork design to determine on which interfaces the routing protocol should be enabled and which routers are expected to become neighbors.
Step 2: Verify whether the routing protocol is enabled on each interface. If it isn’t, determine the root cause and fix the problem.
Step 3: Verify that each router has formed all expected neighbor relationships. If it hasn’t, find the root cause and fix the problem.
Interfaces Enabled with a Routing Protocol
Both EIGRP and OSPF configuration enables the routing protocol an an interface by using the network router subcommand. For any interfaces matched by the network commands, the routing protocol tries the following two actions:
* Attempt to find potential neighbors on the subnet connected to the interface.
* Advertise the subnet connected to that interface.
The passive-interface subcommand can be configured so that the router does not attempt to find neighbors on the interface but still advertises the connected subnet.
show ip eigrp interfaces lists all EIGRP-enabled interfaces that are not passive interfaces. show ip protocols lists the contents of the configured network commands for each routing protocol, as well as a separate list of the passive interfaces. Comparing these two commands identifies all EIGRP-enabled interfaces and those that are passive. For OSPF, the command works slightly differently, with the show ip ospf interface brief command listing all OSPF-enabled interfaces (including passive interfaces).
Key Commands to Find Routing Protocol Enabled Interfaces
show ip eigrp interfaces: Lists the interfaces on which the routing protocol is enabled (based on the network commands), except passive interfaces.
show ip ospf interface brief: Lists the interfaces on which the OSPF is enabled (based on the network commands), including passive interfaces.
show ip protocols: Lists the contents of the network configuration commands for each routing process, and lists enabled but passive interfaces.
OSPF Interface Troubleshooting Examples
It makes sense to check the interface IP addresses, masks, and interface status, using the show interfaces and show ip interface brief commands. It is helpful to note which interfaces are up/up, because a routing protocol will not attempt to find neighbors or advertise connected subnets for an interface that is not in an up/up state.
Neighbor Relationships
When a routing protocol has been enabled on an interface that isn’t in passive mode, the routing protocol attempts to discover neighbors and form a neighbor relationship with each neighbor that shares the common subnet.
In OSPF, all routers on a common subnet should be in the same area by design.
Neighbor Requirements for EIGRP and OSPF
| Requirement | EIGRP | OSPF |
|---|---|---|
| Interfaces must be in an up/up state | Yes | Yes |
| Interfaces must be in the same subnet | Yes | Yes |
| Must pass neighbor authentication (if configured) | Yes | Yes |
| Must use the same ASN/process-ID on the router configuration command | Yes | No |
| Hello and hold/dead timers must match | No | Yes |
| IP MTU must match | No | Yes |
| Router IDs must be unique | No* | Yes |
| K-values must match | Yes | N/A |
| Must be in the same area | N/A | Yes |
* Having duplicate EIGRP RIDs does not prevent routers from becoming neighbors, but it can cause problems when external EIGRP routes are added to the routing table.
Before examining the rest of the details of why two routers do not become neighbors, confirm that the two routers can ping each other on the local subnet. If the ping fails, investigate Layer 1, 2, and 3 issues.
EIGRP Neighbor Requirements
Any two EIGRP routers that connect to the same data link, and whose interfaces have been enabled for EIGRP and are not passive, will at least consider becoming neighbors. To know which potential neighbors have passed the requirements for EIGRP, look at the output of show ip eigrp neighbors. This lists only neighbors that have passed all the verification checks. If the command does not list one or more expected neighbors, and the two routers can ping each other on their common subnet, the problem is probably related to one of the neighbor requirements
EIGRP Neighbor Requirements and the Best show/debug Commands
| Requirement | Best Command(s) to Isolate the Problem |
|---|---|
| Must be in the same subnet | show interfaces |
| Must pass any neighbor authentication | debug eigrp packets |
| Must use the same ASN on the router configuration command | show ip eigrp interfaces, show protocols |
| K-values must match | show protocols |
EIGRP K-values refer to the parameters that can be configured to change what EIGRP uses in its metric calculation. Cisco recommends leaving these values as their default settings, only using bandwidth and delay in the metric calculation.
OSPF Neighbor Requirements
A router’s show ip ospf neighbor command lists all the neighboring routers that have met all the requirements to become an OSPF neighbor. The first step in troubleshooting OSPF neighbors is to look at the list of neighbors.
For neighbors that do not need to directly exchange their databases, typically two non-DR routers on a LAN, the routers should settle into a two-way neighbor state. In most cases, two neighboring routers need to directly exchange their complete full LSDBs with each other. As soon as that process has been completed, the two routers settle into a Full neighbor state.
If the show ip ospf neighbor command does not list one or more expected neighbors, before moving on to look at OSPF neighbor requirements, you should confirm that the two routers can ping each other on the local subnet. As soon as the two neighboring routers can ping each other, if the two routers still do not become OSPF neighbors, the next step is to examine each of the OSPF neighbor requirements.
| Requirement | Best Command(s) to Isolate the Problem |
|---|---|
| Must be in the same subnet | show interfaces, debug ip ospf hello |
| Must pass any neighbor authentication | debug ip ospf adj |
| Hello and hold/dead timers must match | show ip ospf interface, debug ip ospf hello |
| Must be in the same area | debug ip ospf adj, show ip ospf interface brief |
| Router IDs must be unique | show ip ospf |
debug ipo ospf adj helps troubleshoot mismatched OSPF area problems as well as authentication problems. “Mismatched authentication key” means that the correct authentication type was used but the configured keys have different values. debug ip ospf hello helps uncover mismatches discovered in the Hello message, including mismatched IP address/masks and timers.
The MTU Matching Requirement
Of all the problems between two potential OSPF neighbors, only one problem, the mismatched MTU problem, allows the neighbor to be listed in the other router’s show ip ospf neighbor command output. When two routers connect to the same subnet, with different interface IP MTU settings, the two routers can become neighbors and reach the two-way state. However, when the two routers attempt to exchange LSDBs, the database exchange process fails because of the MTU mismatch.
When the MTU mismatch occurs, the routers typically move between a few neighbor states while trying to overcome the problem. The most common state is the Exchange state. The state typically cycles from Exchange state, back to Init state, and then back to Exchange state.