cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2785
Views
15
Helpful
9
Replies
George Servetas
Beginner

EIGRP startup process - Unicast and multicast Updates containing topology information

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

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

View solution in original post

9 REPLIES 9
Peter Paluch
Hall of Fame Cisco Employee

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

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:

  • Should unicast topology updates be sent during the startup process?
  • Should routes be poisoned partially during the startup process?

Many thanks in advance and best regards,

George

Peter Paluch
Hall of Fame Cisco Employee

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

View solution in original post

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

Peter Paluch
Hall of Fame Cisco Employee

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

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

Peter Paluch
Hall of Fame Cisco Employee

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

Peter Paluch
Hall of Fame Cisco Employee

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

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