EIGRP Stuck In Active

EIGRP Stuck In Active

As we all know that EIGRP is an interior gateway protocol and can hold a large number of routing prefixes.

To maintain neighbourship between routers EIGRP uses HELLO packet but if anything goes wrong in the topology then EIGRP uses Query/reply packet.

Stuck in Active is a state in which a router waits for the reply from its neighbour. The router attempts to find an alternate path to a route that is no longer available in the routing table. This attempt takes place when the successor and the feasible successor are not available to the failure route. Router goes from passive mode to active mode for a route that is no longer available. When the router is in active mode it indicates that something is wrong and the router is waiting for query’s reply.

There are two modes for a route in EIGRP:-

Active mode – Router loses route and waiting for a reply from its neighbour to that route.

Passive mode – This mode indicates that route is valid and everything is working fine.

Let’s understand with an example : –

In the Below example, all routers are aware of the EIGRP process. Now suddenly if R1 loses it’s 1.1.1.0/24 route due to link failure. R1 immediately looks for the feasible successor in the routing table for that route. As per topology, we don’t have any feasible successor to 1.1.1.0/24.

So in the below example, R1 moves from passive mode to active mode for 1.1.1.0/24. R1 generates query messages to find an alternative to that route which is no longer available.

The state when a router looks for an alternate path during a time period is called Stuck in Active. Once the R1 sends query then It can wait for reply up to 3 minutes. 3 Minutes it the default Stuck in Active timer value and it can be set to any value between 1 and 65535.

In the above example, All the routers send the reply to their upstream routers and R1 finally removes 1.1.1.0/24 from its routing table.

Now suppose if R7 is not sending a reply to R2 then what would be the situation? Let’s understand.

In the above example, R7 may not be able to send reply due to quality issue on the link therefor causing the packet to lose or the low-bandwidth links get congested and packets are being delayed or dropped.

R1 and R2 set their Stuck in Active timer value to 3 minutes when they sent a query. They kept waiting for the reply during that time. R2 will not proactively inform R1 that it is still waiting for a reply from R7 so once the Stuck in Active timer expires, R2 breaks the neighbouring ship with R7 and R1 breaks the neighbourship with R2.

This may cause a huge problem in the network and R1 will lose all the routes coming from R6 also. This used to happen in earlier in IOS 12.1 and earlier versions. In this case, R1 will never come out of the Stuck in Active state.

After 12.1 IOS this was improved and came with some safeguard solutions.

Let’s understand in below example

R1 sends a query and expect a reply from all the devices. R7 is not able to send a reply. Other side R1 and R2 are in Stuck in Active state.

This time R1 will send SIA query every 90 seconds to confirm that R2 is still alive and waiting for R7‘s reply. R2 will respond to R1‘s SIA-Query and sends SIA-Query to R7 and waits for its reply. At most three SIA-Queries will be sent, Each after half of the Active timer.

Now if Stuck in Active timer expires on both R1 and R2, still R1 and R2 will be neighbours and they will not lose the neighborship. That’s the advantage we get using SIA-Query packet. R2 and R7 may lose the neighbourship and that’s ok in this scenario. This all magic was happening because of SIA-Query and SIA-Reply.

After all this R1 and R2 will remove 1.1.1.0/24 from their routing table but they will not lose any EIGRP neighborship.

I think this will make you understand how the query and reply process works. There are many methods to reduce these query and reply process in EIGRP.

I hope this has been informative for you. If it seems helpful then Like, Share and Don’t forget to subscribe and follow me for the upcoming posts

https://www.youtube.com/channel/UC0-p23p1xWsZsTXHUQ7CiJg

https://www.facebook.com/networkinginfo/

https://twitter.com/Dj1Pali

https://www.instagram.com/a_bhartiya_rider/

https://www.linkedin.com/in/dinesh-jangid-515b6a23/