Routing Information Protocol

From Hill2dot0
(Redirected from RIP)
Jump to: navigation, search

The version of the Routing Information Protocol (RIP) used by IP routers is a distance vector protocol specified in STD 34/RFC 1058. RIP uses hop count as its sole routing metric. Per the specification, a router extracts subnetwork and distance information from its routing table, broadcasting it to all neighboring routers and hosts every 30 seconds. RIP, sometimes called RIP version 1, is now referenced as “historic” by the IETF. RFC 2453 describes RIP version 2, which is gaining support even in low-end router products.

The Routing Information Protocol is a distance vector routing protocol. Perhaps the most widely installed routing protocol, versions of RIP are used in the Xerox Network System (XNS), TCP/IP, and NetWare. RIP’s popularity has a lot to do with its simplicity and its incorporation into Berkeley UNIX in the early 1980s, which made RIP a common routing protocol on the Internet. RIP’s table update plan requires neighboring routers to exchange routing information every 30 seconds (TCP/IP) or 60 seconds (XNS and NetWare), regardless of whether or not the information has changed. RIP is effective in small to mid-size internetworks. As an internetwork grows, however, RIP begins to exhibit limitations.

Advantages of RIP

RIP has a number of advantages. First, it is an exceedingly simple protocol to implement. Simplicity usually means inexpensive to develop and low in computational overhead. Second, RIP has the advantage of being widely implemented and supported. Historically, RIP has been the most popular routing protocol for use in TCP/IP internetworks, largely due to its incorporation in Berkeley Software Distribution (BSD) 4.2 UNIX. Few (if any) router manufacturers have failed to implement RIP in their products.

Limitations of RIP

RIP also suffers from some serious shortcomings. Designed in a simpler time for simpler networks, RIP has begun to show its age as corporate networks have increased in size. Some of the problems are discussed below.

Best Path

The TCP/IP version of RIP bases routing decisions on hop count. Basing routing decisions on hop count does not take into consideration the current load or available bandwidth on a specific link. For example, if two paths exist to a destination, one consisting of a single hop over a 48 kbps leased line, and the other consisting of two hops over T-1/E-1 trunks, RIP automatically sends the packet over the one hop path, even though the slightly longer path has significantly more bandwidth available. The NetWare and XNS versions of RIP include both hop count and delay in their updates, but the vast majority of implementations use hop count as the default metric to be optimized.

RIP’s use of hop count makes it impossible to support type of service (ToS) routing. RIP can only maintain a single routing table, hence a single route, to any given destination.

Path Length

All versions of RIP limit paths to a maximum of 15 hops. That is, the routing tables cannot record paths that include more than 15 routers. If two subnetworks within a RIP routing domain (i.e., a collection of subnetworks and routers using RIP to make routing decisions) have no path of 15 or fewer routers between them, they cannot intercommunicate.


Use of hop count as a routing metric is not always the greatest idea. It does not take load into consideration. Worse still, in internetworks with links of varying bandwidth, hop count ignores the differences. RIP would prefer a two hop path over 9.6 kbps facilities rather than a three hop path over 2.155 Mbps facilities. A network manager can arbitrarily assign high hop counts to low-speed links, but the 15 hop limit places severe restrictions on this approach.

A RIP-based router sends a significant portion of its routing table in each update. As the internetwork grows, routing updates become large, so routing updates can consume a great deal of bandwidth. For example, a routing exchange in the TCP/IP version of RIP requires 20 bytes for each known subnetwork (including destination address and hop count) plus headers. Because this version of RIP limits packet sizes to 512 bytes, a packet can contain information about no more than 25 destination subnetworks. An enterprise network with 250 interconnected subnetworks would require 10 packets exchanged by adjacent routers every 30 seconds. Over a 64 kbps link, these 40,960 bits (512 bytes x 10 packets) would take almost one second to transmit every 30 seconds, effectively reducing the capacity of a 64 kbps line by 2.2%. The loss is even more startling when the fact that many of these exchanges are unnecessary (no change in the routing table) is taken into account. If the WAN link is a frame relay link with five permanent virtual circuits (PVC), the updates must be forwarded on each PVC, increasing the percentage of bandwidth consumed by RIP to 10% (i.e., 204,800 bits).


RIP’s use of event-driven updates ensures that information about new facilities propagates across the network quickly. But facility failure produces a convergence problem, due to the holddown interval. Information about the loss of routes propagates quickly across the network, but the holddown interval then prevents information about alternate routes from being disseminated quickly. This is the cost for avoiding routing loops.

A network has converged when all of the devices are routing based on common information. A router running RIP typically detects local failures right away, but the routers one hop away do not detect the problem until they receive an update; the next closest routers will require yet another exchange, and so forth. This problem is addressed using triggered or event driven updates (i.e., routers generate updates upon detecting a change, rather than waiting for the next update interval). Unfortunately, this introduces the potential for oscillating routing tables and a flood of routing updates. To prevent this, RIP defines a holddown time. Once a router has updated its tables with a new route, it does not issue another update for a defined period of time (typically three times the update interval). The combination of triggered updates and the holddown time is that bad news travels fast (i.e., routers learn quickly that a route is lost), but good news travels slowly (i.e., learning new routes can take a significant amount of time). To put a bound on this time, the diameter of the network is limited to 15 hops.

RIP Message Format

RIP Message Format

The visual depicts the format of a Routing Information Protocol message. RIP messages are carried in User Datagram Protocol (UDP) datagrams which are, in turn, carried in IP datagrams. Below is a brief description of the fields in the RIP message (reserved fields are set to 0).

  • Command: A 1 octet field specifying the purpose of this datagram. Valid command types indicate that the message is a request for a routing table, a response to such a request, or a periodic broadcast.
  • Version: A 1 octet field that identifies the version number of this RIP message. Version 1 and Version 2 are available.
  • Address Family Identifier (AFI): A 2 octet field that identifies the network protocol for which RIP provides the routing information. This field has a value of 2 for Internet Protocol (IP) networks.
  • IP Address: A 4 octet field carrying the IP address of the destination network defined in the route.
  • Metric: A 4 octet field indicating the number of hops to a destination. For a valid route, this value must be between 1 and 15 inclusively, or 16 to indicate an unreachable route.

The portion of the RIP message from the AFI through the Metric field can appear up to 25 times in a single RIP message (i.e., 20 octets per advertised subnetwork).

The packet depicted on the visual is intended to give you an idea of the kind of exchange in which two routers engage using RIP. The key parts of the packet are the IP address of the destination network; the Metric field, which represents the “distance” to that network; and the source IP address of the packet in which the RIP message arrived, which tells the recipient the “direction.” (Note that the source IP address is in the IP header, not shown on the visual.)


<mp3></mp3> | Routing Information Protocol