Networking

Understanding the RIP protocol

RIP (Routing Information Protocol) is one of the most enduring protocols; every system administrator should be familiar with it. In this Daily Drill Down, Alexander Prohorenko shows you how to use RIP.

RIP (Routing Information Protocol) was born to make system administrators happy. Every administrator who has to supervise a large number of routers with never-ending connectivity changes should know RIP. There are a lot of other routing protocols that are much better and more full-featured than RIP, but RIP was and still is the basic routing protocol. In this Daily Drill Down, I’ll take a look at this useful protocol.

Let's start from the beginning
RIP is one of the most enduring of all routing protocols. It’s a very simple protocol, based on distance-vector (or Bellman-Ford, as it's also known) routing algorithms that predate ARPANet (the Advanced Research Projects Agency Network). To be exact, these algorithms were originally described academically by R. E. Bellman, L. R. Ford, Jr., and D. R. Fulkerston between 1957 and 1962. During the 1960s, these algorithms were widely deployed by various companies and marketed under different names.

The RIP protocol in the form that we use now was developed in the 1970s at Xerox Labs as part of the XNS (Xerox Network Systems) Routing Protocol suite. The most popular variants are RIP version 1, described in RFC1058, and RIP version 2, described in RFC2453.

RIP version 2, or RIPv2 as it is more commonly known, was first proposed as an update to RIP in RFC1388 in January 1993. This RFC was later superseded by RFC1723 in November 1994 by Gary Scott Malkin and Scott Bradner. Neither of these RIPv2 proposals was intended to be a replacement for RIP, but they were both designed as an extension of RIP to provide additional functionality and capability. Some of these capabilities are compatible with RIP (first version) and some are not. To avoid supplying information to RIPv1 routes that could be misinterpreted, RIPv2 can use only noncompatible features when its packets are multicast. On interfaces that aren’t capable of IP multicast, RIPv1-compatible packets that don’t contain potentially confusing information are used. Some of the most notable RIPv2 enhancements are:
  • Next hop
  • Network mask
  • Authentication
  • RIP tag field

RIP at run time
Because RIP is a distance-vector protocol, a router running RIP will send updates to its neighbors, thus allowing the convergence to a known topology. In each update, the distance of any given router will be broadcast to its neighbor. RIP classifies routers as active and passive (silent). Active routers advertise their routes (reachability information) to others. Passive routers listen and update their routes based on advertisements but do not advertise. Typically, routers run RIP in active mode, while hosts use passive mode.

I'd rather not dwell on the internal RIP structure, but I will discuss ways of implementing this protocol on routers and on servers working as routers. If you're interested in the protocol structure, please refer to the appropriate RFCs.

Let's look at a sample corporate network, which I used to supervise as a network administrator and security engineer some time ago. Its scheme is depicted in Figure A.

Figure A
A Cisco router is the connection point between the Internet and a private network.


The server
The next important node of this network is the server (192.168.85.33), which serves as a router, operating on the FreeBSD 3.2-STABLE operating system and which serves the local network alongside the remote corporate network connected by dial-up connection to this router.

The state of the dial-up connection to the corporate network (192.168.140.0) is very important because it will influence the building of the correct route to this network. In the case of a working dial-up connection, traffic addressed to any host from this network would be routed through 192.168.85.33. Otherwise, all traffic would be routed via the default (0.0.0.0) route. We’ll also be interested in the private network’s (192.168.2.0) announcements to enable it to communicate with hosts on this network.

Back to our Cisco router
Our configuration begins by telling the router to start a RIP process. It then tells the router the networks on which it should send and listen for RIP updates. Because RIP is a classed protocol, the configuration can't specify the aggregate 192.168.85.0/28 directly. Instead, you supply a network statement for each of the class B networks. These statements don’t restrict what routes can be carried to and from this router, only which of the router's directly attached networks will be configured for RIP processing.

In this configuration, I’ve added a static default route through the host 172.16.92.16, which is used as the Internet connection. However, I've commented out the string that tells the router to redistribute all static routes using the RIP protocol. In the topology of the network I'm using as an example, all hosts are using Cisco's IP as a static default route.
! process RIP
router rip
version 2
network 192.168.85.0
network 192.168.140.0
network 192.168.2.0
! redistribute static routes with a default metric
! redistribute static
ip route 0.0.0.0 0.0.0.0 172.16.92.16


Applications
After you've configured the Cisco router, you should start the same process on the server (192.168.85.33) that runs FreeBSD. There are a lot of tools for configuring this on the FreeBSD OS. The most popular one is GateD , a routing daemon that handles multiple routing protocols. Since GateD is very popular in the UNIX world, a lot of UNIX distributions already include it in the binary package. But I'll get back to it a bit later; now I'd like to discuss software solutions from a rather new but still potentially profitable and promising source—GNU Zebra .

GNU Zebra is free software (distributed under GNU General Public License) that manages TCP/IP-based routing protocols. Unlike traditional, GateD-based, monolithic architectures and even the so-called new modular architectures that remove the burden of processing routing functions from the CPU and utilize special ASIC chips instead, Zebra software offers true modularity. Zebra is intended to be used as a route server and a route reflector. Currently, Zebra is available on the GNU/Linux platform and almost all branches of FreeBSD, NetBSD, and OpenBSD, and it’s in the development stage for Solaris 7.

A Cisco of a different color
From the user's side, Zebra looks like Cisco with the same interface and with all the basic commands of Cisco routers. It consists of separate daemons for numerous routing protocols. The main daemon starts on the server and accepts connections to the port 2601 (Zebra). After you've connected to it, you'll get an interface very similar to Cisco's.

And that's why, in the case of a server running Zebra, all you need to do is perform the same operations with it as you did with the Cisco router earlier and change the static route not to the Cisco's E1 link but to the router directly. This looks pretty easy.
ip route 0.0.0.0 0.0.0.0 192.168.85.46

This is the sample cut of /etc/gated.conf, which will enable the RIP protocol and will allow it to send its announcements to the ed2 interface (192.168.85.0). You don’t need any announcements to the ed3 interface since you have no host to use this information in the Windows NT network.
rip yes {
 interface "ed2" ripin ripout version 2;
};
import proto rip {
 all;
};
export proto rip restrict;


Now, we should check to see whether everything is okay. To do this, let's look at our routing table on the Cisco router:
kitty#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B – BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 E1 - OSPF external type 1, E2 - OSPF external type 2, E – EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
 U - per-user static route


Gateway of last resort is 172.16.92.16 to network 0.0.0.0
 

R 192.168.2.0/24 [120/1] via 192.168.85.33, 00:00:13, Ethernet0
 192.168.85.0/28 is subnetted, 1 subnets
C 192.168.85.32 is directly connected, Ethernet0
 172.16.0.0/30 is subnetted, 1 subnets
C 172.16.92.16 is directly connected, Serial0
S* 0.0.0.0/0 [1/0] via 172.16.92.16



And on the FreeBSD server, running Zebra:
dixi#show ip route
 

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
 B - BGP, * - FIB route.


K* 0.0.0.0/0 ed2 (1) 195.3.85.46
R 0.0.0.0/0 ed2 (1) 195.3.85.46
C* 127.0.0.0/8 lo0 (6) direct
C* 192.168.2.0/24 ed3 (2) direct
C* 195.3.85.32/28 ed2 (1) direct

The state of the FreeBSD server, running GateD, can be easily checked with the ipquery command, which accompanies the GateD package.
You’ve now finished with the RIP setup in your network!

Security
Unless you implement defense methods to secure your network, it will be vulnerable to a RIP protocol attack, which has as its target a default route change. In our example, you have your traffic going through the hacker's host. That's why I'll spend some time describing how to use the RIP protocol and secure it effectively.

During RIP protocol setup in a network with a complex topology, you have a lot of chances to mistakenly reconfigure one of the routers, which will cause a routing loop and cause you to lose control of your remote routers. To avoid this, you have to propagate static backup routes on your remote routers to be able to access them in either case. The trouble with a static route is that, on most routers, static routes normally overlap any route gathered from a dynamic protocol. And you want the static route to take effect only in an emergency.

The secret to allowing a static route to be overlapped by any route gathered from a dynamic routing protocol in the Cisco IOS lies in assigning an administrative distance to the static route. The administrative distance makes that route less preferable than any route that comes from the dynamic routing protocol. To set this distance, you need to know at least the basic administrative distances that Cisco has assigned. These are the most important ones for us:
  • Connected Interface 0
  • Static Route 1
  • RIP 120
  • Unknown 255

For a complete list, refer to the Cisco documentation, which comes with the router.

To set the route preference for this static route, insert the distance number after the ip route statement. For example:
! set the administrative distance on the static route to be higher then
! RIP, what will make any route which comes from RIP be more preferable
ip route 0.0.0.0 0.0.0.0 192.168.140.1 130


The next potential problem appears when you need to get away without sending routing updates to the specific interfaces. There are a lot of reasons that can be pertinent here, starting from a low-bandwidth link between the two sites and ending with the absence of a device that can process such updates. To accomplish this, you should turn such interfaces to the "passive" state. For example, to exclude your serial interface from sending any route updates there, use the following:
! process RIP
router rip
version 2
network 192.168.85.0
network 192.168.140.0
network 192.168.2.0
! suppress advertisements on serial interface
passive-interface serial 0


Unfortunately, sometimes this isn't enough to solve the problem. Often, when you're suppressing updates on an interface, you also want to avoid getting any updates that another router can send. The solution is rather simple: administrative distances. Let's look at this example:
! process RIP
router rip
version 2
network 192.168.85.0
network 192.168.140.0
network 192.168.2.0
! suppress advertisements on serial interface
passive-interface serial 0
! set the default administrative distance to 255 what will make router
! ignore routing updates as far as 255 is considered unusable by Cisco IOS
distance 255
! set the administrative distance for these sources back to normal
distance 120 192.168.85.0 0.0.0.255
distance 120 192.168.140.0 0.0.0.255
distance 120 192.168.2.0 0.0.0.255


An administrative distance of 255 is considered unusable by Cisco IOS; therefore, by using this rule set, you can easily avoid having the router get any updates from the "passive" interface.

Finally, I'd like to address the problem of restricting the sources of the route advertisements. First, suppose I want to set my router to trust the routers on 192.168.140.0/24 and 192.168.85.0/24 to tell me anything. At the same time, I don’t want the router on 192.168.2.0/24 to be fully trusted, and I want to trust only route updates for the 192.168.2.0/24 network.
! process RIP
router rip
version 2
network 192.168.85.0
network 192.168.140.0
network 192.168.2.0
distance 120 192.168.140.0 0.0.0.255
distance 120 192.168.85.0 0.0.0.255
! set the administrative distance for these sources normal but only got
! routes that pass access list 1
distance 120 192.168.2.0 0.0.0.255 1
!
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 1 deny 0.0.0.0 255.255.255.255


Suggestions and evolution
It goes without saying that I don't pretend to fully cover the subject of the RIP protocol in this Daily Drill Down. I’ve described only some basics of theory and practice of implementing of the RIP protocol. For more full coverage of this subject, I suggest you refer to the book IP Routing Fundamentals (ISBN: 1-57870-071-x), written by Mark A. Sportack and published by Cisco Press in 1999.

The evolution of information and network infrastructure has required a rethinking of the importance of routing in future networks. Nowadays, routing technologies are being used to perform tasks beyond the capabilities of traditional hardware-based routers. As progress never stops, the need for new routing algorithms and technologies will follow step by step as the demand multiplies. However, steps forward cannot be accomplished without a knowledge of the basics. The RIP protocol is one of the main components of this basic knowledge foundation. It's worth pointing out that even now, RIP is still a core routing protocol in a lot of corporate as well as scientific and technical networks.

Alexander Prohorenko is a student of computer sciences. For the last three years, he worked as a leading system administrator and coder for one of the largest ISPs in Ukraine, and he installed and integrated much of the Internet infrastructure for that country. Now he’s engaged in quality systems programming and high performance web coding for Network Lynx, an American company that’s based in Rio Rancho, NM.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
5 comments
RASedden
RASedden

Looks like just what I need. But cannot see Figure A (and tried 3 PC's) which makes it incomprehensible :-(

avudai43
avudai43

ever thing is fine but Figure A is not viewable so the given explnation i cant understand

tarif200
tarif200

yes thank you for you examine this protocol i accommodate what you say

jatin0007
jatin0007

Brilliant!! Thank you. I like the security part the most in your document which i guess not many people aware of.

Editor's Picks