EIGRP - Delay Convergence

Unanswered Question
Jun 14th, 2010


Does anyone know of a way of stopping EIGRP from converging back to a link if it is more preferable once it becomes available again?


Two sites, two links, 100Mb primary and 10Mb back up. EIGRP domain across the two sites, but the 10Mb is BGP which is redistributed.

I have experienced an issue with a flapping link where the timers expire, link goes down, then comes back up for 30 seconds, converges back and then repeates 111 times!

To reduce the times this happens, am I able to hold the route on the resilient link for a period to give the primary link chance to settle, or have EIGRP "test" the preferable link for a time before it is chosen?

The latter I dont think will be possible, but is there a hold timer that can be configured for the first....?

Thanks in advance

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)

EIGRP timers by default - are 5 second hello and 15 seconds hold.  Typically the hold is 3 times the hello - these timers are configurable on a per link basis.

On the 10mbs link interface you can configure the timers to be longer or shorter - whatever you prefer, the config is:-

ip hello-interval eigrp <> <>
ip hold-time eigrp <> <>


Wantser1981_2 Tue, 06/15/2010 - 00:34

Hi Andrew,

Thanks for the info.

I am okay with the hello and hold timers of the neighbours, however am interested in trying to work out how I might hold on to a path in the active topology when a relationship is formed and a more desirable route is identified. So the oposite to loosing a neighbour. A wait time when learning about one so that I can reduce the risk of multiple topology changes when a more desirable link is flapping 3-4 times a minute and traffic is stuttering due to the hold times of loosing a neighbour. I dont want to decrease these times preferably.


Wantser1981_2 Tue, 06/15/2010 - 02:12

I get the whole point of a dynamic routing protocol thanks, but I am concerned with the topologies return to normal after the most attractive route fails.

But what I am asking, is is there anyway to protect against a better primary link that is constantly failing in the frequency I have mentioned which means the quick convergency, that is required on total failure (off, that is it!), doesnt become an issue if the link is bouncing around all over the place causing quick convergence after quick convergence. A back off period, if you like, which means that instead of installing a better link straight away, a time can be chosen to wait so that you increase network stability even if it is for 10 minutes for example. Stay on the backup link for a period, before going back to primary when it become available. Similar to STP Listening and Learning I suppose.....

Like I said, this may be wishful thinking as I dont recall such a feature....hence the question.



This Discussion