I setup two routers, R1 and R2, with eigrp and made some observations (using a packet sniffer) which have confused me.
Is it possible for update packets to contain acknowledgements for other update packets? Because instead of a separate Ack packet, I can see R2 sending a unicast update (init) to R1 which contains a value under the acknowledgement number for R1’s previous unicast update (init).
You mention that unicast is used during the full exchange but I am seeing multicast, although still with sequence number and corresponding acknowledgements. It only seems to use unicast when the original multicast doesn’t get an ack response in time and has to resend.
Btw, I’m using CML 2.4 and the adjacency was formed after I cleared eigrp neighbours.
Yes it is. When we talk about EIGRP messages or packets, we often talk about each individual message type as a single discreet message. We get the impression that each one is sent separately and individually. However, part of designing network protocols involves making them efficient. This means that if multiple types of messages can all be packed into a single communication, it becomes much more efficient.
That’s what’s happening with the ACK. Actually, the ACK field within the EIGRP header exists in all message types. When an EIGRP router prepares an ACK, it waits for the next message of any type to be sent and populates the ACK field before sending it out. If no other EIGRP message is being sent at the time, then a Hello packet with the appropriate value in the ACK field is sent. The Hello packet is the smallest and most efficient message type to be sent to contain an ACK, so that’s how it is sent out.
EIGRP uses both unicast and multicast for its communication. What it will actually use in each case depends on things like topology, whether it’s the initial communication or subsequent communication, and the type of message being sent. The goal is to be as efficient as possible. The following Cisco documentation in PDF format contains a table (page 3) with the five types of packets and explains clearly when unicast and multicast are used.
In your particular case, can you share your PCAP file so we can see the specific exchange as well? Let us know.
I have uploaded the PCAP. And this is how I have interpreted it:
14 R10 sends an Update to R8 with the Init flag set. Unicast
16 R8 sends an Update to R10 with the Init flag set and an acknowledgment of R10’s update (No. 14). Unicast
17 R10 sends an Update containing all its routes. Multicast.
18 R10 sends an Ack to R8’s update Init. Unicast
19 R8 sends an Update containing routes. Multicast.
20 R10 sends an Ack to R8 for its updates. Unicast
21 R10 re-sends an Update containing all its routes (I guess because it hasn’t received an Ack yet). Unicast
22 R8 sends an Ack to R10
Aside from multicast being used instead of unicast for the synchronization, the following exchange is what I really don’t understand:
23 R10 sends an Update containing R8’s networks out of the interface connected to R8. Multicast
24 R8 sends and Ack back. Unicast
25 R8 sends an Update containing R10’s networks out of the interface connected to R10. Multicast
26 R10 sends an Ack back. Unicast
Why has the exchange in numbers 23-26 happened? Split horizon is not disabled on R8 or R10’s interface, but they are sending the routes back out of the interfaces they learned them from.
Btw, I’m using CML for this. Not sure if that makes a difference.
I had some trouble with your numbered list as the numbering mechanism on the site renumbered some of your packet numbers. I’ve edited your post to show the correct numbers.
Now, looking at the pcap file you shared and the description you provided, concerning packets 14 to 21, and comparing them to the detailed explanation of when unicast and multicast are used for EIGRP (as shared in my post), they do indeed conform to the description. A hello will always be sent as multicast.
An update that contains a new route will be sent as multicast. An ACK (denoted Hello (Ack) ) in Wireshark, are always unicast.
Now concerning packets 23 to 26 it looks like the following is happening:
packet 23 is an update sent from R10 to R8 (via multicast) and it is advertising 155.1.8.0/24, 155.1.58.0/24 and 150.1.8.8/32. Since it is multicast, it means that a new route was discovered and advertised.
packet 25 is an update sent from R8 to R10 (via multicast) and it is advertising the 150.1.10.10/32 network. Again, since it is multicast, this is a newly discovered route.
Now because we don’t have your topology in front of us with the location of the subnets, and how they are learned, my question is this. R10 is advertising 3 networks. How has R10 learned about those three networks? You mention that they were learned from R8? Similarly, where did R8 learn about the 150.1.10.10/32 network? Let us know so that we can continue to clarify this issue.
I did read the table on page 3 in the link you posted but it said “[Updates] are sent as unicasts when synchronizing topology tables with neighbors upon the EIGRP startup”, which I assumed what what was happening in the case of the exchange I uploaded in the pcap.
Now looking at the topology, and looking at packets 23 and 25 from your pcap file shared in your previous post, it does seem uncharacteristic of EIGRP to have R10 send an update containing 155.1.0.8/24 to R8 since R8 originally advertised that network. And the same thing happened in the other direction for packet 25.
I’m looking at the PCAP file more closely now, and I see that packet 23 has a source of 155.1.108.10 and it is advertising 155.1.8.0/24, 155.1.58.0/24, and 150.1.8.8/32. See below:
These are all the networks hanging off of R8. Similarly, in packet 25, I see 155.1.10.10/32 being advertised which is the loopback off of R10.
Could it be that you have assigned the .8 address to R10 and the .10 address to R8? Check it out and let us know…
In wireshark i see that split horizon is done via route poisoning; in actuality, routers do advertised back the routes in the same interface where they learned them from, but with a delay of infinity.
Not sure if this behavior is the same on all router versions though.
Indeed you are correct. I actually went into Wireshark and verified this as well. I see that an EIGRP neighbor will advertise a route learned from its neighbor back out of the same interface, but with a scaled delay value of 4,294,967,295, which is indeed infinity. Take a look at this wireshark output:
This is an update message sent from R2 to R1, where R1 has already advertised the 1.1.1.0/24 network to R2. So here R2 is re-advertising this destination back to R1, but with a Scaled Delay of infinity.
Now according to the RFC on EIGRP, this behavior above is poison reverse. Split horizon is considered a different rule. Both achieve similar results, but they are distinct from each other. Specifically, it says:
In EIGRP, split horizon suppresses a QUERY, where as poison reverse advertises a destination as unreachable.
I understand that the first two UPDATE packets are to verify bidirectional unicast connectivity.
However, what’s happening next is pretty confusing to me.
Packet No. 5 contains the actual route information for 1.1.1.0/24, Packet No.7 also contains the route information from the other router for 2.2.2.0/24.
Then Packet No.9 contains route information for 1.1.1.0/24 again and so does Packet No.11.
What exactly is happening there? Why is the router advertising the same information 3 times?
And please, why are the packets that contain the actual route information sent as Multicast but then also as Unicast?
Unfortunately, I don’t have a clear-cut answer for you that will explain all of the packets we see in the Wireshark capture. However, there are some characteristics of EIGRP and the underlying transport layer protocol it uses that can explain some of what we see.
First of all, keep in mind that EIGRP operates both using multicast and unicast. Initially, a prefix will be advertised using multicast destination addresses so that it can be advertised to all neighbors in a single go. Unicast updates are sent in response to queries or to provide specific updates to a particular neighbor. In this case, the unicast Update packets 3, 4, and 11 are likely part of a specific conversation between R1 and R2. These updates do not contain any new routes because they might be part of a convergence process where no new routes are available yet, or they could be part of the EIGRP Reliable Transport Protocol (RTP) acknowledging receipt of an update.
RTP (not to be confused with Real-Time Transport Protocol) is a Cisco proprietary transport layer protocol that is used exclusively for the exchange of EIGRP packets. See this post for more info about RTP and how it appears in Wireshark.
Now RTP may require that some packets be resent to achieve reliability based on its operation and functionality. More info about RTP can be found at this Cisco Press article. In addition, detailed information about how RTP behaves in EIGRP exchanges can be found in the relevant RFC for EIGRP.
You might see multiple Update packets with the same routes due to the Reliable Multicast feature of EIGRP. If the EIGRP router doesn’t get a reply from a neighbor via the multicast, it will use unicasts to resend the same data. If it does not get a reply from the neighbor after 16 unicast attempts, it declares the router dead. This process is known as reliable multicast and may be behind some of the repeated updates.
So these describe just some of the logic of the mechanisms used by EIGRP, and may help to explain why we see what we see in our packet captures…
