R.I.P. RIP?

Ron McCarty

The routing information protocol (RIP) is a topic of discussion among network administrators, and whether the protocol still has a place in enterprise networking especially in new deployments instigates many debates. Most network administrators seem to love or hate the protocol, based upon their previous experiences with RIP. Due to the high speed LAN connections and superior switching products, many networks are flattened and include more nodes per logical (IP) network than in the past. Thus, it is argued that with fewer routes per host, static routes on routers are acceptable. Most smaller and mid-sized organizations would typically have several routes for local network, and possibly more for remote locations, with the default route taking care of most routes until the IP traffic gets closer to the edge or egress of the network.

Furthermore, Layer 2 redundancy provides many of the features on local area networks that were served with redundant Layer 3 paths in previous generation networks. I tend to agree with these arguments, and have seen this trend and implemented (or helped implement) such a structure to simplify management of networks. Figure 1 depicts such a network.

The weakness with such a solution occurs when it is forced upon an organization that, although relatively small, has a complex network. Remote offices, ExtraNets, multiple Internet gateways, VPN gateways, and instant complex networks created by mergers require a solution that is both manageable, easy to learn, and supported on a wide range of networking equipment.

Many of us are tempted to use the latest tool to create the solution. However, modern but more complex routing protocols, such as Open Shortest Path First (OSPF), may not be the best choice, especially when legacy equipment or limited IT support are issues.

The IETF revisited RIP in 1998 with RFC 2453, "RIP version 2", and stated:

"While it is true that the newer IGP routing protocols are far superior to RIP, RIP does have some advantages. Primarily, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time."

RIP Overview

RIP primarily functions as an interior gateway protocol, and it can perform very well in small to medium networks. RIP version 2 uses the network multicast address (224.0.0.9) to advertise the network architecture to its neighbors; RIP version 1 used the broadcast address. These broadcasts are to UDP port 520, regardless of the RIP version. Most of the discussion here covers RIP 2, which has features, including subnetting and variable length subnet masks, necessary in most modern networks. RIP is a distance vector protocol, which means that it only keeps track of the the networks, the gateways, and the metric, which is typically the number of hops to the destination RIP neighbor. This also means that the protocol is not aware of better paths that may exist based upon larger bandwidth or congestion. However, most implementations support manual configuration of the vector for limited administrative granularity. For example, a router with two interfaces to the same WAN may assign the lower bandwidth connection a metric of two, as opposed to the normal metric of one.

RIP is limited to networks with 15 hops or less from any particular RIP node. This was created by the original RIP and has been maintained in RIP version 2 for compatibility with the older version. One of the added features of version 2 is the support of triggered updates, which means that a router can notify its neighbors of an outage by sending a triggered update with a route containing a metric of infinity (defined as 16). Therefore, network changes can converge much quicker. Since I am talking about time, I'll review RIP's timers.

Timing and Numbers

RIP advertisements are broadcast to the network every 30 seconds, with a minimum of about a 5-second jitter to keep the complete network updates from becoming synchronous with each other and causing undo network processing. (PNNI signaling, a very modern protocol for ATM networks, also includes a similar jitter for hello packets.) These updates include the networks directly connected as RIP networks and any networks learned from other RIP advertisements. Before sending the learned routes, the broadcasting node will add one to all the metrics to make the hop count go up. Thirty seconds may seem like too often for network managers that are responsible for very stable networks; whereas, 30 seconds may seem too long for unstable networks for VPN solutions that use the Internet.

The +/- 30 second RIP advertisement is sent to the multicast address 224.0.0.9 on UDP port 520 as previously mentioned. Although the address is a multicast address, it is sent out on the local network and is not forwarded by routers. The distinct advantage of this "local" multicast over a broadcast is that hosts or nodes not configured for RIP will not examine the packet, whereas a broadcast is looked at by every host on the segment.

Each route entry on each node also has timers associated with it. The 180-second timeout keeps a routing entry active as long as no new entries are received for the route. Should an update be received, the timer is reset to 180 seconds.

As opposed to simply flushing the route, a 120-second garbage collection timer is set for the route, and the route's metric is set to infinity (16). During the next 30-second advertisement stages the route is distributed with the infinity metric. Should the "bad" route become "good" during this interval, the route entry currently being timed for garbage collection is replaced with the good entry, and all timers are reset.

Protocol Messaging

RIP messaging is very simple and is made up of two message types: requests and responses. Since RIP is known for its broadcasting or advertising method of distributing routes, the response packet is usually the most well known because it is used for advertisements. The response packet is also used as an answer to a request message and for triggered update. Request messages are used to request specific entries for specific networks or to request the whole network table.

This simplicity of message types makes the protocol easy to implement and is one of the reasons for support of RIP by most router and OS vendors.

New Generation Features

The original version of RIP came under fire for many reasons, including lack of support for subnetting and variable length subnets. As mentioned, RIP version 2 supports these features. In addition to the changes required to support current IP networking practices, the protocol also lacked features that would encourage quicker convergence and avoid routing loops. RIP version 2 supports two distinct features that provided the quicker convergence and routing loops avoidance.

Triggered updates, alluded to earlier, provide a mechanism of telling RIP neighbors that there has been a change in the network topology, without waiting on the next advertisement interval.

Split Horizon is simply a rule that tells the routing protocol process not to send out learned entries onto the network (on broadcast networks) or to the neighbor (point-to-point networks) to which they were learned. Split Horizon with Poison Reverse is the same thing on steroids; as opposed to not advertising the route, the route is advertised with an infinity metric. Examine the Split Horizon and Split Horizon with Poison Reverse to see them in a network. Split Horizon, although not perfect in avoiding routing loops, is a definite plus for most networks.

Summary

RIP, although aged, is a proven technology and available from all router vendors, as well as most OS vendors. Additionally, there are freely available solutions, such as Zebra (http://www.zebra.org). Next month, I'll look at RIP configuration with Zebra and take a closer look at the protocol in action with tcpdump (http://www.tcpdump.org/).

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: ronald.mccarty@gte.net.