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 difficult 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:
- Router A went active for route 20.2.1.0/.24 and is waiting for Router B to
reply to its query.
- Router B cannot reply because it is waiting for the query response from
Router D.
- Router D cannot reply because it is waiting for Router E to reply to the
query.
- 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.