CCNA online course

Cisco Reliable Transport Protocol (RTP)

Learn how Cisco Reliable Transport Protocol supports reliable EIGRP routing updates using acknowledgments, sequencing, multicast, unicast retransmissions, and IP protocol 88.

Cisco Reliable Transport Protocol (RTP) is a Cisco-developed transport mechanism used by certain Cisco routing protocols, most importantly Enhanced Interior Gateway Routing Protocol (EIGRP). It provides dependable and ordered delivery for EIGRP control-plane messages without creating TCP or UDP sessions between routers.

Cisco RTP should not be confused with Real-time Transport Protocol, which is also abbreviated RTP and is used mainly for audio and video traffic. The two technologies are unrelated.

What Cisco RTP Is—and Is Not

Cisco RTP is a specialized transport mechanism inside a routing protocol implementation. It manages the delivery of routing-control messages between directly connected EIGRP neighbors.

Technology                         Main purpose                         EIGRP relationship
Cisco Reliable Transport Protocol  Reliable routing-control delivery     Used by EIGRP
Real-time Transport Protocol       Multimedia media transport            Unrelated to EIGRP RTP
TCP                                 General reliable byte-stream service  Not used to carry EIGRP
UDP                                 General connectionless datagrams      Not used to carry EIGRP
  • It is not a general replacement for TCP or UDP. Applications do not normally use Cisco RTP as an end-user transport.
  • It is not multimedia RTP. Voice and video RTP commonly operates with UDP, while Cisco RTP supports EIGRP control messages.
  • It does not make user data reliable. Its reliability applies to EIGRP messages exchanged by routers, not to packets being forwarded through the network.

For background on encapsulation and protocol layers, review the OSI Reference Model and computer network fundamentals.

Why Routing Updates Need Dependable Delivery

Routing protocols exchange control-plane information such as reachable networks, metric changes, route queries, and responses. If an important message is lost, neighboring routers may temporarily hold different routing information.

Inconsistent information can cause stale routes, missing routes, unnecessary recalculation, or slower convergence. Convergence is the process by which routers reach a consistent view of the network after a change.

A router may also need to distribute the same information to several neighbors. A useful transport mechanism should therefore:

  • Reach multiple neighbors efficiently, often with one multicast transmission.
  • Know which neighbors received a reliable message.
  • Retransmit only to neighbors that did not acknowledge it.
  • Preserve the order of important route-control messages.
  • Avoid retransmitting message types for which delivery confirmation is unnecessary.

Cisco RTP provides these functions for EIGRP. It helps EIGRP exchange information reliably, but it cannot overcome every routing problem. Incorrect configuration, authentication mismatches, topology failures, overloaded routers, and resource shortages can still prevent convergence.

EIGRP and Cisco RTP

EIGRP is the principal Cisco routing protocol associated with Cisco RTP. EIGRP routers form neighbor adjacencies and then exchange routing information with those directly connected neighbors.

EIGRP uses RTP to manage the delivery of several message types. The EIGRP routing process and its DUAL algorithm—Diffusing Update Algorithm—decide what information must be exchanged. RTP supplies delivery functions such as sequencing, acknowledgment tracking, and retransmission.

EIGRP is identified at the IP layer by protocol number 88. This is an IP protocol field value, not a TCP or UDP port.

Reliable and Unreliable Delivery

Reliable delivery

With reliable delivery, the sender assigns identifying information to the message and expects the recipient to acknowledge it. If the expected acknowledgment does not arrive before the retransmission timeout, or RTO, the sender can resend the message.

Reliable delivery is appropriate when losing a message could leave EIGRP neighbors with incomplete or inconsistent route information. Update, query, and reply messages generally require dependable delivery.

Unreliable delivery

With unreliable delivery, the sender does not require an acknowledgment for each packet and does not retransmit a lost packet through RTP. This reduces overhead for messages that are sent periodically or whose loss can be handled by a later message or a liveness timer.

EIGRP hello packets generally use unreliable delivery. A missing hello is handled through the neighbor hold-time and liveness process rather than by retransmitting that particular hello packet.

EIGRP can select the delivery mode according to the message type and its operational purpose. “Unreliable” does not mean that the entire routing protocol is careless; it means that RTP acknowledgment and retransmission are not required for that particular transmission.

Multicast, Unicast, and Selective Retransmission

Multicast is one-to-many delivery. On an IPv4 segment, EIGRP uses multicast address 224.0.0.10. For IPv6, EIGRP uses the link-local multicast address FF02::A.

Suppose one router has three EIGRP neighbors on a shared network. It can send one reliable update to the EIGRP multicast address. Each neighbor processes the update and returns an acknowledgment individually, normally using unicast.

A multicast acknowledgment would not clearly identify which neighbor received the update. Individual acknowledgments allow the sender to track delivery per neighbor. If two neighbors acknowledge but one does not, RTP can retransmit the update by unicast only to the non-acknowledging neighbor.

             Reliable multicast update
                    224.0.0.10
                         |
          +--------------+--------------+
          |                             |
       Router A                      Router B
       ACK by unicast                ACK by unicast

If Router B does not acknowledge:
       Router A  -------- update by unicast -------->  Router B

Sequence Numbers, Acknowledgments, and RTO

A sequence number identifies a reliably delivered packet and helps the receiver process messages in the proper order. It also helps distinguish a new packet from a delayed or duplicated copy.

An acknowledgment indicates that a reliable packet was received. The sender tracks acknowledgment state for each neighbor. For a multicast transmission, one neighbor may be acknowledged while another remains outstanding.

The sender waits for an acknowledgment using an RTO, or retransmission timeout. If the timer expires without the expected acknowledgment, the sender retransmits according to EIGRP/RTP behavior, often as a targeted unicast.

  1. The sender creates a reliable EIGRP message.
  2. The message receives a sequence value and is sent to one neighbor or to the EIGRP multicast group.
  3. Each recipient checks the message and returns an acknowledgment.
  4. The sender records which neighbors have acknowledged the message.
  5. If an acknowledgment is missing when the RTO expires, the sender retransmits to the affected neighbor.
  6. Repeated failures can contribute to adjacency problems or delayed route processing.
Step  Sender action                         Receiver action                    Result
1     Sends reliable update, sequence 42   Receives update 42                 Message identified
2     Waits for acknowledgments             Sends acknowledgment for 42        Delivery confirmed
3     Tracks neighbors individually         Other neighbor does not respond    One delivery remains pending
4     RTO expires                           No acknowledgment                  Targeted retransmission
5     Retransmits by unicast                Receives and acknowledges           Pending state clears

Sequencing and acknowledgments reduce ambiguity when packets are delayed, duplicated, or lost. They also support ordered processing of route-control information, which is important when one update depends on the state established by another message.

EIGRP Packet Types and Delivery Expectations

EIGRP packet type  Main purpose                              RTP expectation
Hello             Discover and maintain neighbors            Generally unreliable
Acknowledgment    Confirm receipt of a reliable packet       Response; no separate ACK expected
Update            Carry route information                    Reliable
Query             DUAL request for alternate route data      Reliable
Reply             Response to a query                         Reliable

Hello packets

EIGRP hello packets are periodic neighbor-discovery and keepalive messages. They help routers learn about one another and maintain adjacency awareness. A router does not normally acknowledge every hello.

Acknowledgment packets

An acknowledgment is a response to a reliable EIGRP packet. It tells the sender that the relevant reliable information was received. Because acknowledgments are normally sent individually, the sender can maintain a separate delivery state for each neighbor.

Update, query, and reply packets

Update packets carry routing information. Query packets are used by DUAL when a router needs information about an alternate path. A reply responds to a query. These messages generally require dependable delivery because losing one can leave a route calculation incomplete.

If an expected reliable message is not acknowledged, RTP can retransmit it. If the underlying neighbor or path remains unavailable, EIGRP may be unable to finish its route calculation. In query processing, failure to receive an expected reply can contribute to a stuck in active (SIA) condition.

Ordered Delivery and Flow Control

Route-control information must be processed in a meaningful sequence. Processing an old update after a newer state has already been received could produce an incorrect or temporary view of the topology.

Cisco RTP coordinates sequencing, acknowledgment state, retransmission timers, and delivery to individual neighbors without requiring a TCP session. EIGRP maintains the routing relationship, while RTP provides transport behavior specialized for EIGRP messages.

A slow or unresponsive peer can affect retransmission behavior. Packets may remain outstanding, timers may expire, and route calculations may take longer. Persistent problems can lead to adjacency instability, delayed convergence, or active-route problems.

Packet Encapsulation and Protocol Placement

Ethernet or other data link frame
  IP packet
    IP protocol field: 88
      EIGRP message
        EIGRP/RTP-related fields such as packet type,
        sequence information, and acknowledgment information

EIGRP messages are carried directly inside IP. Therefore:

  • There is no TCP header around EIGRP.
  • There is no UDP header around EIGRP.
  • There are no TCP or UDP port numbers to filter.
  • Packet analyzers should filter for IP protocol 88 or the EIGRP protocol name.

EIGRP packets have a link-local scope characteristic. In IPv4, a TTL of 2 is relevant to EIGRP packet handling. EIGRP multicast addresses are also local-link addresses, so EIGRP neighbor discovery is intended for directly connected neighbors rather than arbitrary remote routers.

Practical Reliable Multicast Example

Router A has two EIGRP neighbors, Router B and Router C, on a shared segment. A route changes on Router A.

  1. Router A creates a reliable EIGRP update with a sequence number.
  2. Router A sends the update to 224.0.0.10 for IPv4, or FF02::A for IPv6.
  3. Routers B and C receive the update and return separate unicast acknowledgments.
  4. Router A marks B as acknowledged but sees no acknowledgment from C.
  5. When the RTO expires for C, Router A retransmits the update directly to C using unicast.
  6. After C acknowledges the retransmission, Router A clears the outstanding delivery state.

This behavior combines multicast efficiency with per-neighbor reliability. It avoids sending separate initial copies to every neighbor while still allowing selective recovery.

Operational Verification

Start by confirming that EIGRP neighbors and topology state are healthy. Transport symptoms should be interpreted in the context of adjacency, interface, and route state.

Verify neighbor adjacencies

show ip eigrp neighbors
show ipv6 eigrp neighbors

Check whether the expected neighbors are present, how long the adjacencies have been stable, and whether a neighbor repeatedly disappears and returns.

Inspect topology and routes

show ip eigrp topology
show ip eigrp topology all-links
show ip route eigrp

Topology output can show successor state, alternate paths, and routes that are active. An active route or missing reply may point toward a query, neighbor, or transport problem.

Review protocol settings and interface details

show ip protocols
show ip eigrp interfaces detail

Use these commands to review EIGRP participation, passive interfaces, timers, and interface-level details.

Use diagnostics carefully

debug eigrp packets
debug eigrp neighbors
undebug all

Debugging can generate significant output and affect device performance. Use it in a controlled lab or for a narrowly scoped maintenance task. In production, prefer filtered packet captures and targeted diagnostic output when possible.

Packet Capture Interpretation

Capture traffic on an interface participating in EIGRP and apply one of these filters:

ip.proto == 88
eigrp

Inspect the following fields and behaviors:

  • EIGRP packet type or opcode, such as hello, update, query, reply, or acknowledgment.
  • IPv4 multicast destination 224.0.0.10 or IPv6 multicast destination FF02::A.
  • Unicast source and destination addresses for individual acknowledgments.
  • Sequence values associated with reliable packets.
  • Acknowledgment values and whether they correspond to the sender’s reliable messages.
  • Repeated sequence values or a later unicast copy, which can indicate retransmission.
  • Timing between the original packet and the retransmission.

A capture can show whether a packet left the sender, reached the interface, received an acknowledgment, and was later retransmitted. Always correlate packet evidence with interface counters, neighbor state, and topology output.

Minimal Lab Context

The following configuration provides context for generating EIGRP traffic in a lab. It is not a complete EIGRP design lesson.

router eigrp 100
 network 192.0.2.0 0.0.0.255
 no auto-summary

After configuring matching EIGRP participation on connected routers, observe hello traffic, adjacency formation, and route updates. Named-mode EIGRP and address-family configuration use different syntax and should be studied separately.

Troubleshooting Cisco RTP and EIGRP

Neighbors fail to form or repeatedly reset

  • Check that interfaces are up and Layer 2 connectivity is stable.
  • Confirm that EIGRP autonomous system or address-family settings match.
  • Compare authentication settings.
  • Check whether passive-interface configuration prevents hello exchange.
  • Review hello and hold timers and inspect whether EIGRP multicast reaches the local segment.
show ip eigrp neighbors
show ip eigrp interfaces detail

Reliable retransmissions repeat for one neighbor

Possible causes include packet loss, congestion, interface errors, duplex-related physical problems, an overloaded neighbor, or an ACL/control-plane policy interfering with IP protocol 88.

  • Check interface counters and error statistics.
  • Capture EIGRP traffic and compare sequence numbers with acknowledgments.
  • Review neighbor statistics and diagnostic output.
  • Confirm that filtering devices permit EIGRP protocol 88.

A route remains active or becomes SIA

A query or reply may not have arrived because of a failed path, an unreachable or overloaded neighbor, or an overly broad query scope. Check topology output for active routes, verify neighbor stability, and correlate query and reply packets in a capture.

No TCP or UDP ports appear in the capture

This is expected. EIGRP is directly encapsulated in IP. Filter for ip.proto == 88 or eigrp, not for a TCP or UDP port.

Cisco RTP is confused with multimedia RTP

Identify the context. EIGRP traffic uses IP protocol 88 and contains routing-control messages. Multimedia Real-time Transport Protocol traffic is a separate technology and is commonly carried over UDP.

Limitations and Common Misconceptions

  • RTP reliability is not end-to-end application reliability. It covers EIGRP control-plane message delivery between routing neighbors.
  • RTP does not guarantee convergence. Configuration errors, topology problems, authentication failures, resource exhaustion, and excessive query scope can still prevent stable routing.
  • RTP is not TCP. EIGRP does not rely on TCP sessions, TCP ports, or a general-purpose byte stream.
  • RTP is not UDP. Although some EIGRP messages use an unreliable delivery mode, EIGRP itself is not carried in UDP.
  • RTP is not multimedia RTP. The shared abbreviation does not indicate a shared protocol.
  • Reliable control messages do not make forwarded user traffic reliable. Data-plane delivery depends on the applications and transport protocols used by end systems.

Key Points for CCNA Study

  • Cisco Reliable Transport Protocol is a Cisco transport mechanism associated primarily with EIGRP.
  • EIGRP uses IP protocol number 88, not TCP or UDP ports.
  • Reliable delivery uses acknowledgments, sequence information, RTO timers, and retransmissions.
  • Unreliable delivery does not require acknowledgments or RTP retransmissions.
  • Hello packets generally use unreliable delivery.
  • Update, query, and reply packets generally require reliable delivery.
  • EIGRP can multicast a reliable packet to multiple neighbors.
  • Acknowledgments are returned individually, normally by unicast.
  • A missing acknowledgment can cause a targeted unicast retransmission.
  • EIGRP uses IPv4 multicast address 224.0.0.10 and IPv6 multicast address FF02::A.
  • RTP supports ordered routing-control delivery but does not guarantee successful convergence under every failure condition.