This is an excellent question. EIGRP, after sending its initial hellos, will often send an empty Update packet to verify reachability between neighbors before beginning to exchange routes. You can see this in the cloudshark capture that @ReneMolenaar shared on the forum. You can see that there is an update from one router to the other, and another update in the other direction. It is only after those two updates occur that the next update actually contains routes.
Another issue involves the fact that you must have routes on your routers to share. In the above topology, do you have any loopbacks that you actually share with EIGRP? If not, the updates will be empty, since there are no attached networks to R1 and R2 to exchange prefixes, so updates will indeed be empty.
Yes, loopbacks are configured on the interfaces and advertised in eigrp. In my case they are exchange using multicast after sending empty updates. My interest, is the reason why, What is right? In the capture from renemolnar they are sent using unicast.
When you configure neighbors statically, all updates are unicast. However, when you configure them using the default neighbor discovery, they initially exchange updates using unicast, but then subsequently use multicast. This is described in Reneâs post below and seems to also be the case in your wireshark output, where the first two updates are exchanged with unicast, while the rest are multicast.
Why EIGRP neighbor sends each other a blank Update message with a flag set called init ??.
The neighbor discovery hello and the acknowledge hello op code are different ??.
Which EIGRP updates are multicast and unicast ??
An empty update is called a NULL update packet. This is used to help ensure unicast and multicast packet delivery. This is explained in detail in RFC7868 which describes EIGRP:
The opcode for a Hello and an acknowledgment hello is the same. However, the value of the Acknowledgment Number field will tell you if the message is a Hello or an Ack hello. In the above mentioned RFC, it describes it in this way:
Acknowledgment Number: The 32-bit sequence number that is being acknowledged with respect to the receiver of the packet. If the value is 0, there is no acknowledgment present. A non-zero value can only be present in unicast-addressed packets. A HELLO packet with a non-zero ACK field should be decoded as an ACK packet rather than a HELLO packet.
Why in the image here is ACK field is showing 0 .??
One thing i just want to know that , in TCP there is an ACK is based on Seq number+1 , In case of EIGRP , How it maintain the AcK, Is based on SEQ+1 in eigrp also ??
The ACK field found inside the EIGRP header is used to identify the type of packet that is being sent as well as to keep track of communications between specific EIGRP neighbors.
A hello packet with an ACK of zero is treated as a simple hello packet.
A hello packet with a non-zero ACK value is treated as an ACK packet, that is, an acknowledgment to an EIGRP update. The ACK value found in the field contans the sequence number last heard from the neighbor to which the packet is being sent. That sequence number can be found in the header of the EIGRP update.
Thank you very much. Itâs very helpful. RTP Protocol is (Real-Time Transport protocol) that used in multi-media communications or different Protocol (Reliable Transport Protocol) ?
The infinite metric for EIGRP is a value of 4,294,967,295. This is the maximum value that the 32-bit metric can have. EIGRP packets of all types that contain information about routes, including Updates as well as Replies, will contain the metric not as a single number but in its constituent parts, such as delay, BW, MTU, reliability, and load. Take a look at this portion of an EIGRP update that includes information about a route including the metric.
You can see the constituent components of the metric. When each EIGRP packet is received by an EIGRP router, that metric is calculated based on those metric values. If that value is greater than or equal to 4,294,967,295, the metric is considered infinite.
Now what I have mentioned until now is valid for legacy EIGRP. When using wide metrics, the metric is defined using a 64-bit value. The same logic for infinite metrics applies. You can find out more information about wide metrics at the following lesson:
If I shutdown the link between R2 and R3, it wonât learn about the destination (10.0.0.0/30) from it, so it will only receive the EIGRP UPDATE packet from R1.
However, if I then decide to enable that link on R2, it will receive the UPDATE packet from R3 and then also advertise it to R1.
But doesnât the rule say not to advertise a route out the interface it was learned on?
In your example, the split horizon rule is not being violated. When you reenable the link between R1 and R2, R1 will receive an UPDATE from R3 about 10.0.0.0/30, and it will resend it to R1. Note that this UPDATE containing the network 10.0.0.0/30 was received from R3 (via G0/1) and sent out of G0/0to R1. So the split horizon rule was not violated.
So the difference is that in this case, R2 is saying to R1 with its update: âYou can reach the 10.0.0.0/30 network through me because I have a route to that destination via R3.â
If the split horizon rule was violated, R2 would be saying the following to R1 with its update: âYou can reach the 10.0.0.0/30 network through me because I have a route to that destination via R1.â
You can immediately see that the second case would cause a problem because if the link between R1 and R3 failed, R1 would try to reach the 10.0.0.0/30 network through R2, and R2 would try to reach the 10.0.0.0/30 network through R1, thus resulting in a ping-pong match between the two routers.
The first case would be valid, because in the event of the same failure, R1 would try to reach 10.0.0.0/30 via R2, and R2 in turn will try to reach it via R3, thus avoiding the pingpong match.
Now I believe that your concern here is that even if the split horizon rule wasnât violated, R1 is still learning about the 10.0.0.0/30 network from two different sources. Doesnât that cause a loop even if the split horizon rule is not violated? Well, no because the metrics take care of that. R1 will not choose to reach the 10.0.0.0/30 network via R2 because it is not the shortest path. Similarly, R2 will not reach the network via R1, because itâs not the shortest path. Does that make sense?
