EIGRP Stuck in Active

EIGRP Queries and Stuck in Active

I want to tell you a little more about the EIGRP query process and the stuck-in-active problem. This will be helpful in understanding why we use the EIGRP stub feature.

EIGRP is designed for large enterprise networks but having one big EIGRP network (5000+ prefixes and many hops) can lead to some problems:

  • Lots of EIGRP prefixes equal a large topology table and routing table.
  • Calculating the successor router will take longer if you have many EIGRP neighbors and different paths.
  • If there are many backup paths, EIGRP will have to see if there are one or more feasible successors. This will take longer.
  • More information means our EIGRP routers have to work harder to process everything.
  • When EIGRP loses a route, and there is no feasible successor the route will go from passive to active, and the router starts sending queries to its neighbors.
  • EIGRP sends queries on all interfaces except the interface of the successor.

Let me describe the EIGRP query process in detail for you:

eigrp big topology failed link

In the topology above, we are running EIGRP on all of the routers. R1 has a link failure and, as a result, has lost its successor route to a particular network on the left side. There is no feasible successor so the route is going from passive to active, and we will send a query to R2 and R3.

There are two things that can happen at this moment:

  • R2 or R3 has information about this particular route and will send information about it to R1. The query process is now over.
  • R2 or R3 don’t know anything about this route and will send a query themselves to their neighbors: R2 to R4 and R5. R3 to R6 and R7. R2 or R3 will not reply to R1 until they hear a response from all their neighbors.

eigrp big topology failed link query forward

In our topology, nobody has a clue which network R1 is looking for. They will forward their queries to their own neighbors. The red arrows indicate the query packet.

eigrp big topology failed link query reply

There are no neighbors behind R4, R5, R6, or R7. They will send a reply to R2 and 3 to let them know they don’t know the answer. R2 and 3 will send a reply to R1 to tell them they are sorry, but this is it. That’s a lot of packets for just one route that was lost, right?

eigrp big topology failed link query fail

Let’s make things even more interesting. Look at my picture above, and you’ll see that the reply from R2 never makes it back to R1. EIGRP is a reliable protocol and for each query, a router sends to its neighbors, it must get a reply in response within 3 minutes. If the router does not receive a reply to ALL its outstanding queries it will put the route in SIA (Stuck in Active) state and will kill the neighbor adjacency. By dropping the neighbor adjacency you will lose all the routes you learned from this neighbor, which means the router will start sending queries for all those routes as well. Not a pretty sight, right?

How is it possible that a reply never makes it back?

  • The router that gets the query is too busy because of memory problems or a CPU that’s too busy. It might not get the chance to process the incoming query or send a reply packet.
  • There are problems with the link between the neighbors, so not all packets arrive.
  • You have a unidirectional link failure, so packets only flow in one direction. This can happen with fiber links.

Since IOS 12.1, Cisco decided to change the stuck in active process to reduce the number of unwanted lost neighbor adjacencies. They introduced two new packets called SIA query and SIA reply.

eigrp sia reply

Before Cisco introduced SIA query and SIA reply this would happen:

  1. R1 loses information about a network and has no feasible successor.
  2. R1 sends a query to R2.
  3. R2 doesn’t know the answer, so sends a query as well to R3.
  4. R3 doesn’t know the answer and sends a reply to R2.
  5. R2 sends a reply to R1 to let him know he has no clue about this network.
  6. Because of congestion, the reply from R2 never makes it back to R1.
  7. After 3 minutes, R1 will drop the neighbor adjacency with R2, including all the routes it learned from R2.

Now we have SIA query and SIA reply and things will work a little bit differently:

  1. R1 loses information about a network and has no feasible successors.
  2. R1 sends a query to R2.
  3. R2 doesn’t know the answer, so sends a query as well to R3.
  4. R3 doesn’t know the answer and sends a reply to R2.
  5. R2 sends a reply to R1 to let him know he has no clue about this network.
  6. Because of congestion, the reply from R2 never makes it back to R1.
  7. After 1.5 minutes R1 will send an SIA query to R2 to ask for its status.
  8. R2 will respond with an SIA reply, and the neighbor adjacency will not be dropped.

Does this make sense to you? Another method to deal with these queries is configuring EIGRP summarization or the EIGRP stub feature. I’ll save those for another lesson! If you have any questions, please leave a comment.

Table of Content

Unit 1: Introduction to EIGRP

Unit 2: EIGRP Neighbor Adjacency

Unit 3: EIGRP Filtering

Unit 4: EIGRP Advanced Features