Content

| 5.6 |  | Troubleshooting EIGRP |
| 5.6.4 |  | Stuck in active – methodology for troubleshooting |

The methods for troubleshooting an EIGRP stuck in active problem with the show ip eigrp topology active command is useful only when the problem is happening. When the stuck in active event is over and the network stabilizes, it is extremely difficult, if not impossible, to backtrack the problem and find out the cause. Figure shows the flowchart for troubleshooting the EIGRP stuck in active problem.

Consider the network shown for an example of troubleshooting the EIGRP stuck in active problem. Router A has a FastEthernet interface with network 20.2.1.0/24 that just went away. Router A does not have a feasible successor to go to as a backup route. Router A has no choice but to put the 20.2.1.0/24 route into active state and query its neighbor, Router B. Notice the output of show ip eigrp topology active in Router A. The 20.2.1.0/24 route has gone away for 1 minute and 12 seconds, and the neighbor that has not responded is listed as 10.1.1.2 from Serial 0/0, which is Router B. The next step is to Telnet to Router B to see the active route status in Router B. Figure shows the active route status in Router B by performing the command show ip eigrp topology active.

The command show ip eigrp topology active on Router B shows that the route 20.2.1.0/24 is also in active status in Router B and that it has gone active for 1 minute and 23 seconds. Most importantly, Router B cannot reply to Router A about 20.2.1.0/24 because Router B is still waiting for the neighbor with IP address of 10.1.3.2 (Router D) from Serial 1/2 to reply to the query. The next step is to go to Router D to see the status of the active route 20.2.1.0/24 to see why Router D has not replied to the query. Figure shows the output of show ip eigrp topology active on Router D.

Router D also put the router 20.2.1.0/24 in active state, and it has been in active state for 1 minute and 43 seconds. Router D can not answer the query from Router B because Router D is waiting for the router with the IP address of 10.1.5.2 from Serial 1/2 (Router E) to respond to the query. The next step is to go to Router E to see the status of the active route 20.2.1.0/24 and to find out why Router E is not replying to the query. Figure shows the status of the active route on Router E.

The output for show ip eigrp topology active did not show anything for Router E. This indicates that, as far as Router E is concerned, there are no routes in active state. The next step is to Telnet back to Router D to double-check whether the router is still in the active state for route 20.2.1.0/24. Telnetting back to Router D shows that Router D is still in active state for route 20.2.1.0/24, but Router E does not have any routes in active state.

To summarize the event so far:

1. Router A went active for route 20.2.1.0/.24 and is waiting for Router B to reply to its query.
2. Router B cannot reply because it is waiting for the query response from Router D.
3. Router D cannot reply because it is waiting for Router E to reply to the query.
4. Finally, the show ip eigrp topology active command in Router E shows that Router E does not think that any routes are active, while going back to Router D shows that the route 20.2.1.0/24 is still in active state.

From this sequence of events, you can see that there is clearly a discrepancy between Router D and Router E. More investigation is needed between these two routers.

A look at Router D and Router E CPU utilization and memory usage does not show a problem. The CPU utilization and available memory are normal for both routers. Look at the Router D neighbor list to see if there is a problem with the neighbors. Figure shows the Router D EIGRP neighbor list.

Notice that there is a problem in Router D with EIGRP sending a reliable packet to the neighbor with IP address of 10.1.5.2 (Router E). The Q count is 1, and performing the show ip eigrp neighbors command a few times in succession shows that the Q count is not decrementing.

The RTO counter is at its maximum value of 5000ns. This indicates that Router D is trying to send a reliable packet to Router E, but Router E never acknowledges the reliable packet back to Router D. Because Router E does not appear to have a high CPU or memory problem, the link should be tested for reliability between Router D and Router E. Figure shows the output of a ping from Router D to Router E.

The ping test shows the success rate of 0 percent. This test shows that a link problem exists between Router D and Router E. The link is capable of passing a multicast packet to establish an EIGRP neighbor relationship, but it is having problems transmitting a unicast packet. This link problem is the root cause of the EIGRP stuck in active problem in this example. The way to troubleshoot the EIGRP stuck in active problem is to chase the query, hop by hop, and find out the status of the active route at each hop.

This process is typical troubleshooting methodology for combating the EGIRP stuck in active problem. Sometimes, chasing the query, hop by hop, leads to a loop, or there are simply too many neighbors that did not reply to the query. In this case, simplify and reduce the complexity of the EIGRP topology by cutting down the redundancy. The simpler the EIGRP topology is, the easier it is to troubleshoot an EIGRP stuck in active problem.