The IP header of the EIGRP packet specifies IP protocol number 88 within
it, and the maximum length of the packet will be the IP MTU of the
interface on which it is transmitted, most of the time 1500
octets. Following the IP header is the various Type/Length/Value (TLV)
triplets. These TLVs will not only carry the route entries but also
provide fields for the management of the DUAL process, multicast
sequencing, and IOS software versions from the router.
EIGRP sends updates and other information between routers using multicast packets to
224.0.0.10. For example in the topology below, R1 made a change in the topology and it
needs to send updates to R2 & R3. It sends multicast packets to EIGRP multicast address
224.0.0.10. Both R2 & R3 can receive the updates and acknowledge back to R1 using
unicast. Simple, right?
But what if R1 sends out updates, only R2 replies but R3 never does? In the case a router
sends out a multicast packet that must be reliable delivered (like in this case), an EIGRP
process will wait until the RTO (retransmission timeout) period has passed before
beginning a recovery action. This period is calculated from the SRTT (smooth round-trip
time). After R1 sends out updates it will wait for this period to expire. Then it makes a list of
all the neighbors from which it did not receive an Acknowledgement (ACK). Next it sends
out a packet telling these routers stop listening to multicast until they are been notified that
it is safe again. Finally the router will begin sending unicast packets with the information to
the routers that didn’t answer, continuing until they are caught up. In our example the
process will be like this:
1. R1 sends out updates to 224.0.0.10
2. R2 responds but R3 does not
3. R1 waits for the RTO period to expire
4. R1 then sends out an unreliable-multicast packet, called a sequence TLV (Type-Length-
Value) packet, which tells R3 not to listen to multicast packets any more
5. R1 continues sending any other muticast traffic it has and delivering all traffic, using
unicast to R3, until it acknowledges all the packets
6. Once R3 has caught up, R1 will send another sequence TLV, telling R3 to begin
listening to multicast again.
The sequence TLV packet contains a list of the nodes that should not listen to multicast
packets while the recovery takes place. But notice that the TLV packet in step 6 does not
contain any nodes in the list.
Note. In the case R3 still does not reply in step 4, R1 will attempt to retransmit the unicast
16 times or continue to retransmit until the hold time for the neighbor in question expires.
After this time, R1 will declare a retransmission limit exceeded error and will reset the
neighbor.
