Reliable Transport Protocol (RTP) is responsible for guaranteed and ordered delivery of EIGRP packets with the use of sequence and acknowledge numbers, but without any fancy windowing or congestion control mechanism (because only one packet will be sent at a time). It supports transmission of both multicast and unicast packets.
Sending Hello packets to all neighbors individually is inefficient on a multi-access networks that provide multicast capabilities (eg: Ethernet), therefore Hello packets do not require acknowledgement are sent as unreliable multicasts. All packets that carry routing information – Update, Query, and Reply packets are sent reliably and require explicit acknowledgment.
Note: Hello and ACK packets which are not being transmitted reliably have no sequence number.
RTP ensures ongoing communication is maintained between neighboring routers by maintaining/a retransmission list for each neighbor. The list is used to track all the reliable packets that were sent but not acknowledged within the Retransmission Time Out (RTO). If the RTO timer expires before an ACK packet is received, EIGRP will transmit another copy of the reliable packet until the hold timer expires and terminate the neighbor relationship.
The use of reliable multicast packets is efficient. However, delays are potential to exist on multi-access media with multiple neighbors, as a reliable multicast packet cannot be transmitted until all peers have acknowledged the previous multicast packet. If a router is slow to respond, it would delay the transmission of next packet and affects all other routers. RTP is designed to handle such situation – neighbors that respond slow to multicasts would have the unacknowledged multicast packets retransmitted as unicasts when the RTO timer expires. This allows the reliable multicast operation to proceed without delaying communications with others and ensure low convergence time in the environments with variable-speed links.
The multicast flow timer determines how long to wait for an ACK packet before switching from multicast to unicast; while the RTO determines how long to wait between subsequent unicasts. The EIGRP process for each neighbor calculates both the multicast flow timer and RTO timer based on the Smooth Round-Trip Time (SRTT). The formulas for the SRTT, RTO, and multicast flow timer are Cisco-proprietary.
RTO is a dynamically adjusted over time. It is based on the SRTT, which specifies the average time in milliseconds between the transmission of a packet and the receipt of an acknowledgment. As more unacknowledged updates are sent, the SRTT would get higher and higher, which causes the RTO to increase exponentially. The maximum RTO value is 5000 ms (5 seconds).
In a steady-state network where no routes are flapping, EIGRP waits for the specified hold-time interval to expire before determining that an EIGRP neighbor adjacency is down. By default, EIGRP waits up to 15 seconds for high-speed links and up to 180 seconds for low-speed links. When EIGRP determines that a neighbor is down and the router cannot reestablish the adjacency, the router will remove all reachable networks through that neighbor from the routing table. The router will attempt to find alternative paths to those networks when the convergence occurs.
The 180-second hold time interval for low-speed links seems excessive, but it accommodates the links which are generally connected to less-critical remote sites. Additionally, 15 seconds is considered too long for some networks with high-speed links and serving mission-critical and time-sensitive applications. Always remember that there are situations and reasons in which modifying the default hold time interval is necessary in order to achieve faster convergence.
When a local router sends an update packet to a remote router and the remote router does not acknowledge the packet, the router would retransmit the update every time the RTO expires for up to 16 times, or until the hold timer expires, whichever is longer, and eventually terminate the neighbor relationship; not as claimed by some sources that the neighbor relationship will be terminated after 16 retransmissions rather than wait until the hold timer expires!
EIGRP packets are only being generated at the moment of transmission. The transmit queues contain small and fixed-size structures that indicate which parts of the topology table to include in an EIGRP packet. As a result, the queues do not consume large amounts of memory and only the latest information will be transmitted. Ex: If a route changes state several times, only the last state is transmitted in the packet. This approach reduces bandwidth utilization.
The show ip eigrp traffic EXEC command shows the numbers EIGRP packets sent and received on a router.
Router#sh ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 100
Hellos sent/received: 26/22
Updates sent/received: 3/3
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 2/0
Input queue high water mark 2, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 72
PDM Process ID: 71
Router#
No comments:
Post a Comment