01-23-2016 09:03 AM - edited 03-05-2019 03:11 AM
I have a question regarding the startup process of EIGRP. I have noticed that a unicast update is sent in a broadcast segment containing topology information. Why is this?
Below is a screenshot of the EIGRP startup process and of two Update messages; one multicast and one unicast, both containing the same sequence number.
Solved! Go to Solution.
01-24-2016 12:04 PM
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:
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:
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
01-23-2016 09:41 AM
Hi George,
What exact IOS version are you using? Around 12.4 - 12.4T, the adjacency startup in EIGRP exhibited certain ill symptoms that were corrected in 15.x versions. This looks like one of them.
In addition, can you please post the PCAP file containing the EIGRP communication?
Best regards,
Peter
01-24-2016 10:59 AM
Hello Peter and thank you for your prompt reply. I am using code 15.2(4)S7 in GNS3. Please find attached the capture file and the network topology.
Furthermore, the draft states:
When two routers first become neighbors, they exchange topology tables during startup mode. For each destination a router receives during startup mode, it advertises the same destination back to its new neighbor with a maximum metric (Poison Route).
However in the capture is seen that the new neighbors poison only the routes for which they can no longer be considered as the best next hop.
Which is the normal protocol behavior?
That is:
Many thanks in advance and best regards,
George
01-24-2016 12:04 PM
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:
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:
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
02-27-2016 09:09 AM
Peter I have another question.
The sequence number is incremented from SeqNo=6 to SeqNo8. Is this another flaw in the implementation of EIGRP for this specific IOS?
Finally can you confirm the following?
During the startup process, only the Null Updates are unicast. Other updates containing topology information (advertising routes or poisioning routes) are multicast in a broadcast segment.
Many thanks in advance and best regards,
George Servetas
02-27-2016 10:35 AM
Hi George,
The sequence number is incremented from SeqNo=6 to SeqNo8. Is this another flaw in the implementation of EIGRP for this specific IOS?
No, I do not think so. If, after sending a reliable packet with SeqNo=6 through the interface you were capturing packets on, this router needed to send another reliable packet through a different interface, it would increase the sequence number to 7. The next reliable packet sent through the interface being captured would carry sequence number 8. A sequence number is not maintained on a per-neighbor or a per-interface basis - rather, it is a per-EIGRP-process variable. Sequence numbers observed on one particular interface can exhibit gaps but they must be monotonous (ever increasing). A gap in sequence numbering does not necessarily indicate a packet loss.
During the startup process, only the Null Updates are unicast. Other updates containing topology information (advertising routes or poisioning routes) are multicast in a broadcast segment.
Not necessarily. Null Updates will be unicasted but the subsequent Updates will be multicasted or unicasted depending on whether the router is building an adjacency over an interface with no prior adjacencies, or whether it already has existing adjacencies over that interface.
If a router establishes an adjacency over an interface that previously had no adjacencies, it will send the Updates as multicast because there is a fair chance that there are multiple neighbors on the segment, and the router needs to synchronize with all of them. If, however, the interface already has at least one fully synchronized adjacency, and a new neighbor is detected, the router will synchronize to this neighbor using unicasted Updates.
Consider this scenario: R1 and R2 connected via a switch, detecting themselves - they will sync to each other using multicasts. Afterwards, R3 joins the segment. R3 will sync to R1 and R2 using multicasts; however, R1 and R2 will sync to R3 using unicasts. Finally, R4 joins the segment. R4 will sync to R1, R2, and R3 using multicasts, while R1, R2, and R3 will sync to R4 using unicasts.
Please feel welcome to ask further!
Best regards,
Peter
02-28-2016 04:55 AM
Thank you very much Peter once more for your detailed and prompt reply.
Another question that I have, arising from your reply is as follows:
In the following topology, assuming that all links between the following routers are broadcast links and that EIGRP peerings have formed between R1 ↔ R2, R2 ↔ R3 and R3 ↔ R4:
R1 --- R2
| |
R4 --- R3
If EIGRP is enabled on the link R1 ↔ R4, those peers after concluding the EIGRP 3-way handshake, they will multicast their topology information, on the broadcast segment R1 ↔ R4, since there are no other adjacencies on this link.
At the same time, they will unicast topology information regarding the network R1 ↔ R4, to their peers R2 and R3 respectively, since adjacencies between R1 ↔ R2 and R3 ↔ R4 have already been formed.
Am I correct in my assumption?
Your help has been invaluable in demystifying the protocol behaviour.
Many thanks again for your help and best wishes,
George
03-11-2016 12:18 AM
Hi George,
I apologize for responding this late - I have missed your question earlier. I am sorry.
If EIGRP is enabled on the link R1 ↔ R4, those peers after concluding the EIGRP 3-way handshake, they will multicast their topology information, on the broadcast segment R1 ↔ R4, since there are no other adjacencies on this link.
Yes. Keep in mind that the motivation for the multicast here is: "I'm starting over an interface where I had no neighbors before, and now there is at least one - so it's possible there are actually many of them, and I need to talk to all of them because everybody is interested in knowing what I know - ideally at once, so let's use multicast".
At the same time, they will unicast topology information regarding the network R1 ↔ R4, to their peers R2 and R3 respectively, since adjacencies between R1 ↔ R2 and R3 ↔ R4 have already been formed.
Not really. Even though there are only two neighbors on each of those links, the idea is: "I have news that is relevant to anyone on the link, so I am going to multicast the update."
When trying to decide on the use of multicasts vs. unicasts in EIGRP, always ask yourself a question: For whom would the information be useful? Is it just a single neighbor out of many neighbors, or are those potentially all neighbors on the wire, regardless of how many?
As always, feel welcome to ask further!
Best regards,
Peter
01-24-2016 12:08 PM
George,
Regarding the draft, it is still being imprecise in a number of places, so at this point, I suggest not taking it as a definitive reference. Being generously accepted as one of its co-authors, I can say that we're currently in the process of overhauling it and removing the ambiguosities - it will take some time but we'll get it done.
Best regards,
Peter
02-21-2016 08:08 AM
Thank you Peter for your detailed reply, for analyzing the packet capture, for explaining the EIGRP 3-way handshake process, for explaining how EIGRP routers initialy establish a peeing, exchange topology information and poison routes.
Many thanks again and best wishes,
George
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: