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

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?

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

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?