This chapter is from the book
This chapter is from the book
This chapter is from the book
RIP Concepts and Operation
The Routing Information Protocol (RIP) was the first commonly used IGP in the history of TCP/IP. Organizations used RIP inside their networks commonly in the 1980s, and into the 1990s. RIPv2, created in the mid-1990s, improved RIPv2, giving engineers an option for easy migration and co-existence to move from RIPv1 to the better RIPv2.
This second of four major sections of the chapter compares RIPv1 and RIPv2, while discussing a few of the core features that apply to both.
Features of Both RIPv1 and RIPv2
Like all IGPs, both RIPv1 and RIPv2 perform the same core features. That is, when using either RIPv1 or RIPv2, a router advertises information to help other routers learn routes; a router learns routes by listening to messages from other routers; a router chooses the best route to each subnet by looking at the metric of the competing routes; and the routing protocol converges to use new routes when something changes about the network.
RIPv1 and RIPv2 use the same logic to achieve most of those core functions. The similarities include the following:
- Both send regular full periodic routing updates on a 30-second timer, with full meaning that the update messages include all known routes.
- Both use split-horizon rules, as shown in Figure 20-6.
- Both use hop count as the metric.
- Both allow a maximum hop count of 15.
- Both use route poisoning as a loop-prevention mechanism (see Figure 20-7), with hop count 16 used to imply an unusable route with an infinite metric.
){kind=link}
){kind=link}
Although you might be puzzled why the creators of RIPv2 made it so much like RIPv1, the goal was simple: interoperability. A network that used RIPv1 could slowly migrate to RIPv2, enabling RIPv2 on some routers on one weekend, some more on the next, and so on. Done correctly, the network could migrate over time. The fact that both RIPv1 and RIPv2 used the same metric, and same loop-prevention mechanisms, allowed for a smooth migration.
Differences Between RIPv1 and RIPv2
Of course, RIPv2 needed to be better than RIPv1 in some ways, otherwise, what is the point of having a new version of RIP? RIPv2 made many changes to RIPv1: solutions to known problems, improved security, and new features as well. However, while RIPv2 improved RIP beyond RIPv1, it did not compete well with OSPF and EIGRP, particularly due to somewhat slow convergence compared to OSPF and EIGRP. However, for the sake of completeness, the next few pages walk through a few of the differences.
First, RIPv1 had one protocol feature that prevented it from using variable-length subnet masks (VLSMs). To review, VLSM means that inside one classful network (one Class A, B, or C network), that more than one subnet mask is used. For instance, in Figure 20-8, all the subnets are from Class A network 10.0.0.0, but some subnets use a /24 mask, whereas others use a /30 mask.
)
Figure 20-8 An Example of VLSM
RIPv1 could not support a network that uses VLSM because RIPv1 did not send mask information in the RIPv1 update message. Basically, RIPv1 routers had to guess what mask applied to each advertised subnet, and a design with VLSM made routers guess wrong. RIPv2 solved that problem by using an improved update message, which includes the subnet mask with each route, removing any need to guess what mask to use, so RIPv2 correctly supports VLSM.
RIPv2 fixed a couple of other perceived RIPv1 shortcomings as well. RIPv2 added authentication (RIPv1 had none), which can avoid cases in which an attacker introduces incorrect routes into a router’s routing table. RIPv2 changed from using IP broadcasts sent to the 255.255.255.255 broadcast address (as in RIPv1) by instead sending updates to the 224.0.0.9 IPv4 multicast address. Using multicasts means that RIP messages can be more easily ignored by other devices, wasting less CPU on those devices.
Table 20-3 summarizes some of the key features of RIPv1 and RIPv2.
Table 20-3 Key Features of RIPv1 and RIPv2
Feature |
RIPv1 |
RIPv2 |
Hop-count metric |
Yes |
Yes |
Sets 15 as the largest metric for a working route |
Yes |
Yes |
Sends full routing updates |
Yes |
Yes |
Uses split horizon |
Yes |
Yes |
Uses route poisoning, with metric 16 |
Yes |
Yes |
Sends mask in routing update |
No |
Yes |
Supports discontiguous classful networks |
No |
Yes |
Sends updates to 224.0.0.9 multicast address |
No |
Yes |
Supports authentication |
No |
Yes |