Reliable Transport Protocol
The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP packets. Reliable
delivery means that delivery is guaranteed and that packets will be delivered in order. Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address 22.214.171.124. Each neighbor receiving a reliably multicast
packet will unicast an acknowledgment.
Ordered delivery is ensured by including two sequence numbers in the packet. Each packet includes a
sequence number assigned by the sending router. This sequence number is incremented by one each time the router sends a new packet. In addition, the sending router places in the packet the sequence number of the last packet received from the destination router.
In some cases, RTP may use unreliable delivery. No acknowledgment is required, and no sequence
number will be included for unreliably delivered EIGRP packets.
EIGRP uses multiple packet types, all of which are identified by protocol number 88 in the IP header.
· Hellos are used by the neighbor discovery and recovery process. Hello packets are multicast and
use unreliable delivery.
· Acknowledgments ( ACKs) are Hello packets with no data in them. ACKs are always unicast and
use unreliable delivery.
· Updates convey route information. Unlike RIP and IGRP updates, these packets are transmitted only when necessary, contain only necessary information, and are sent only to routers that require the information. When updates are required by a specific router, they are unicast. When updates are required by multiple routers, such as upon a metric or topology change, they are multicast.
Updates always use reliable delivery.
· Queries and Replies are used by the DUAL finite state machine to manage its diffusing computations. Queries can be multicast or unicast, and replies are always unicast. Both queries and replies use reliable delivery.
· Requestswere a type of packet originally intended for use in route servers. This application was never implemented, and request packets are noted here only because they are mentioned in some older EIGRP documentation.
If any packet is reliably multicast and an ACK is not received from a neighbor, the packet will be retransmitted as a unicast to that unresponding neighbor. If an ACK is not received after 16 of these unicast retransmissions, the neighbor will be declared dead.
The time to wait for an ACK before switching from multicast to unicast is specified by the multicast flow
timer. The time between the subsequent unicasts is specified by the retransmission timeout (RTO). Both
the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time
(SRTT). The SRTT is the average elapsed time, measured in milliseconds, between the transmission of a
packet to the neighbor and the receipt of an acknowledgment. The formulas for calculating the exact
values of the SRTT, the RTO, and the multicast flow timer are proprietary.