6.3 EIGRP Data Structures
6.3.3 EIGRP packet types
EIGRP uses five specialized packets to maintain its various routing tables. Each packet type performs a specific function in support of routing table maintenance. The five EIGRP packet types are
  • Hello
  • Acknowledgment
  • Update
  • Query
  • Reply

Given that EIGRP is a proprietary Cisco Systems product, its detailed specifications --- including the size and structure of its internal packet type --- are not made public. Consequently, the following survey of the six EIGRP packet types is limited to their functional description and uses.

Hello Packets

Hello packets, as their name implies, are used to discover (or rediscover) and track other EIGRP routers in the network. Rediscovering neighbors can sometimes occur during convergence. In theory, a failure in the network changes its topology. If, during the process of convergence, neighboring routers lose contact for a moment, the hello process will eventually reestablish the relationship. Rediscovering a lost neighbor is known as recovery or rediscovery.

EIGRP nodes transmit hello packets at fixed intervals known as hello intervals. The default interval depends on the bandwidth available per interface. On relatively low-bandwidth (T1 or less) multipoint circuits (such as multipoint Frame Relay, ATM, and X.25 circuits), EIGRP uses a 60-second hello interval. Higher-bandwidth interfaces include point-to-point serial links, multipoint circuits with bandwidth greater than T1, and LANs. EIGRP uses a 5-second hello interval on such interfaces. An EIGRP node uses its neighbor table to keep track of the other EIGRP routers in its network. Included in this table is the last time that each neighbor was heard from. Such contact may have been made via hello packets or any other EIGRP packet type. The point is that an EIGRP router considers a neighbor to be functional as long as it is capable of some form of communication.

There must be a finite period that an EIGRP router endures before concluding that a silent neighbor is actually out of service. This period is known as the hold time, which is tracked by the hold timer. If a router's hold timer counts down to zero, and a neighbor still hasn't been heard from, that router informs DUAL of the change. DUAL initiates convergence among the surviving routers in the network.

Hold time is usually defaulted to three times the hello interval for an interface. Therefore, hold times are defaulted to 180 and 15 seconds respectively for low- and high-bandwidth interfaces. For each router interface, a network administrator may also manually configure both the hello interval and hold times. Changing the hello interval does not automatically change the hold time, however. Each interval is manipulated individually. If you manually change the value of one, you should also manually change the value of the other.

Note: EIGRP enables a stable relationship between neighboring routers, even if they have different hold times or hello intervals! Hold time is one of the pieces of information exchanged via hello packets and stored in the neighbor table. Therefore, EIGRP routers won't prematurely assume that a neighbor is out of service just because it has a longer-than-normal hello interval or hold time. This capability is unique to EIGRP. OSPF, another protocol that uses hello intervals, requires both routers to have matching hold times and hello intervals.

Acknowledgment Packets

Acknowledgment packets are used to acknowledge receipt of any EIGRP packet that requires reliable delivery. As explained in the section titled "Reliable Transport Protocol," a packet's receipt must be acknowledged if it is to be delivered reliably. Otherwise, the source router would have no way of knowing whether the packet was actually delivered. EIGRP's standalone acknowledgment packet is actually a hello packet without any data. Acknowledgments (or Acks) can be differentiated from hello packets in another way, too. Hellos are always multicast, whereas acknowledgments are always sent to a single, specific IP address. This is known as unicasting. Hello and acknowledgment packets, incidentally, do not require acknowledgment. A router running EIGRP may also piggyback the acknowledgement information onto others' unicast packets, such as replies, being sent to the peer.

Update Packets

The update packet is used to convey routing information to known destinations. This packet type actually has two uses. The first use is to provide a complete dump of topological data to a newly discovered neighbor. Whenever a new neighbor is discovered (that is, a new router is added to an existing network), EIGRP nodes transmit update packets to this new neighbor for use in constructing its initial topology table. A series of update packets might be needed to send a complete set of topology information to the new router.

The second use of the update packet would be more typical of daily operation within an EIGRP network. Updates would be sent whenever a change in either topology or link metric occurred. These updates would be forwarded broadly to all known neighbors. The way to differentiate between these two uses is to check the destination address of the update packets. Updates sent to a new neighbor will be directly addressed to that neighbor. Otherwise, update packets usually use an IP multicast address to forward to multiple neighbors simultaneously. The update packet is always transmitted reliably regardless of whether it is unicast or multicast.

One important improvement over many other routing protocol is that EIGRP does not transmit updates of complete routing tables. Instead, EIGRP uses non-periodic, incremental routing updates. That is, EIGRP nodes convey only the information that has changed, when it has changed. By transmitting only the deltas, EIGRP converges more quickly and consumes much less bandwidth in the process.

Query and Reply Packets

Two of EIGRP's packet types, query and reply, are functionally interrelated. As a result, it doesn't make sense to examine them separately. Query packets are used whenever a router needs specific information from one or all of its neighbors. A reply packet is used to respond to a query.

One example showing the interaction of queries and replies is found in the process of finding an alternative route to a destination for which a router has lost its only routes. A router can send query packets to request information from neighbors about alternative paths that may be available. Neighboring routers would reply with their successor information.

Another example of the use of a query packet would be if a router receives a request for a destination that it previously didn't know about. In this case, the router receiving the query would immediately reply that it, also, doesn't know about this destination. This is one way in which queries are bounded in an EIGRP network. Unlike queries, which can be multicast, it doesn't make sense to multicast a reply. Instead, replies are unicast directly back to the originator of the query.

Queries are only sent when a destination becomes active. Otherwise, if the network is stable, and all routes are passive, there is no need to waste network bandwidth by requesting (and receiving) routing information. An additional bandwidth-conserving tactic is the capability to multicast queries. As demonstrated in the preceding two examples, queries can be both unicast and multicast. Regardless of which address type is used, queries are always transmitted reliably. Replies are also always transmitted reliably.