Cisco Support Community
Community Member


Hi All,

I am facing EIGRP stuck-in active problem since we are moving from ATM core network to VPN network.Earlier when the entire core was ATM, we didnt face any issues, but we replaced a Core ATM link with a GRE VPN link and we are getting lot of stuck-in active logs.

I dont understand the reason behind EIGRP algorithm resetting the neighbor relationship with its peers if a route goes into stuck in active as it doesnt get a reply.All the routes have to be relearnt.I have done a lot of reading but can't understand it.

For example:

*Nov 1 09:13:36.268: %DUAL-3-SIA: Route stuck-in-active state in IP-EIGRP(0) 100. Cleaning up

*Nov 1 09:13:36.268: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor (Tunnel140) is down: stuck in active

*Nov 1 09:13:36.424: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor (GigabitEthernet0/0) is up: new adjacency

*Nov 1 09:13:38.520: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor (Tunnel140) is up: new adjacency

When this route is no way reachable on your network(because of power problem,link down,etc), EIGRP resets the neighbor adjacency with all its upstream routers ? And all traffic on that link is broken/lost.

I am running IOS versions as below:

Let me know if you have any EIGRP related bugs

3845 --12.4(3) and 12.4(3a)





Hall of Fame Super Gold



I can not tell you why you are having such issues with stuck in active routes but I can share my understanding of what is involved and maybe that will help.

First lets establish some understanding of principles of EIGRP: EIGRP does not send periodic updates but exchanges routes with a neighbor when it discovers the neighbor. EIGRP assumes that once routes are exchanged that the neighbors will stay in sync by exchanging incremental updates when something changes. EIGRP also believes that if it loses sync with the neighbor (or thinks that it might have lost sync) that it should start the neighbor relationship over again from the beginning.

Another fundamental of EIGRP is that if EIGRP has had a route in its table (some prefix that it can route to) and if EIGRP loses that prefix from the table then EIGRP should put that prefix into "active state". When a prefix is in active state EIGRP should send a query to every one of its neighbors attempting to find whether any one has a replacement route.

If an EIGRP router receives a query from a neighbor it must either answer the query or it must forward queries to all of its nieghbors. The EIGRP router can not respond to a query until all of the queries that it may have sent to neighbors have been satisfied.

This leads us to the meaning of stuck in active. When an EIGRP router loses some route and puts it in active state and sends a query to all of its neighbors it assumes that the neighbor must respond within the time limit. If a neighbor has received a query and sent queries to its neighbors, it can not respond to the first query until all of its queries are responded to. If a neighbor does not respond within a certain limit of time the EIGRP router assumes that it may have lost sync with the router and tears down the neighbor relationship and starts over again from the beginning.

I believe that if you are having lots of stuck in active issues that there are two questions to investigate:

- why are so many routes being lost from the table?

- why are neighbors not able to respond within the time limit.





Rick's description of how EIGRP works is fine. You can find more information in a couple of places:

are some, or, there's a little EIGRP book published by Addison-Wesley called "EIGRP for IP Networks." It's a really good, short book, which also has a section on troubleshooting SIAs that's very good, if I remember right (?). My mind is like a steel sieve, only the big chunks stick....

Generally, a route gets stuck in the active state because of either a sick router, or a sick link in the network someplace. The key is either to run new code, where you don't get SIAs, but instead get neighbors taken down because the neighbor or link to the neighbor is bad, or to chase down the bad router or link.

It's hard to explain how to do this in a post, but if you send me an email, I can probably dig up some slides that show how to do it. Some common problems that cause SIAs are:

-- Router with no memory, or heavy memory fragmentation. Routers in this condition will ack packets from their neighbors, but not send a reply, causing SIAs all around them, in many cases (although they may never be reset themselves).

-- Dirty links. This is probably the least common problem, in my experience, but it does happen.

-- Some specific network topologies can cause an SIA in almost all cases, in older code (figure 8's, and the problem should be fixed in all the code you're running).

-- Hold times of 180 seconds on zero cir or other "low end" links in your network. You can often clear SIAs by changing your hello and hold timers on very low speed NBMA links to 30 and 90 seconds, rather than the default 90 and 180 seconds. The explaination is long and convoluted, but just consider that 180 seconds is 3 minutes, which happens to match the active timer, by default.... Most links are 5 and 15 by default, but some types are 90 and 180.

There's a lot of information in this area, hard to cover in a single posting....




Community Member


Thanks, Russ and Rburts for your suggestions. I finally got hold of the sick router which was causing this problem.It was the router was not fully configured to peer with necessary EIGRP routers.But this router was 3 hops away from were I was getting the stuck in active logs.


CreatePlease to create content