Detailed look at EIGRP Neighbor Adjacency

[lagapidis (Lazarus Agapidis)]

Hello Marcel

It’s great to see that you’re looking at the operation of EIGRP in such detail, it helps to learn more about the protocol’s operation!

@marcel.hofheinz

Seems like that the initial Update Packet is Unicasted to it’s Neighbor after receiving a Hello Packet but that Update at that time doesn’t contain any Network Information, only a Flag is set (Init Flag).

What EIGRP will do is it will initially send an empty update during the neighbor establishment phase. After hellos are exchanged, an empty update will be sent to verify unicast and multicast reachability between the neighbors before beginning to exchange routes.

This sequence is described in detail in RFC7868 which fully describes the neighbor adjacency procedure using UPDATE packets.

@marcel.hofheinz

Now the most confusing point is that the actual “Full Update” with all Network Information is sent as Multicast to all EIGRP Listeners (224.0.0.10) with a new Sequence number but later on it is also sent again as Unicast.

According to the RFC, Reliable Transport Protocol (RTP) is used to provide guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Now it states in the RFC that:

The UPDATE exchange sequence requires UPDATE packets sent to be delivered reliably. If the UPDATE or the ACK packet is lost on the network, the UPDATE packet will be retransmitted. The initial packet is always multicast and subsequent retransmissions are unicast addressed. The acknowledgments sent are always unicast addressed.

You can find the above text specifically at the following location.

So there are cases where an update will indeed be sent via unicast, as is the case in the particular packet capture you shared.

I hope this has been helpful!

Laz