To begin the problem-isolation process when troubleshooting a possible IPv4 routing protocol problem, first focus on interfaces, and then on neighbors.
The routing protocol configuration identifies the interfaces on which the router should use the routing protocol. After identifying those interfaces, a network engineer can look at the neighbors each router finds on each interface, searching for neighbors that should exist but do not.
Troubleshooting Routing Protocol Problems
Because a routing protocol’s job is to fill a router’s routing table with the currently best routes, it makes sense that troubleshooting potential problems with routing protocols could begin with the IP routing table.
For example, the figure below shows an internetwork with six subnets. Router R1’s routing table should list all six subnets, with three connected routes, two routes learned from R2 (172.16.4.0/24 and 172.16.5.0/24), and one route learned from R3 (172.16.6.0/24).
One possible troubleshooting process is 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 whether that router has learned any routes from the expected next-hop (neighbor) 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.
For example, suppose that R1 in the figure has learned a route for subnet 172.16.4.0/24 but does not have routes for subnet 172.16.5.0/24. In this case, it is clear that R1 has a working neighbor relationship with R2. In these cases, the root cause of this problem might still be related to the routing protocol, or it might be unrelated to the routing protocol.
For example, the problem may be that R2’s lower LAN interface is down. However, if R1 did not have a route for either 172.16.4.0/24 or 172.16.5.0/24, R1’s neighbor relationship with R2 could be the problem.
Interfaces Enabled with a Routing Protocol
This part of article examines how to verify the interfaces on which the routing protocol has been enabled. Both EIGRP and OSPF configuration enable the routing protocol on an interface by using the network router subcommand. For any interfaces matched by the network commands, the routing protocol tries the following two actions:
- Attempts to find potential neighbors on the subnet connected to the interface
- Advertises the subnet connected to that interface
At the same time, the passive-interface router subcommand can be configured so that the router does not attempt to find neighbors on the interface but still advertises the connected subnets.
In Cisco devices, three show commands are all we need to know exactly which interfaces have been enabled with EIGRP and which interfaces are passive. In particular, the show ip eigrp interfaces command lists all EIGRP-enabled interfaces that are not passive interfaces.
The show ip protocols command essentially lists the contents of the configured network commands for each routing protocol and 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). Using this command, along with the list of passive interfaces listed by the show ip protocols command, again identifies all fully enabled OSPF interfaces as well as all passive interfaces.
Table below summarizes these commands for easier reference.
Routing Protocol Neighbor Relationships
After an EIGRP or OSPF router hears a Hello from a new neighbor, the routing protocol examines the information in the Hello, and compares that information with the local router’s own settings. If the settings match, great. If not, the routers do not become neighbors.
Because there is no formal term for all these items that a routing protocol considers, this book just calls them neighbor requirements. The table below lists neighbor requirements for EIGRP and OSPF:
1 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.
Unlike most of the neighbor requirements listed in the above table, the first three requirements have very little to do with the routing protocols themselves. The two routers must be able to send packets to each other over the physical network to which they are both connected. To do that, the router interfaces must be in the up/up state, and they must be in the same subnet. In addition, the routers must not be using an ACL that filters the routing protocol traffic.
For instance, OSPF sends many messages to the well-known multicast IP addresses 126.96.36.199 and 188.8.131.52, whereas EIGRP uses 184.108.40.206. An ACL command like access-list 101 deny ip any host 220.127.116.11, in an inbound ACL on a router interface, would filter incoming EIGRP packets. Or, an ACL command like access-list 102 deny ospf any any could filter all OSPF traffic. So, take extra care to watch for ACLs, especially when it seems like all the routing protocol configuration looks good.
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 all the Layer 1, 2, and 3 issues that could prevent the ping from working such as an interface not being up/up.