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.
|