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.
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:
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 188.8.131.52. 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 192.168.1.0 /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):
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.