EIGRP Neighborship Initial Update

[Menachem E]

Hi, from what I've observed, every time EIGRP establishes a neighborship, the initial update containing the prefixes sent by the router that sent the first INIT isn't acknowledged by the neighbor. Instead, it's always resent using unicast, and only then does it get acknowledged. I'm curious if anyone has insights into why this occurs?

[David Ruess]

Could you provide a packet capture of the observed behavior? Possible guess is the EIGRP process wasn't fully initialized and when the unicast is sent then the ACK happens.

And it is an Update packet correct? And is this a live environment or lab with virtual devices?

-David

[Menachem E]

Yes, its a virtual lab in CML and IOSv routers.

in the pcap the update with seq 68 is sent twice first multicast and then unicast

[David Ruess]

OK check out the contents of the packet. Lets start with the first update.

Update from 10.0.13.3

Update Sequence: 67

ACK: 0

The next update is from 10.0.13.1

Sequence: 118

ACK: 67

Its not quite in the order you expect but if you go line by line between al the updates and ACK they should match up. All updates were ACK in the first packet capture you sent. Update packet types also count as an ACK packet. It doesnt make sense to send an update packet AND an ACK packet to the same neighbors in a short period of time. So the Update packet includes the ACK inside so you kill 2 birds with one stone

Hope that helps

-David

[Menachem E]

The 3rd update sent (second from 10.0.13.3) with sequence 68 doesn't seem to get ACK till a few packets later and when it is sent again.

[David Ruess]

Yup. Also notice how that Update with a SEQ: 68 was a multicast. Then when the neighbor didn't respond with an ACK then it sent it again as a unicast directed at that neighbor. EIGRP was likely busy processing the routes and running the DUAL algorithm and just missed the Update. In that case it got a targeted Update message to ACK.

[Menachem E]

I see that happening every time I take a packet capture.

[David Ruess]

It could be a limitation of the resources in your virtual environment or in CML itself. It looks like it takes a few update packets to get all your networks conveyed to the neighbor. You could reduce the number of networks to only use one or two update packets to see if it still happens.

[Menachem E]

I tried it with only 2 routers and had the same thing. I guess it could be a CML thing, I only tried it in CML.

[David Ruess]

I just tried it in CML as well. I sent 9 routes over. I did notice it sent the update twice as a multicast even though it was ACK the first time and it even had a different sequence number. It was the same set of routes in both updates. 

[Menachem E]

Can you please send the pcap?

[David Ruess]

I can spin up the lab again tomorrow and I would be happy to provide the .pcap file.

[David Ruess]

Attached.

[Menachem E]

Or here in update with seq 83

[MHM Cisco World]

show ip eigrp interface detail <<- share this 

MHM