EIGRP Queries and Stuck in Active

Thanks Andrew…

Great explanation Rene.

I have one query- Suppose R2 is unable to get back to R1, how can we troubleshoot those high memory/CPU utilization and unidirectional link failure problems in between R1-R2

Hi Rene,
I have two doubts here:

1> Router 1 waits 3 minute to enter into stuck in active, but we know 10 sec hello time,so in between router 1 receive hello packets from router 2, still it goes SIA?

2> You said if due to congestion, reply packet is not coming from Router 2, or due to CPU/Memory utilization at router 2, it may not process or send.
If that is the case then there is possibility that SIA reply will not come from router because of above reason ie CPU/Memory or congestion. So that case also router 1 will go to SIA mode and adjacency will be dropped? whats the waiting period for SIA reply? What if that period expires?

Please help…

Thank you,
Pradeep K

Hello Pradeep.

These are very good questions. In the first question, the answer is yes, even if hello packets are being recieved from a router, the SIA state will still kill the neighbour adjacency. You can think of the Stuck in Active condition as an additional condition for which neighbour adjacencies are killed.

As for your second question, yes you’re right, the SIA reply may also fail to reach Router 1 due to congestion. Only one SIA Query is sent at 90 seconds. However, the purpose of the SIA Query and Reply feature is not only to resolve eigrp failures due to congestion, but also due to the waiting time it takes to allow additional routers to respond to queries. Let’s say you have six routers in this configuration:


R1 loses a router via the interface to the left. It sends a query to R2, which sends a query to R3 and so on. At 90 seconds, R1 sends is SIA query to R2. R2 WILL ANSWER with an SIA reply EVEN IF it doesn’t yet have an answer to give R1, because R2 is also waiting on the other routers to get an answer. This saves the relationship and the rebuilding of the routing table. The timer then goes back to 0 and after another 90 seconds the query goes again.

I hope this has been helpful.


1 Like

Hi Rene,4

If there are more than one feasible successor , will all of them show in topology table?

Also if the successor route goes down , feasible successor takes over. Now will there be a new feasible successor?

Hi Ananth Maruti,

If there is more than one feasible successor, then surely it will be listed in the topology table of EIGRP. Please remember the forumla: to have a feasible successor then the Advertised distance of feasible successor should be less than the Feasible distance of successor.

For the 2nd part of your question, if the network in converged than the calculation of successor & feasible successor(s) is already done. In this case, if a successor route goes down, then the feasible successor takes over. In case the topology table had another feasible successor then it will remain in the topology table.
They will be a possible new feasible successor if the network has been changed such as adding a new router in the EIGRP network which has a route to the destination network which complies to the formula that I have listed above, then in this case a new feasible successor will be added to the topology table.

I highly recommend that you read this lesson for more detailed information: Introduction to EIGRP

Hope I could answer your question.

Hi Rene,
When a router receives an SIA query there are three possibilities (I can think of)

  1. The router is still waiting for its own querys to be responded to. So as explained it sends an SIA reply
    so far so good
  2. The router had previously sent a reply with infinite metric
  3. The router had previously sent a reply with finite metric (i.e it has a route)

For cases 2 and 3 is the information included in the SIA reply packet or does the router respond with SIA reply and a Reply packet ?


I simulated this on GNS3

Basically case 1 SIA Reply is sent
Case 2 and 3 SIA Reply is not sent, however since the reply packet would not have received an ACK the router keeps sending reply every 5s until it gets an ACK

So IRL case 2 and 3 do not result in SIAQuery being sent

Hi Rene, thanks for such good explanation. I have one doubt in that. Suppose R1 will start its timer for 3 mins and after 1.5 min it will send SIA query to R2, if R2 send SIA reply to the R1 then till what time R1 will wait?

Your reply will really very helpful for clearing my doubt.

Hello Raj

In the scinario you describe above, R1 starts its 3 minute timer. It sends an SIA query to R2. If R2 sends an SIA reply to R1 before the 3 minutes are up, then the timer resets to 0. If it does not, then the neighbour relationship is torn down.

I hope this has been helpful!


19 posts were merged into an existing topic: EIGRP Queries and Stuck in Active

Hi Lazaros, I got it. Thanks a lot for you reply.Its really helpful.

19 posts were merged into an existing topic: EIGRP Queries and Stuck in Active

If a route/neighbour fails, how can you recover from SIA? Recycle the interface facing the neighbour that’s down?

I’m also curious how you can simulate this in GNS3. Surely the main cause of SIA is congestion? How did you replicate the replys from R2 not reaching R1? Use an ACL?

Hello Chris

If a route or neighbour fails, and there is no feasible successor, an EIGRP enabled router will go from Passive to Active. This is normal behaviour. This is also the expected behaviour because it must attempt to find a new route to the destination. This does not mean that the router goes into SIA.

The router will only go into SIA if several things go wrong on the network as described in the lesson.

Now if you do end up in SIA, there is no “quick fix” solution like the bouncing of an interface. You must look more deeply into the problem. What is the reason for SIA? It is usually due to congestion on the network, a malfunctioning link or a unidirectional link.

Another reason may be the use of an IOS before 12.1 that doesn’t use the SIA query and reply packets (which reduce the probability of an SIA situation).

Another way to resolve SIA problems is to configure EIGRP summarization and/or the EIGRP stub feature. All of these must be implemented using proper troubleshooting procedures to evaluate the results of each change.

To simulate lost EIGRP packets in GNS3 you can use a traffic generator to create network congestion. There are several options for this, one of which you can find here. You can make your interfaces 10Mbps if they are Ethernet or you can create serial links and modify the data rate accordingly to make the data congestion reach 100% of bandwidth. When you do this however, make sure that you configure the ip bandwidth-percent eigrp command on the interface in question at a very low percentage such as 1 or 2 percent. This should have the result of losing some EIGRP packets.

Try it out and let us know your results!

I hope this has been helpful!


Is this feature enable by default in EIGRP?

Yes it is :slight_smile:

Thanks for such a good brief .Can we have a lab where we can test it.

1 Like

as Router send SIA query to router after 1.5 Second but as link is of fiber and there is unidirectional link failure then SIA query of neighbor router will not reach towards query sender (i.e. Router)
then what will happen?

Hello Kunal

SIA queries and replies are used in order to minimize situations where neighbor adjacencies that are a result of lost replies to regular EIGRP queries. These lost replies are usually due to intermittent problems that may prevent some replies from reaching their destinations, such as high CPU, flapping links, network congestion etc. If you have a situation where there is a permanent unidirectional link failure, SIA will not resolve this issue. The SIA response will never reach the sender.

Take a look at the lesson below that further describes the EIGRP Queries and SIA:

I hope this has been helpful!