Hi George,
I apologize for answering somewhat late. I had to do a few experiments to solidify my own understanding of what's going on, and it took me some time to get done.
Before I explain the process recorded in the PCAP file, I need to spend a quite a few words on how the Reliable Transport Protocol (RTP) works and how an EIGRP adjacency between two routers is set up.
As mentioned by almost every textbook and course about EIGRP, EIGRP uses its own transport protocol called the Reliable Transport Protocol (RTP; do not confuse with Real-time Transport Protocol used for voice and video streaming which is an independent protocol). The EIGRP packet header is in fact the RTP header. Because RTP is a reliable protocol, it must provide guaranteed in-order delivery and acknowledgements. To provide ordering and to facilitate reliable delivery, each EIGRP packet header contains a Sequence Number field (SeqNo). Although this field is present in all EIGRP packets, it is set to a non-zero value only for packets that need to be delivered reliably. Additionally, to allow a router to acknowledge the successful arrival of a packet, each EIGRP header contains an Acknowledgement Number field (AckNo). When acknowledging a packet, the AckNo field is set to the value of the SeqNo field of the packet that is being acknowledged. Obviously, packets whose SeqNo is set to 0 are not intended to be acknowledged, and packets whose AckNo is set to 0 do not carry any acknowledgement.
An EIGRP router can send an acknowledgement in two ways. The first, obvious one, is to use the Ack packet type. Funnily enough, this Ack packet type is nothing more than a plain Hello packet without a body, consisting only of EIGRP/RTP header whose AckNo field is set to the SeqNo of the acknowledged packet.
The second way of acknowledging a packet is to "piggyback" the acknowledgement onto another reliable packet being sent to the neighbor whose own packet the router wants to acknowledge. This piggybacking is done by appropriately setting the AckNo field in a reliable packet that is just ready to be sent to this neighbor (if there is such a packet). Remember, each EIGRP packet header contains both SeqNo and AckNo fields and they can be used simultaneously. Such a packet would then serve both its original purpose (Update, Query, Reply), and in addition, it would carry an acknowledgement for a packet received from that neighbor.
This all is very similar to how TCP works, by the way. You surely know that TCP headers contain both SeqNo and AckNo fields, and the sender of a TCP segment can both transmit its own data and acknowledge received data by simply setting these fields in a single TCP segment appropriately.
An important fact that might not be immediately obvious is that in RTP, acknowledgements can only be piggybacked onto unicast reliable packets to a specific neighbor. You cannot piggyback an acknowledgement onto a multicast packet because that doesn't make sense and could cause considerable confusion: A reliable packet is always received from a specific single neighbor, so you want only that neighbor to receive back your acknowledgement for that packet. If multiple neighbors received a single acknowledgement, it would not be certain to whose neighbor's packet you are referring to.
Two routers in EIGRP go through a sequence of states as they establish their adjacency. The following list sums the main steps and rules:
- Before a router can accept any non-Hello packet from its neighbor, it must first receive a Hello packet from this neighbor. This is because neighbors are discovered and made known by receiving their Hellos, and a router cannot accept a packet from a neighbor that is not known yet.
- As soon as the router receives a Hello from its neighbor, it puts the neighbor into a so-called Pending state. The purpose of the Pending state is to confirm bi-directional reachability between these neighbors, and to postpone processing of any significant packets till this bi-directional visibility has been confirmed. In this Pending state, the only packets accepted from this neighbor are Hello, an empty Update with the Init flag set (also called the Null Update), and an acknowledgement for the router's own Null Update (this can be received either as a standalone Ack packet, or as a piggybacked acknowledgement). For a neighbor to be moved from Pending to the Up state, the router must receive both a Null Update from this neighbor, and an acknowledgement for its own Null Update sent to this neighbor, in any order.
- After a router detects a neighbor by receiving a Hello from this neighbor, it expedites sending its own Hello to make sure that this neighbor can detect this router. Then it sends a Null Update to this neighbor.
- The neighbor should react in the same way, putting this router into the Pending state and sending its own Null Update. However, if it has received this router's Null Update, it needs to acknowledge it, and it can do it by piggybacking this acknowledgement on its Null Update.
- After this router receives a Null Update with the piggybacked acknowledgement from the neighbor, both requirements for putting the neighbor to the Up state are met (receiving a Null Update and receiving an acknowledgement from our own Null Update), so the router will indeed put the neighbor into the Up state. In addition, it will send an acknowledgement for the neighbor's Null Update.
- After the neighbor receives the acknowledgement for its Null Update, it will put this router into the Up state as well. Now the exchange of the routing information can start.
Finally, a word on how the multicast/unicast is used. EIGRP tries to use multicast whenever possible and sensible. When a router creates the first adjacency over an interface (meaning that before, there were no neighbors detected at all, and now, there is at least one neighbor detected), it will use multicasts to advertise its topology table contents (the Null Update packets used to establish adjacencies with individual neighbors will remain unicast, though). This is done for efficiency reasons: A newcoming router on a network has to advertise its topology database to every neighbor on the network, so using multicast is the obvious choice. However, if the router already has at least one adjacency over an interface, and only then detects a new neighbor, it is going to talk to this new neighbor via unicast. If the router used multicast, it would be sending its topology table also to neighbors that already have that information, so it would be a waste of effort. Additionally, if a packet has not been acknowledged in a certain time, it will be retransmitted to the unresponsive neighbor as a unicast.
Okay, after this primer on RTP, let's see your packet capture:
- Up to and including Packet 21: Hellos are seen from both routers. We can assume that both routers consider each other to be in the Pending state at this point.
- Packet 22: R1 sends a Null Update to R4, SeqNo=5, AckNo=0.
- Packet 24: R4 send a Null Update with Ack of R1's Null Update to R1, SeqNo=5, AckNo=5. At this point, R1 has received both Null Update from R4 and the acknowledgement for its own Null Update. After receiving Packet 24, R1 moves R4 to the Up state. R4 still considers R1 to be in the Pending state at this point - it waits for R1's acknowledgement.
- Packet 25: Because R1 consider R4 to be Up, it starts sending its topology table contents in this multicast Update, SeqNo=6, AckNo=0. Because this is R1's first adjacency over this particular interface, it uses multicast for this Update. Notice, however, that at this point, R4 still considers R1 to be in the Pending state, and so this packet will not be acknowledged and should be ignored by R4. This behavior on R1 is a flaw in implementation because the acknowledgement for R4's Null Update is sent right next in the upcoming Packet 26. R1 should have either sent the Ack first and this Update after (swapping Packets 25 and 26), or have the Ack piggybacked onto this Update in Packet 25. As a result, as we will see later, R4 will never acknowledge this multicast packet, and R1 will need to retransmit it in Packet 31.
- Packet 26: R1 sends an Ack to R4 for R4's Null Update, SeqNo=0, AckNo=5. Only now R4 puts R1 into the Up state.
- Packet 27: Because R4 considers R1 to be Up, it starts sending its topology table contents in this multicast Update, SeqNo=6, AckNo=0. Because this is R4's first adjacency over this particular itnerface, it uses multicast for this Update.
- Packet 28: R1 sends an Ack to R4 for the Update from Packet 27, SeqNo=0, AckNo=6.
- Packet 29: R4 sends a multicast Update, SeqNo=8, AckNo=0. The contents of this update are somewhat surprising: There are three networks for which R4 has decided to use R1 as its next hop, and so this Update is in fact a Split Horizon with Poisoned Reverse - you can check that the Delay metric of all three networks in this update is set to infinity. The question, however, is how could R4 learn about these networks from R1 when the only Update received from R1 - Packet 25 - was received at the time when R4 considered R1 to be still in the Pending state. It turns out that despite R4 has considered R1 to be Pending, it has still processed the contents of an Update received from it. This behavior on R4 is yet another flaw in implementation - if R4 does not acknowledge a packet, why is it processing its contents?
- Packet 30: R1 sends an Ack for the Update from Packet 29, SeqNo=0, AckNo=8.
- Packet 31: At this point, R1 decides that since the time of sending an Update in Packet 25 with SeqNo=6, an Ack should have been received from R4; however, this Ack never came. Therefore, R1 retransmits the packet again to R4 - retransmissions are always unicast. Note the SeqNo=6, the same SeqNo as in Packet 25, clearly indicating a retransmission. This Update also contains AckNo=8, duplicating the meaning of the Ack in Packet 30 (it is superfluous but not harmful). At the same time, note that the list of network in this packet is slightly shorter - this is because for some networks learned from previous updates, R1 is already using R4 as its next hop, and so they fall under the Split Horizon with Poisoned Reverse rule.
- Packet 32: R4 sends an Ack for the Update from Packet 31, SeqNo=0, AckNo=6.
- Packet 33: R1 send a multicast Update, SeqNo=8, AckNo=0. This Update contains the two missing networks we've seen in Packet 25 but haven't seen in Packet 31. These two networks are advertised as unreachable (Split Horizon with Poisoned Reverse).
- Packet 34: R4 sends an Ack for the Update from Packet 33, SeqNo=0, AckNo=8.
This is quite a long post and a complicated one so please feel welcome to take your time on it, and please come back and ask any further questions you might have!
Best regards,
Peter
