10.4 RIP: Routing Information Protocol

10.4 RIP: Routing Information Protocol

This section provides an overview of RIP, because it is the most widely used (and most often maligned) routing protocol. The official specification for RIP is RFC 1058 [Hedrick 1988a], but this RFC was written years after the protocol was widely implemented.

Message Format

RIP messages are carried in UDP datagrams, as shown in Figure 10.2. (We talk more about UDP in Chapter 11.)

Figure 10.2. RIP message encapsulated within a UDP datagram.

Figure 10.3 shows the format of the RIP message, when used with IP addresses.

Figure 10.3. Format of a RIP message.

A command of 1 is a request, and 2 is a reply. There are two other obsolete commands (3 and 4), and two undocumented ones: poll (5) and poll-entry (6). A request asks the other system to send all or part of its routing table. A reply contains all or part of the sender's routing table.

The version is normally 1, although RIP Version 2 (Section 10.5) sets this to 2.

The next 20 bytes specify the address family (which is always 2 for IP addresses), an IP address, and an associated metric. We'll see later in this section that RIP metrics are hop counts.

Up to 25 routes can be advertised in a RIP message using this 20-byte format. The limit of 25 is to keep the total size of the RIP message, 20 — 25 + 4 = 504, less than 512 bytes. With this limit of 25 routes per message, multiple messages are often required to send an entire routing table.

Normal Operation

Let's look at the normal operation of routed, using RIP. The well-known port number for RIP is UDP port 520.

• Initialization. When the daemon starts it determines all the interfaces that are up and sends a request packet out each interface, asking for the other router's complete routing table. On a point-to-point link this request is sent to the other end. The request is broadcast if the network supports it. The destination UDP port is 520 (the routing daemon on the other router).

  This request packet has a command of 1 but the address family is set to 0 and the metric is set to 16. This is a special request that asks for a complete routing table from the other end.

• Request received. If the request is the special case we just mentioned, then the entire routing table is sent to the requestor . Otherwise each entry in the request is processed : if we have a route to the specified address, set the metric to our value, else set the metric to 16. (A metric of 16 is a special value called "infinity" and means we don't have a route to that destination.) The response is returned.

• Response received. The response is validated and may update the routing table. New entries can be added, existing entries can be modified, or existing entries can be deleted.

• Regular routing updates. Every 30 seconds, all or part of the router's entire routing table is sent to every neighbor router. The routing table is either broadcast (e.g., on an Ethernet) or sent to the other end of a point-to-point link.

• Triggered updates. These occur whenever the metric for a route changes. The entire routing table need not be sent ” only those entries that have changed must be transmitted.

Each route has a timeout associated with it. If a system running RIP finds a route that has not been updated for 3 minutes, that route's metric is set to infinity (16) and marked for deletion. This means we have missed six of the 30-second updates from the router that advertised that route. The deletion of the route from the local routing table is delayed for another 60 seconds to ensure the invalidation is propagated.

Metrics

The metrics used by RIP are hop counts. The hop count for all directly connected interfaces is 1. Consider the routers and networks shown in Figure 10.4. The four dashed lines we show are broadcast RIP messages.

Figure 10.4. Example routers and networks.

Router R1 advertises a route to N2 with a hop count of 1 by sending a broadcast on N1. (It makes no sense to advertise a route to N1 in the broadcast sent on N1.) It also advertises a route to N1 with a hop count of 1 by sending a broadcast on N2. Similarly, R2 advertises a route to N2 with a metric of 1, and a route to N3 with a metric of 1.

If an adjacent router advertises a route to another network with a hop count of 1, then our metric for that network is 2, since we have to send a packet to that router to get to the network. In our example, the metric to N1 for R2 is 2, as is the metric to N3 for R1.

As each router sends its routing tables to its neighbors, a route can be determined to each network within the AS. If there are multiple paths within the AS from a router to a network, the router selects the path with the smallest hop count and ignores the other paths.

The hop count is limited to 15, meaning RIP can be used only within an AS where the maximum number of hops between hosts is 15. The special metric of 16 indicates that no route exists to the IP address.

Problems

As simple as this sounds, there are pitfalls. First, RIP has no knowledge of subnet addressing. If the normal 16-bit host ID of a class B address is nonzero, for example, RIP can't tell if the nonzero portion is a subnet ID or if the IP address is a complete host address. Some implementations use the subnet mask of the interface through which the RIP information arrived, which isn't always correct.

Next, RIP takes a long time to stabilize after the failure of a router or a link. The time is usually measured in minutes. During this settling time routing loops can occur. There are many subtle details in the implementation of RIP that must be followed to help prevent routing loops and to speed convergence. RFC 1058 [Hedrick 1988a] contains many details on how RIP should be implemented.

The use of the hop count as the routing metric omits other variables that should be taken into consideration. Also, a maximum of 15 for the metric limits the sizes of networks on which RIP can be used.

Example

We'll use the program ripquery, which is available from the gated distribution, to query some routers for their routing table. ripquery tries to send one of the undocumented requests (named "poll," a command of 5 from Figure 10.3) to the router, asking for its entire routing table. If no response is received in 5 seconds, the standard RIP request is issued ( command of 1). (Earlier we said a request with the family set to 0 and the metric set to 16 asks the other router for its entire routing table.)

Figure 10.5 shows the two routers that we'll query for their routing table from the host sun. If we execute ripquery from sun, fetching the routing information from its next-hop router, netb, we get the following:

Figure 10.5. Two routers netb and gateway that we'll query for their routing tables.

 sun %  ripquery -n netb  504 bytes from netb (140.252.1.183):  first message contains 504 bytes   lots of other lines deleted  140.252.1.0, metric 1  the top Ethernet in Figure 10.5  140.252.13.0, metric 1  the bottom Ethernet in Figure 10.5  244 bytes from netb (140.252.1.183):  second message with remaining 244 bytes   lots of other lines deleted  

As we expect, the metric for our subnet that is announced by netb is 1. Additionally, the top Ethernet that netb is also attached to (140.252.1.0) has a metric of 1. (The “n flag says to print the IP addresses numerically instead of trying to look up the names .) In this example netb has been configured to consider all the hosts on the subnet 140.252.13 as directly connected to it ” that is, netb knows nothing about which hosts are actually on the 140.252.13 subnet. Since there is only one connection point to the 140.252.13 subnet, advertising different metrics for each host makes little practical sense.

Figure 10.6 shows the packet exchange using tcpdump. We specify the SLIP interface with the -i sl0 option.

Figure 10.6. tcpdump output while running ripquery program.

The first request issued is the RIP poll command (line 1). This times out after 5 seconds and a normal RIP request is issued (line 2). The number 24 at the end of lines 1 and 2 is the size of the request packets in bytes: the 4-byte RIP header (with the command and version) followed by a single 20-byte address and metric.

Line 3 is the first reply message. The number 25 at the end indicates that 25 address and metric pairs are in the message, which we calculated earlier to be 504 bytes. This is what ripquery printed above. We specified the -s600 option to tcpdump telling it to read 600 bytes from the network. This allows it to receive the entire UDP datagram (instead of just the first portion of it) and it then prints the contents of the RIP response. We've omitted that output.

Line 4 is the second response message from the router, with the next 12 address and metric pairs. We can calculate the size of this message to be 12 — 20 + 4 = 244, which is what ripquery printed earlier.

If we go one router beyond netb, to gateway, we expect the metric to our subnet (140.252.13.0) to be 2. We can check this by executing:

 sun %  ripquery -n gateway  504 bytes from gateway (140.252.1.4):  lots of other lines deleted  140.252.1.0, metric 1  the top Ethernet in Figure 10.5  140.252.13.0, metric 2  the bottom Ethernet in Figure 10.5  

Here the metric for the top Ethernet in Figure 10.5 (140.252.1.0) stays at 1, since that Ethernet is directly connected to both gateway and netb. Our subnet 140.252.13.0, however, now has the expected metric of 2.

Another Example

We'll now watch all the unsolicited RIP updates on an Ethernet and see just what RIP sends on a regular basis to its neighbors. Figure 10.7 shows the arrangement of many of the noao.edu networks. We have named the routers R n for simplicity, where n is the subnet number, except for the ones we use elsewhere in the text. We show the point-to-point links with dashed lines and the IP address at each end of these links.

Figure 10.7. Many of the noao.edu 140.252 networks.

We'll run the Solaris 2.x program snoop, which is similar to tcpdump, on the host solaris. We can run this program without superuser privileges, but only to capture broadcast packets, multicast packets, or packets sent to the host. Figure 10.8 shows the packets captured during a 60-second period. We have replaced most of the official host-names with our notation R n.

Figure 10.8. RIP broadcasts captured at Solaris over a 60-second period.

The “P flag captures packets in nonpromiscuous mode, “tr prints the relative timestamps, and udp port 520 captures only UDP datagrams with a source or destination port of 520.

The first six packets, from R6, R4, R2, R7, R8, and R3, each advertise just one network. If we looked at the packets we would see that R6 advertises a route to 140.252.6.0 with a hop count of 1, R4 advertises a route to 140.252.4.0 with a hop count of 1, and so on.

The router gateway, however, advertises 15 routes. We can run snoop with the -v flag and see the entire contents of the RIP message. (This flag outputs the entire contents of the entire packet: the Ethernet header, the IP header, the UDP header, and the RIP message. We've deleted everything except the RIP information.) Figure 10.9 shows the output.

Figure 10.9. RIP response from gateway.

Compare these advertised hop counts on the 140.252.1 network with the topology shown in Figure 10.7.

A puzzle in the output in Figure 10.8 is why R10 is advertising four networks when Figure 10.7 shows only three. If we look at the RIP packet with snoop we see the following advertised routes:

 RIP:   Address        Metric     RIP:   140.251.0.0    16 (notreachab)     RIP:   140.252.9.0    1     RIP:   140.252.10.0   1     RIP:   140.252.11.0   1 

The route to the class B network 140.251 is bogus and should not be advertised. (It belongs to another institution, not noao.edu. )

The notation "BROADCAST" output by snoop in Figure 10.8 for the RIP packet sent by R10 means the destination IP address is the limited broadcast address 255.255.255.255 (Section 12.2), instead of the subnet-directed broadcast address (140.252.1.255) that the other routers use.