Detailed look at EIGRP Neighbor Adjacency

Hi,

I setup two routers, R1 and R2, with eigrp and made some observations (using a packet sniffer) which have confused me.

  1. 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).

  2. 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.

Thanks

Hello Samir

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 hope this has been helpful!

Laz

Hi Laz,

Thanks for the reply, it makes sense.

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.

11f6a5f8-c12b-40ca-92a5-8166bc443dc7.pcap (4.5 KB)

Thanks,

Sam

Hello Samir

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 hope this has been helpful!

Laz

Hi Laz,

Apologies, the topology diagram is below:

image

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.

Thanks for the detailed explanation.

Sam

Hello Samir

Thanks for sharing that.

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:
image

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…

I hope this has been helpful!

Laz

1 Like

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.