EIGRP neighborship Packet Exchange

[surendrasinghtanwar667]

During EIGRP neighborship form process both router exchange the update packet and first packet is init and second update packets contain the routes. But my doubt is first R1 has send a update packet on multicast and then again it send unicast in the same way R2 has followed the same process?? Can someone please clear my doubt 

[M02@rt37]

Hello @surendrasinghtanwar667 

When Router 1 (R1) and Router 2 (R2) establish their neighborship, the first Update packet from R1 will be multicast, advertising its routing information to all potential neighbors. After this, R1 sends unicast Updates directly to R2 to finalize the exchange. R2 follows a similar process: it multicasts its initial routing information and then unicasts to R1 for further synchronization.

[David Ruess]

Hello,

Basically the device is advertising itself on the link. It uses multicast first to be efficient (as in talk to everyone listening on this link at the same time). Then once it hears responses it can just end the unicast updates to the neighbor. I believe in some instances it will send multicast updates as well.

As an example, say you're in a room full of people. You shout (multicast) "Hey I want to talk EIGRP protocol with people. Anyone listening for that keyword can come over and you can talk to individuals (unicast) about EIGRP.

Hope that helps

-David

[surendrasinghtanwar667]

but see R1 has send the update packet twice time because each and everytime i get different outcome sometime i am able to see single multicast update and sometime more then 1, Idk why 

[David Ruess]

Thats because EIGRP Update packets are sent reliably. If it's not Acknowledged by the neighbor, then it will send it again until it is up to a certain amount. When you dive deeper into the packet you should see a sequence number of what's being sent vs what's being acknowledged. It's likely your device hadn't fully initialized to ACK the update packet or maybe it got lost on the link. Sometimes it happens, which is why devices retransmit packet. AS you mentioned sometimes you only see one. That means it made it successfully the first time.

[paul driver]

Hello
The rtrs will send mc to the eigrp group address 224.0.0.10  if no answer is received the rtr it will resend numerous times (16)  via a unicast before it declares the peer dead/unreachable, this is known as Reliable Multicast.

[MHM Cisco World]

the devil in detail 

open the update message unicast one and compare to multicast 
you can see that update unicast is empty it only for checking the real update that contain prefix is send in multicast.

MHM

[paul driver]

Hello
FYI -With that lab setup , you dont even require mc, you could make the adjacency's all unicast and remove the BW  K value so you just use delay much easier to path manipulate.

[MHM Cisco World]

I build general lab' when I have issue with eigrp I retrun to it.

My concern here is  packet capture of eigrp message.

Thanks 

MHM

[surendrasinghtanwar667]

"Could you please specify the image used in your topology?"

[MHM Cisco World]

Sorry I don't get it, 

I share  packet capture detail for both 

Multicast and unicast update, you can see the destination to know which capture it is.

MHM

[surendrasinghtanwar667]

which router image you are using in the gns3 

[M02@rt37]

Thanks @MHM Cisco World for that sharing.

[MHM Cisco World]

You are welcome friend

MHM

[surendrasinghtanwar667]

As you mentioned, multicast updates are used to share routes; however, this isn't entirely accurate. You can observe that when R1 sends updates via multicast, it still shares internal routes. Additionally, during unicast communication, it continues sharing routes as well.