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 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 (22.214.171.124) 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
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
126.96.36.199 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.
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
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.
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: firstname.lastname@example.org.