VMware ESXi and vSphere Cluster Management
EIGRP Reliable Transport Protocol (RTP)
Learn how EIGRP Reliable Transport Protocol delivers Updates, Queries, Replies, Hellos, and acknowledgments using reliable, unreliable, multicast, and unicast transmission.
EIGRP Reliable Transport Protocol (RTP) is the Cisco transport mechanism that EIGRP uses to exchange control-plane messages between neighboring routers. It provides both reliable and unreliable delivery, depending on the EIGRP packet type and the event being handled.
EIGRP RTP is not Transmission Control Protocol (TCP) and it is not User Datagram Protocol (UDP). EIGRP is carried directly inside IP using IP protocol number 88. RTP tracks received EIGRP information, requests acknowledgments when needed, and can retransmit reliable messages when delivery is not confirmed.
What EIGRP RTP Does
EIGRP RTP has three main goals:
- Deliver EIGRP information quickly between neighbors.
- Provide reliable delivery for packet types that must arrive.
- Track received information and determine whether a reliable packet needs retransmission.
RTP is a function of EIGRP itself. It is not a general-purpose transport service for applications. EIGRP selects the delivery behavior based on the packet and situation.
Reliable and Unreliable EIGRP Delivery
Reliable delivery
With reliable delivery, the receiving router sends an acknowledgment after receiving the packet. The sender uses that acknowledgment to determine whether the information arrived. If an acknowledgment is not received, EIGRP can retransmit the packet or take additional neighbor-management action.
Reliable delivery is important for information such as route updates and queries. Losing this information could leave neighboring routers with incomplete topology knowledge.
Unreliable delivery
With unreliable delivery, the receiver does not acknowledge the packet, and the sender does not retransmit it through RTP. This behavior is appropriate for messages such as Hellos, which are sent periodically. A later Hello can provide another opportunity to confirm that a neighbor is still reachable.
Exam point: EIGRP is not entirely reliable or entirely unreliable. Reliability is selected per packet type and event.
Multicast and Unicast Choices
Multicast is a one-to-many transmission method. EIGRP uses multicast when the same information should reach multiple neighbors on a shared segment. This avoids sending a separate copy to every neighbor.
- EIGRP for IPv4 uses multicast address 224.0.0.10.
- EIGRP for IPv6 uses link-local multicast address FF02::A.
Unicast is a one-to-one transmission method. EIGRP uses it when a message is intended for one specific neighbor. For example, initial route information may be sent as a reliable unicast Update during neighbor initialization, and a Reply is sent back to the router that issued a Query.
Reliable multicast versus unreliable multicast
Multicast describes how many recipients receive a packet; reliable or unreliable describes whether receipt must be acknowledged. Therefore, multicast does not automatically mean unreliable.
- Reliable multicast: a multicast packet is sent to several neighbors, and the sender tracks acknowledgments from those neighbors.
- Unreliable multicast: a multicast packet is sent without requiring acknowledgments or retransmissions.
EIGRP commonly uses unreliable multicast for Hellos and reliable multicast for Updates and Queries.
EIGRP Packet Types
Update
An Update carries routing and topology information. Updates communicate available destinations, route metrics, and changes in the EIGRP topology. Updates are reliably delivered. They may be multicast to multiple neighbors or unicast to one neighbor, such as during neighbor initialization.
Query
A Query requests information about a destination when the current route may no longer be usable. EIGRP sends Queries while searching neighboring routers for an alternate path. Queries sent to neighbors use reliable multicast.
Reply
A Reply answers a Query. It can identify a usable path or indicate that the neighbor knows no path to the destination. Replies are reliably unicast to the router that sent the Query.
Hello
A Hello is used to discover neighbors and maintain neighbor relationships. Hellos use unreliable multicast and do not require acknowledgments. If Hello exchange fails, the routers cannot remain EIGRP neighbors.
Acknowledgment
An acknowledgment, often called an ACK, confirms receipt of a reliably delivered EIGRP packet. ACKs are sent by unicast and are themselves sent unreliably. An ACK is not a route-information message; it only confirms reception.
EIGRP Packet Delivery Summary
The table can be remembered as follows: Updates and Queries are reliably multicast when several neighbors need the message, Replies are reliably unicast to the querying router, Hellos are unreliably multicast, and ACKs are unreliably unicast.
How Acknowledgments and Reception Tracking Work
- A sender transmits a reliable EIGRP packet.
- The intended neighbor receives the packet and sends a unicast ACK.
- The sender records that the neighbor confirmed receipt.
- If the sender does not receive the expected confirmation, RTP can retransmit the reliable packet or identify a neighbor communication problem.
When a reliable multicast packet is sent to several neighbors, the sender must track delivery for the intended recipients. The transmission method is multicast, but reliability still depends on receiving the necessary confirmations.
Relationship Between RTP and EIGRP Convergence
Convergence is the process by which routers reach a consistent view of the network after a change. RTP delivers the messages used during this process, while another EIGRP component calculates the route result.
- Updates distribute normal route information and advertise topology or metric changes.
- Queries search for alternate paths after a successor route is lost or becomes unusable.
- Replies report an available path or state that no path is known.
- DUAL, the Diffusing Update Algorithm, uses the exchanged topology information to calculate loop-free routes and coordinate route recomputation.
RTP should therefore be viewed as the delivery mechanism, not the route-selection algorithm. DUAL decides how EIGRP evaluates paths; RTP helps ensure that the required EIGRP messages reach their neighbors.
Practical Message-Exchange Examples
New EIGRP neighbor discovery
- Routers send Hello packets using unreliable multicast.
- The routers discover one another and establish an EIGRP neighbor relationship if the required settings match.
- Initial route information can be sent in a reliable unicast Update to the new neighbor.
- The receiving router returns a unicast ACK for that reliable Update.
Link metric change
- A link or route metric changes.
- The router sends changed route information in an Update.
- If several neighbors need the information, the Update can be sent using reliable multicast.
- Neighbors confirm receipt with ACKs.
Successor route loss
- A router loses its successor route to a destination.
- It sends reliable Query packets to ask neighbors about alternate paths.
- Neighbors return reliably unicast Reply packets.
- A Reply can provide a route or report that no route is known.
- DUAL uses the collected information to resolve the route state and select a loop-free result.
Viewing EIGRP Behavior on Cisco IOS
Use neighbor commands to verify that EIGRP relationships are established:
show ip eigrp neighbors
show ipv6 eigrp neighbors
Use topology commands to inspect route and topology information related to Updates, Queries, and Replies:
show ip eigrp topology
show ipv6 eigrp topology
In a controlled lab, packet debugging can help reveal EIGRP control-plane activity:
debug eigrp packets
undebug all
A packet capture or protocol analyzer can identify EIGRP traffic by filtering for EIGRP or for IP protocol 88.
Troubleshooting RTP-Related Problems
Neighbors are not forming
- Confirm that Hello packets are sent and received on the interface.
- Verify matching EIGRP autonomous-system or named-mode configuration as applicable.
- Check that the interfaces are not configured as passive.
- Check Layer 2 and Layer 3 reachability.
- Confirm that multicast traffic is not being filtered.
Without successful Hello exchange, routers do not become EIGRP neighbors. They therefore cannot exchange reliable Updates, Queries, or Replies.
Route changes do not appear at a neighbor
- Check neighbor status and EIGRP topology output.
- Inspect a packet capture or controlled debug output for Updates and ACKs.
- Look for lost reliable packets or missing acknowledgments.
- Verify interface reachability and multicast handling when multicast delivery is expected.
Reliable Update delivery depends on the sender receiving confirmation from the intended neighbor.
A route remains active or convergence is slow
- Inspect the EIGRP topology table for active routes.
- Determine whether Queries were sent and whether Replies were received from all required neighbors.
- Check for unreachable or unresponsive neighbors that could delay Query resolution.
Queries and Replies support route recomputation after a path failure. RTP provides their reliable delivery, while DUAL uses the results to resolve the route state.
EIGRP RTP Compared With Real-time Transport Protocol
Key Exam Notes
- EIGRP uses its own Reliable Transport Protocol rather than TCP or UDP.
- EIGRP is carried directly over IP protocol 88.
- IPv4 EIGRP multicast is 224.0.0.10; IPv6 EIGRP multicast is FF02::A.
- Updates are reliable and may use multicast or unicast.
- Queries use reliable multicast when sent to neighbors.
- Replies are reliably unicast to the router that sent the Query.
- Hellos use unreliable multicast and require no ACK.
- ACKs are unicast and are themselves unreliable.
- RTP delivers EIGRP messages; DUAL uses topology information to calculate loop-free routes.
- EIGRP RTP is not the Real-time Transport Protocol used for voice and video.
For a related reference, see Reliable Transport Protocol (RTP).