That’s really helpful, thanks Laz!
I found out something interesting in cloudshark and I even saw this in my GNS3 Lab I did when I traced neighbor adjacency.
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).
The receiver of this seems to Acknowledge this Unicast Update Packet but not with an ACK as i thought it actually will use a Update Packet with the same Flag and also no information about the network yet.
Now the most confusing point is that the actual “Full Update” with all Network Information is sent as Multicast to all EIGRP Listeners (188.8.131.52) with a new Sequence number but later on it is also sent again as Unicast.
The full trace is here:
Can someone explain this trace to me ?
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!
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.
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!