EIGRP doesn’t use TCP or UDP to deliver its packets. Instead, it uses its own purpose-built delivery mechanism called Reliable Transport Protocol (RTP) — not to be confused with the unrelated Real-time Transport Protocol used in VoIP and streaming, which shares the same acronym but nothing else. EIGRP’s RTP is what guarantees Update, Query, and Reply packets actually reach their destination in order, while letting Hello and Ack packets travel without that overhead, since they don’t need it. This guide covers how RTP’s reliable and unreliable delivery modes work, its three-way handshake for new adjacencies, and how to troubleshoot the RTP-related symptoms that show up when something goes wrong.
Why EIGRP Built Its Own Transport Instead of Using TCP or UDP
EIGRP was designed to be network-layer independent, meaning it isn’t tied to any single Layer 3 protocol’s transport mechanisms. This is also why EIGRP historically supported protocols entirely outside the TCP/IP suite, such as IPX and AppleTalk, through its Protocol-Dependent Module (PDM) architecture — a router running EIGRP for IPX had no TCP or UDP to lean on in the first place, since those are IP-specific transport protocols entirely absent from the IPX stack. Building its own transport layer meant EIGRP could work consistently across whatever network-layer protocol a given PDM was serving, without depending on transport mechanisms that only existed for some of them.
A note on legacy protocol support: IPX and AppleTalk support has been gone from Cisco IOS for years — Cisco removed both permanently starting around IOS 12.2(13)T and completing with 15.0(1)M. RTP’s protocol-independent design is still relevant today, though, since it’s exactly what let EIGRP add IPv6 support cleanly without needing a separate transport mechanism for the new protocol.
Reliable and Unreliable Delivery, Side by Side
RTP supports two delivery modes, deliberately mirroring the reliable/unreliable split familiar from TCP and UDP, without actually being either:
Reliable delivery requires the receiver to send an acknowledgment back to the sender, confirming the packet arrived. If no acknowledgment comes back within the expected window, RTP retransmits the packet. This mirrors TCP’s behavior, though RTP is a much simpler, EIGRP-specific mechanism rather than a general-purpose transport protocol.
Unreliable delivery requires no acknowledgment at all — the packet is sent, and RTP moves on regardless of whether it arrived. This mirrors UDP’s fire-and-forget behavior.
EIGRP assigns each of its packet types to one of these two modes based on what that packet type actually needs:
- Hello packets are sent unreliably. Since Hello packets repeat on a short interval anyway (every 5 seconds by default on most links), losing an occasional one isn’t a problem — the next one arrives shortly after.
- Update, Query, and Reply packets are sent reliably, since these carry actual routing information that DUAL depends on to make correct decisions. Losing one of these without retransmission could leave a router with a stale or incomplete view of the topology.
- Ack packets — the acknowledgments themselves — are sent unreliably. This is a practical necessity as much as a design choice: an acknowledgment for an acknowledgment would create an infinite chain, so acks themselves are never acknowledged.
For the complete breakdown of all EIGRP packet types, including SIA-Query and SIA-Reply, see EIGRP Packet Types.
Sequence Numbers and How Retransmission Actually Works
Every reliably delivered RTP packet carries a sequence number, which the receiver uses to detect duplicates and confirm packets arrive in the correct order. When a router sends a reliable packet, it keeps a copy and starts a retransmission timer. If the acknowledgment for that specific sequence number doesn’t arrive before the timer expires, the router retransmits the original packet — not a fresh copy, the same sequenced packet — so the receiver can correctly recognize a retransmission rather than mistaking it for new information, and can safely discard a duplicate if the original acknowledgment was simply lost rather than the packet itself.
This sequence-and-acknowledgment mechanism is also what allows a form of piggybacking: a router doesn’t necessarily need to send a dedicated Ack packet in response to every reliable packet it receives. If it has its own Update, Query, or Reply packet to send back to that same neighbor anyway, it can include the acknowledgment number in that outgoing packet instead of sending a separate, empty Ack — reducing unnecessary packet overhead on the link.
Unicast and Multicast Delivery
RTP can send EIGRP packets as either unicast or multicast, depending on the specific packet type and situation. Multicast is the default for Hello packets and initial Update packets, using two reserved addresses:
- 224.0.0.10 — the reserved IPv4 multicast address for EIGRP.
- FF02::A — the reserved IPv6 (link-local scope) multicast address for EIGRP.
Reply packets, by contrast, are always sent unicast directly back to the router that originated the Query being answered — there’s no reason for every EIGRP router on a segment to receive a reply meant for one specific query. Retransmissions of previously multicast packets are also typically sent unicast to the specific neighbor that failed to acknowledge, rather than re-multicasting to every neighbor again, which avoids unnecessarily disturbing neighbors that already received and acknowledged the original packet correctly.
The Three-Way Handshake for New Adjacencies
Before two EIGRP routers begin relying on RTP’s reliable delivery for real routing information, they go through a three-way handshake to confirm both multicast and unicast delivery actually work correctly between them:
- The initiating router sends a reliable Update packet with the Init flag set, signaling the start of a new adjacency.
- The receiving neighbor responds, acknowledging the Init Update and beginning to send its own full routing table as reliable Update packets.
- The initiating router acknowledges receipt, and the adjacency is now fully established with both sides synchronized.
This handshake exists specifically to catch a scenario that would otherwise cause serious problems: if multicast delivery works in only one direction between two routers (a surprisingly common real-world failure mode with certain switch or firewall configurations), the handshake surfaces that mismatch immediately, before either router starts depending on unreliable multicast for information it actually needs delivered, rather than discovering the problem later through mysterious, hard-to-diagnose adjacency instability.
Troubleshooting RTP-Related Issues
A few symptoms and their typical RTP-related causes:
A neighbor adjacency repeatedly resets. This can indicate that reliable packets aren’t being acknowledged in time, often due to an underlying network problem (packet loss, asymmetric routing, or a misconfigured multicast boundary) rather than an EIGRP-specific misconfiguration. Checking show ip eigrp neighbors for a high Retransmission Count or Queue Count value points toward exactly this kind of delivery problem, and is usually the first place worth looking before assuming the EIGRP configuration itself is at fault.
Excessive retransmissions on a specific link. If one neighbor relationship consistently shows more retransmissions than others, the underlying physical or logical link to that neighbor is worth investigating directly — RTP’s retransmission behavior is a symptom of unreliable delivery, not the root cause of it, and treating the symptom without addressing the actual link quality issue rarely resolves the problem for long.
A stuck-in-active (SIA) route. If a Query packet’s Reply never arrives within the expected window, DUAL marks the affected route as Stuck in Active, eventually resetting the adjacency with the unresponsive neighbor. This is a more severe consequence of RTP’s reliable delivery failing over an extended query/reply exchange, and is covered in more depth in EIGRP Packet Types, which discusses SIA-Query and SIA-Reply packets directly, including the mechanism EIGRP added specifically to reduce how often this failure mode occurs in large networks.
How This Compares to OSPF’s Reliability Mechanism
OSPF solves a similar problem — making sure critical routing information actually arrives — with a different mechanism entirely. Rather than a general-purpose reliable/unreliable transport split like RTP, OSPF uses explicit acknowledgment packets and a defined Database Description (DBD) exchange process during adjacency formation, tailored specifically to synchronizing link-state databases. OSPF doesn’t have an equivalent to RTP’s blanket reliable-vs-unreliable packet classification; instead, its reliability mechanisms are built directly into the specific packet types and states of its neighbor state machine (from Down through Init, ExStart, Exchange, Loading, and finally Full).
Both protocols ultimately achieve the same goal — ensuring routing information is delivered correctly rather than silently lost — but EIGRP’s RTP does it as a general-purpose transport layer sitting underneath all its packet types, while OSPF builds reliability into the specific mechanics of its adjacency and database synchronization process itself. Neither approach is objectively better; they simply reflect the different overall designs of a distance-vector protocol built for fast convergence versus a link-state protocol built around maintaining a shared topology database.
Frequently Asked Questions
Is EIGRP’s RTP the same thing as the Real-time Transport Protocol used for VoIP?
No, despite sharing the same acronym, these are completely unrelated protocols. EIGRP’s RTP is a proprietary, EIGRP-specific delivery mechanism for routing packets; the Real-time Transport Protocol (also commonly abbreviated RTP) is an IETF standard used for delivering audio and video streams, entirely unrelated to routing.
Why don’t Hello packets need to be reliably delivered?
Because Hello packets are sent repeatedly on a short, regular interval (5 seconds by default on most interfaces). Losing one occasionally doesn’t meaningfully affect neighbor detection, since another Hello will arrive shortly after — the ongoing stream of Hellos itself provides the reliability that an acknowledgment mechanism would otherwise need to guarantee.
What happens if an EIGRP Update packet’s acknowledgment is lost, not the Update itself?
The sending router doesn’t know the acknowledgment was lost rather than the original packet — from its perspective, no ack arrived either way, so it retransmits the original Update. The receiving router detects the retransmission via the sequence number, recognizes it already processed that packet, and simply re-acknowledges it without reprocessing the routing information a second time.
Does RTP encrypt EIGRP traffic?
No. RTP handles delivery reliability and sequencing, not security. EIGRP authentication (MD5 or HMAC-SHA-256) is a separate mechanism layered independently on top of RTP, verifying that packets came from a trusted neighbor rather than protecting the confidentiality of the data itself.
Can a router avoid sending a separate Ack packet for every reliable packet it receives?
Yes, through piggybacking — if the router already has an outgoing Update, Query, or Reply packet destined for that same neighbor, it can include the acknowledgment number in that packet instead of sending a dedicated, otherwise-empty Ack packet, reducing overall packet overhead.
Why does EIGRP go through a three-way handshake when OSPF has its own separate adjacency process?
Both exist for the same underlying reason: confirming that two routers can actually exchange information reliably before either one commits to depending on the other for real routing decisions. EIGRP’s version specifically verifies that both multicast and unicast delivery work correctly in both directions, which matters because RTP relies on multicast for several packet types — a one-way multicast failure between two routers is exactly the kind of subtle problem the handshake is designed to catch early.
Conclusion
RTP is the delivery mechanism that lets EIGRP guarantee its important routing packets — Update, Query, and Reply — arrive reliably and in order, while letting less critical packets like Hello and Ack travel without that overhead. Its protocol-independent design, mirroring TCP-like reliability and UDP-like simplicity without depending on either, is exactly what let EIGRP originally support IPX and AppleTalk alongside IP, and later let it extend cleanly to IPv6 once those legacy protocols were retired. Understanding RTP’s reliable-vs-unreliable split, its sequence-and-acknowledgment mechanics, and the three-way handshake that verifies it’s all working correctly gives real diagnostic value when an EIGRP adjacency behaves unexpectedly — most delivery-related EIGRP problems trace back to exactly these mechanisms.
