As you may know, EIGRP has been published as RFC draft since February 2013. I have therefore decided to take a closer look at some implementation details of the DUAL algorithm. I was surprised to find that the draft was not 100% accurate – but, let me clarify…

However, before going any further, let’s quickly review some terminology.

  • Reported Distance is the best metric from the neighbours perspective; EIGRP only advertises out routes with the best metric. This means that the topology table will consist of best metrics as seen by neighbours.
  • The Feasible Distance is really just a fancy way of referring to the best metric, after adding the cost on its own interface where the update was received. The Feasible Distance will be the (Reported Distance + Incoming-Interface-Metric). 
  • Another fancy term is the Successor Route – they should’ve just called it, best route – this is in fact the route that gets installed in the routing table and, the metric will match the Feasible Distance. 
  • The Feasible Successor is really a backup route which meets the feasibility condition – the reported distance must be lower than the best metric. 
  • The Feasibility condition is of much importance for it is used by DUAL to avoid loops. Route-Poisoning is also used, though in EIGRP’s case, it is not used for loop-avoidance rather, to further avoid needless updates, hence avoiding unnecessary traffic. 

NOTE: Route Poisoining is same as split-horizon taken to the next-level – with split-horizon, the router will *not* advertise a route out the same interface the route was learnt; route-poisoning however, will advertise the route out with an infinite metric effectively causing the remote peer, to ignore the route!

The principle behind this is that it is better to say something, than not saying anything at all. 


Going further, I will be using the topology below:


I am here running EIGRP with custom costs set on each interface. For the purpose of this lab, I have also configured the routing process to use the Delay only, when calculating the metric – at the moment, the actual metric is calculated as:

metric = Sum (Delay) * 256


Some things I found …

I. Unicast vs. Multicast Updates

As per the actual RFC draft, the 1st update will be unicast, just after acknowledging the neighbour; all further updates will be multicast using the destination mcast IP address of Every time an update is multicasted, a timer is started within which the router must received acknowledgment for the sent update – should this not happen, a retransmission will occur, only this time, as Unicast.

What the draft *does not* mention is that, by default, over serial links, updates are always sent Unicast. This can be confirm by capturing the EIGRP updates as well as, by looking at the the show ip eigrp interfaces detail command output:



II. The Topology Table and the Infinite Metric

For as long as equal delay is set throughout the entire network, we would see the following possible routes towards /24 network, from R3 & R1 respectively; you can also see below the respective topology tables.



Notice that in both cases, the 1st route is the best route – this would be added to the routing table. The 2nd route, has been added to the topology table by DUAL algorithm despite not being feasible successors (neither match the feasibility condition – in this case, the best reported metric is 51200 which is *not* lower than the best metric of 51200).

Next, I will change the metrics (delay) on the link connecting routers R2 and R3 so that different paths are preferred.



Notice that R1 does not have list the non-feasible successor anymore, even though the all-links keyword is still being used! So why is that?

To find out, I have ran the command following commands and captured the traffic too (just to be sure):

debug ip eigrp 1
debug eigrp packet update
debug eigrp fsm

I found that EIGRP, when installing a route in the routing table, it will also send an update for the same route with an Infinite metric set – this effectively tells the remote router to discard that same route. The sending router is basically saying: I can reach the network through you, so please, don’t even think about the possibility of reaching that same network through me otherwise we’d be looping between each other. 

When R3 installs the best route via R1, it sends R1 such an update, with the infinite metric set (429467295) – see below:


NOTE: This is in fact the process of route-poisoning / split-horizon. However, the poisoned update seems to happen only for those routes which get installed in the routing table, i.e. best routes only.

Again, I did not find a reference about route-poisoning in the RFC draft.


Thank you,
View Rafael A Couto Cabral's profile on LinkedIn

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>