You might be wondering how EIGRP neighbors talk to each other. How do they know their neighbor is down? How do they know about recent updates on the network? How do they get information about their neighbors? How do they talk back to their neighbor? And how do they accept the message from their neighbor?
EIGRP like any other routing protocols has their own message types or packet types in order to communicate and synchronize within their network. These messages can be sent either in unicast or multicast and reliably or unreliable.
Let’s start with the “HELLO” message. Routing protocols are not snobbish like a human being (just kidding!). They greeted each other to know if they’re still doing fine. EIGRP’s Hello message is used for neighbor discovery, recovery, and to maintain adjacencies. It is sent to the multicast group address 126.96.36.199. In addition, it is sent with unreliable delivery which means that they do not require acknowledgement from the other device to know that it was received. Five seconds (5) is default hello interval for high bandwidth links like higher than T1 links, PPP or HDLC leased circuits, Frame Relay point-to-point subinterfaces, and etc. Sixty (60) seconds is the default for slower than T1 links.
We do not usually do this in a real-world scenario, but this is how we configure the hello interval:
As you can see, hello interval configured for se2/1 is 5 seconds.
Mashushi-SP(config)#int s2/1 Mashushi-SP(config-if)#ip hello Mashushi-SP(config-if)#ip hello-interval ? eigrp Enhanced Interior Gateway Routing Protocol (EIGRP) Mashushi-SP(config-if)#ip hello-interval eigrp ? <1-65535> Autonomous system number Mashushi-SP(config-if)#ip hello-interval eigrp 2 ? <1-65535> Seconds between hello transmissions Mashushi-SP(config-if)#ip hello-interval eigrp 2 6 ? Mashushi-SP(config-if)#ip hello-interval eigrp 2 6
Now, it is 6 seconds.
*Please note that the hello interval value, unlike OSPF, doesn’t need to match on other EIGRP devices to form adjacencies.
Unlike Hello message, “Update” message is sent via unicast or multicast with reliable delivery. This is sent as sent as unicast when synching its topology table with its neighbors and sent as multicast when convergence is completed or a new route is discovered. This message needs confirmation from the other end that this message is received because this type of message contains EIGRP routing updates.
A “Query” message, as the name implies, is used to inquire routes from other neighbors. It is sent via unicast or multicast in a reliable manner. It requests information like for example asking for feasible successor during the DUAL recomputation of routes.
Of course, when there is a Query, there is a “Reply.” Reply message is sent in response to a query. It is sent via unicasts reliably. It is very important like in Stuck-In-Active (SIA) situation, where it needs to wait for a Reply to each of its Query messages. Any neighbors that do not send a Reply message will be brought down by the router.
Finally, “Acknowledgement” message is used as a confirmation receipt sent for EIGRP Queries, Updates, and Reply. Like Hello message, it contains no data and is sent as unicast.
With all these message types, how does the router know what kind message does it have inside its EIGRP packet header?