WORKSHOPS

Alternatives To RIP In A Large Internetwork

by Chris Lewis

In the September 1 Workshop, "Should RIP Finally Rest In Peace?," on page 124, we discussed the basic operation of the first distance-vector routing protocol of the Routing Information Protocol (RIP). RIP's failings in a large heterogeneous network environment were outlined. In this article, we'll examine more modern routing protocols that improve the capabilities of RIP and discuss how it can communicate with these protocols.

These newer protocols are Cisco Systems' Interior Gateway Routing Prot ocol (IGRP) and Enhanced IGRP a nd Open Shortest Path First (OSPF). RIP version 2 and Integrated IS-IS will not be covered because these are not widely deployed.

Interior Gateway Routing Protocol Cisco's goals for IGRP include stable, optimal routing for large internetworks with no routing loops; fast response to changes in network topology; automatic adaptation to link load and error rates; and low overhead in terms of bandwidth and router-processor utilization.

The key differences between RIP and IGRP are in the metric, poisoning algorithm and use of default gateway. IGRP's split horizon, triggered updates and hold-downs are implemented in a fashion similar to RIP.

IGRP computes a vector of metrics that is used to characterize paths. This metric value can exceed 16 million, allowing a great deal of flexibility when mathematically describing link characteristics. This composite metric (as defined by Cisco) is calculated as follows: [(K1/B) + (K2*D)]*R. In this equation K1 and K2 a re constants; B is unloaded path band width x (1 - channel occupancy); D is topological delay; and R stands for reliability.

K1 and K2 indicate the weight to be assigned to bandwidth and delay, and they are defined by the type of service requested for a packet. The metric calculation actually is much simpler than this equation would suggest. If two routers are connected via their serial 0 ports, the default bandwidth assumed for the metric calculation is 1.544 Mbps, or T1 speed. For a T1 link, IGRP assigns a composite delay of 21,000 microseconds. By default, K1 equals 10,000,000; K2 equals 100,000; and R equals 1. This gives a metric of 8,576 for every serial port connection on a network, regardless of the actual line capacity in place. This metric value can be viewed using the "show ip route A.B.C.D." command, where A.B.C.D. is the IP address of a d evice on the other side of the serial port link.

Metric values can be customized using the bandwidth interface command for each serial port to factor in actual bandwidth available for each link.



The path with the smallest metric is the best path. If two or more paths have identical metrics, they are entered in the routing table and traffic is split equally among them. Caution must be taken with network design because of this functionality. As long as either the data-link or transport layer protocol can receive out-of-sequence packets, everything is fine. However, if one is using frame relay to transport User Datagram Protocol (UDP) packets in an internetwork with multiple routes between networks, for example, this IGRP feature will cause problems, since neither frame relay nor UDP guarantee correct sequencing of packets. In this instance, using TCP as the transpo rt protocol would resolve the problem.

IGRP Route Poisoning The poisoning algorithm used in IGRP can counter larger routing loops than the split horizon with the poison-reverse system used by RIP. RIP's poisoning algorithm counters only routing loops between adjacent routers. IGRP will poison routes with metric increases by a factor of 10 percent or more after an update. This is based on the logic that routing loops generate continually increasing metrics.

With this type of poisoning rule, certain valid routes will be erroneously deleted from routing tables. However, if routes are valid, they will be reinstated by the next regular update message. The advantage to this type of poisoning is that it safely allows a zero hold-down value, which speeds network convergence time considerably.

Application Development and the Web
Return To The Table Of Contents


Updated September 24, 1996


Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers