EIGRP uses five different types of packets to communicate with its neighbors: Hello, Update, Acknowledgment, Query, and Reply. Depending on the packet type, EIGRP sends them with reliable or unreliable delivery, and as unicast, multicast, or sometimes both. These packet types are sometimes also referred to as EIGRP packet formats or EIGRP messages. Here’s a detailed look at each one.
EIGRP Hello Packets
EIGRP uses Hello packets to discover EIGRP-enabled neighbors on directly connected links. A router uses hello packets to form EIGRP neighbor adjacencies, also known as neighbor relationships. The Hello packet is sent as an IPv4 or IPv6 multicast, using unreliable delivery — meaning it does not require an acknowledgment packet in return.
The IPv4 address 224.0.0.10 is reserved for IPv4 Hello packet multicasting, and the IPv6 address FF02::A is reserved for IPv6 Hello packet multicasting. On most networks, EIGRP Hello packets are sent as multicast packets every five seconds. On some networks, however — non-broadcast multi-access (NBMA) networks such as X.25, Frame Relay, and Asynchronous Transfer Mode (ATM) interfaces with access links of T1 (1.544 Mb/s) or slower — the Hello interval is 60 seconds instead, to account for the lower available bandwidth.
Hello packets also maintain previously established adjacencies. An EIGRP-enabled router assumes that as long as it keeps receiving Hello packets from a neighbor, that neighbor and its advertised routes remain usable. EIGRP uses a hold timer to determine the maximum time a router should wait to receive the next Hello before declaring that neighbor unreachable.
The default hold time is three times the Hello interval — 15 seconds on Ethernet and higher-speed T1 links, and 180 seconds on slower NBMA networks. If the hold timer expires, EIGRP declares the affected route down, and DUAL (Diffusing Update Algorithm), EIGRP’s route-computation engine, searches for a new path by sending out Query packets to the router’s remaining neighbors.
EIGRP Update Packets
EIGRP Update packets carry routing information. Unlike traditional distance-vector protocols such as RIP, EIGRP does not send periodic full-table updates, and its route entries do not expire on a timer. Instead, EIGRP sends an Update only when something actually changes in the network — a new network becomes available, an existing network becomes unavailable, or the routing metric for an existing network changes.
EIGRP uses the terms partial and bounded to describe how it sends updates. “Partial” means the update contains only the specific route information that changed, not the full routing table. “Bounded” means that partial update is sent only to the routers actually affected by the change, rather than flooded across the entire network. Together, partial and bounded updates minimize the bandwidth EIGRP consumes compared to protocols that broadcast their entire routing table on a schedule.
EIGRP propagates routing information to its neighbors using reliable delivery, meaning the sending router requires an acknowledgment for each Update it sends. An initial Update sent to a newly discovered neighbor is sent as unicast; an Update triggered by a route change, once neighbors are synchronized, is typically sent as multicast to the same 224.0.0.10 / FF02::A group used by Hello packets.
EIGRP Acknowledgment Packets
EIGRP Acknowledgment (Ack) packets confirm receipt of Update, Query, or Reply packets — the three reliably delivered packet types. An Ack is essentially a Hello packet with no data payload; it exists purely to tell the sender “I received your reliable packet.” Ack packets are always sent as unreliable unicast, since acknowledging an acknowledgment would create an endless loop. Hello packets themselves never need to be acknowledged, since they’re already sent unreliably.
EIGRP Query Packets
EIGRP Query packets ask neighboring routers whether they have a usable route to a destination that has just become unreachable. (Note: this “Query” link points to a general dictionary definition rather than networking-specific content — an auto-link mismatch inherited from the original article. Flagging here per audit policy; happy to point it somewhere more relevant on request.)
Queries come into play when DUAL loses its successor (its current best route) to a destination and doesn’t have a feasible successor (a pre-computed backup route) already available. In that situation, the router enters an “active” state for that route and sends Query packets to all of its EIGRP neighbors, asking whether any of them have a viable alternate path. Query packets use reliable delivery and can be sent as either unicast or multicast, depending on the situation. Because delivery is reliable, every router that receives a Query must return an EIGRP Acknowledgment to confirm it got the message — separate from the actual answer, which comes back as a Reply packet.
EIGRP Reply Packets
EIGRP Reply packets answer a Query, reporting back either an alternate route to the requested destination or confirmation that no such route exists. Reply packets are always sent with reliable delivery as unicast messages, directed specifically back to the router that sent the original Query. Once a router has received Replies from all of its queried neighbors, DUAL can select a new successor (or conclude that the destination truly is unreachable) and the route exits its “active” state.
How EIGRP Delivers Packets: RTP
All of this reliable-versus-unreliable delivery is handled by EIGRP’s own transport mechanism, the Reliable Transport Protocol (RTP) — not to be confused with the Real-time Transport Protocol used for voice and video. RTP is responsible for sequencing and, where required, acknowledging EIGRP packets between neighbors.
When a packet needs reliable delivery, RTP tracks it with a sequence number and expects an Acknowledgment in return; if that Acknowledgment doesn’t arrive within the calculated retransmission timeout, RTP retransmits the packet as unicast directly to the non-responding neighbor rather than continuing to multicast it to everyone. This is also why the initial synchronization of a new neighbor relationship — and any retransmissions after a missed Acknowledgment — happen over unicast, even for packet types that are normally multicast.
EIGRP Packet Types at a Glance
| Packet Type | Delivery | Unicast / Multicast | Purpose |
|---|---|---|---|
| Hello | Unreliable | Multicast | Discover neighbors and maintain existing adjacencies |
| Update | Reliable | Unicast (new neighbor) or Multicast (network change) | Advertise new, changed, or removed routes |
| Acknowledgment | Unreliable | Unicast | Confirm receipt of an Update, Query, or Reply |
| Query | Reliable | Unicast or Multicast | Ask neighbors for an alternate route when a successor is lost |
| Reply | Reliable | Unicast | Answer a Query with an alternate route or “no route available” |
FAQs
What triggers EIGRP to send an Update packet?
EIGRP sends an Update packet whenever there’s an actual change to advertise — a new network appearing, an existing network going down, or a metric change for a route that’s already known. Because EIGRP doesn’t use periodic full updates like RIP, this event-driven behavior is central to keeping bandwidth usage low, especially on large or WAN-connected networks. The partial and bounded nature of these updates means only the affected routers receive them, rather than the entire topology.
Why does EIGRP use both unicast and multicast for the same packet types?
EIGRP generally prefers multicast because it’s more efficient when many neighbors need the same information at once, such as during a network-wide route change. Unicast is used in more targeted situations — for example, when synchronizing routing information with a newly discovered neighbor, or when retransmitting a reliable packet to a specific neighbor that failed to acknowledge it the first time. This mix lets EIGRP balance efficiency with reliability depending on the situation.
What happens if an EIGRP neighbor stops sending Hello packets?
If a router stops receiving Hello packets from a neighbor before the hold timer expires, EIGRP assumes that neighbor is still reachable and takes no action. Once the hold timer does expire — by default three times the Hello interval — EIGRP declares the neighbor unreachable and removes any routes learned from it. DUAL then searches for a replacement route, which may involve sending Query packets to the router’s remaining neighbors if no backup route was already known.
What’s the difference between a successor and a feasible successor in EIGRP?
A successor is a router’s current best route to a destination, based on EIGRP’s composite metric. A feasible successor is a pre-computed backup route that DUAL has already verified is loop-free, meaning it can be used immediately if the successor fails, without needing to send Query packets at all. When no feasible successor exists for a lost route, the router has to go active and query its neighbors, which is a slower process than simply switching to an already-known backup.
Why does EIGRP use reliable delivery for some packets but not others?
EIGRP uses reliable delivery for Update, Query, and Reply packets because losing any of them could leave a router with an inaccurate or incomplete view of the network, which risks routing loops or unreachable destinations. Hello and Acknowledgment packets, by contrast, are sent unreliably because they’re either repeated frequently on a short interval (Hello) or exist solely to confirm another packet’s receipt (Acknowledgment), so an occasional lost packet doesn’t meaningfully affect network state. This selective reliability is part of what makes EIGRP more bandwidth-efficient than protocols that reliably retransmit everything.
