EIGRP timers

Answered Question
Feb 5th, 2009

How long does it take for EIGRP to declare a route dead and to add a feasible successor to the topology table?

Is there any way to make it faster?

Thank you

I have this problem too.
0 votes
Correct Answer by Richard Burts about 7 years 11 months ago

Fuad

Apparently Mohamed was right and your question is more about how to declare a neighbor dead and not about how to process route replacement.

Yes to declare a neighbor dead more quickly you should decrease the timers.

HTH

Rick

Correct Answer by Mohamed Sobair about 7 years 11 months ago

Hi,

For EIGRP to declare a neighbor dead depends on the lin.

On high speed link (above 1536Kb) , the Hellos are send every 5 seconds. The Hols timer expires in 15 sec (3*Hello timer).

On low speed link, The hello Timers are send every 6sec , the Hold timer expires in 180sec.

U can manually modify the (Hello & Hold) timers, but be sure the Hold timer should be 3*hello timer. You may also find another consideration/precaution about changing it that I may not be aware of but its possible.

HTH

Mohamed

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Correct Answer
Mohamed Sobair Thu, 02/05/2009 - 05:51

Hi,

For EIGRP to declare a neighbor dead depends on the lin.

On high speed link (above 1536Kb) , the Hellos are send every 5 seconds. The Hols timer expires in 15 sec (3*Hello timer).

On low speed link, The hello Timers are send every 6sec , the Hold timer expires in 180sec.

U can manually modify the (Hello & Hold) timers, but be sure the Hold timer should be 3*hello timer. You may also find another consideration/precaution about changing it that I may not be aware of but its possible.

HTH

Mohamed

Richard Burts Thu, 02/05/2009 - 07:35

Mohamed

You have given a good explanation of EIGRP timers and the process of declaring a neighbor dead. But I am not sure that is really what Fuad was asking about. His post asks about declaring a "route" dead and when he asks about getting feasible successor into the routing table I am not sure that his question was about neighbors.

There are two things that produce delay about getting an EIGRP replacement route into the routing table: if EIGRP has to go through the querry process to find possible replacement routes, and what does EIGRP have to do to assure that the replacement route is a loop free path to the destination. When EIGRP gives the status of feasible successor to a route it has already gone through the process of assuring that the route is a loop free path to get to the destination. So if the currently chosen route is declared dead and removed from the routing table and if there is a feasible successor then EIGRP does not need to go through the querry process and does not need to do any calculation on the feasible successor route to detect potential loops. EIGRP just puts the feasible successor route into the table. That is very very fast and there is not anything that you can do to make it faster.

HTH

Rick

fgasimzade Thu, 02/05/2009 - 07:57

Thank you, Rick and Mohammed

Even though it does not go through any calculation, I experience delay for about 15 sec, when testing it with a "ping" command. As far as I understand the reason is in "hello" and "hold" timers, am I correct?

Richard Burts Thu, 02/05/2009 - 08:09

Fuad

Can you tell us a bit about how you are testing? In particular how are you getting the route to fail and how is that failure detected. If you are running a ping which is running over the route that will fail and watching how long it takes the ping to start on the new route, then what you are observing is a combination of how long it takes to determine that a neighbor has failed (as discussed by Mohamed) and how long it takes for the feasible successor to be put into the routing table.

I might suggest that a better test would be to run some debugs on the router where the feasible successor will be put into the routing table. Perhaps debug ip routing will show you the amount of time from when the old route is removed from the routing table to the time when the feasible successor is put into the table. Or perhaps some debugs on EIGRP (perhaps debug eigrp fsm) will clarify how long it takes from route failure to placement of feasible successor into the routing table.

HTH

Rick

fgasimzade Thu, 02/05/2009 - 08:13

If you are running a ping which is running over the route that will fail and watching how long it takes the ping to start on the new route, then what you are observing is a combination of how long it takes to determine that a neighbor has failed (as discussed by Mohamed) and how long it takes for the feasible successor to be put into the routing table.

--------------

This is exactly what I am doing, so I assume I have to decrease the timers, right?

Correct Answer
Richard Burts Thu, 02/05/2009 - 08:22

Fuad

Apparently Mohamed was right and your question is more about how to declare a neighbor dead and not about how to process route replacement.

Yes to declare a neighbor dead more quickly you should decrease the timers.

HTH

Rick

Actions

This Discussion