Operation of RIP


The RIP process operates from UDP port 520; all RIP messages are encapsulated in a UDP (User Datagram Protocol) segment with both the Source and Destination Port fields set to that value. RIP defines two message types: Request messages and Response messages. A Request message is used to ask neighboring routers to send an update. A Response message carries the update. The metric used by RIP is hop count, with 1 signifying a directly connected network of the advertising router and 16 signifying an unreachable network.

On startup, RIP broadcasts a packet carrying a Request message out each RIP-enabled interface. The RIP process then enters a loop, listening for RIP Request or Response messages from other routers. Neighbors receiving the Request send a Response containing their route table.

When the requesting router receives the Response messages, it processes the enclosed information. If a particular route entry included in the update is new, it is entered into the route table along with the address of the advertising router, which is read from the source address field of the update packet. If the route is for a network that RIP has already entered in the table, the existing entry will be replaced only if the new route has a lower hop count. If the advertised hop count is higher than the recorded hop count and the update was originated by the recorded next-hop router, the route will be marked as unreachable for a specified holddown period. If at the end of that time the same neighbor is still advertising the higher hop count, the new metric will be accepted.[5]

[5] Holddowns are used by Cisco IOS, but are not part of the stability features specified in RFC 1058.

RIP Timers and Stability Features

After startup, the router gratuitously sends a Response message out every RIP-enabled interface every 30 seconds, on average. The Response message, or update, contains the router's full route table with the exception of entries suppressed by the split horizon rule. The update timer initiating this periodic update includes a random variable to prevent table synchronization.[6] As a result, the time between individual updates from a typical RIP process might be from 25 to 35 seconds. The specific random variable used by Cisco IOS, RIP_JITTER, subtracts up to 15 percent (4.5 seconds) from the update time. Therefore, updates from Cisco routers vary between 25.5 and 30 seconds (Figure 5-1). The destination address of the update is the all-hosts broadcast 255.255.255.255.[7]

[6] Synchronization of route tables is discussed in Chapter 4, "Dynamic Routing Protocols."

[7] Some implementations of RIP might broadcast only on broadcast media and send updates to the directly connected neighbor on point-to-point links. The Cisco RIP will broadcast on any link type unless configured to do otherwise.

Figure 5-1. RIP adds a small random variable to the update timer at each reset to help avoid route table synchronization. The RIP updates from Cisco routers vary from 25.5 to 30 seconds, as shown in the delta times of these updates.


Several other timers are employed by RIP. Recall from Chapter 4 the invalidation timer, which distance vector protocols use to limit the amount of time a route can stay in a route table without being updated. RIP calls this timer the expiration timer, or timeout. The Cisco IOS calls it the invalid timer. The expiration timer is initialized to 180 seconds whenever a new route is established and is reset to the initial value whenever an update is heard for that route. If an update for a route is not heard within that 180 seconds (six update periods), the hop count for the route is changed to 16, marking the route as unreachable.

Another timer, the garbage collection or flush timer, is set to 240 seconds60 seconds longer than the expiration time.[8] The route will be advertised with the unreachable metric until the garbage collection timer expires, at which time the route will be removed from the route table. Example 5-1 shows a route table in which a route has been marked as unreachable but has not yet been flushed.

[8] Cisco routers use a 60-second garbage collection timer, although RFC 1058 prescribes 120 seconds.

Example 5-1. This router has not heard an update for subnet 10.3.0.0 for more than six update periods. The route has been marked unreachable but has not yet been flushed from the route table.
Mayberry#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 Gateway of last resort is not set      10.0.0.0 255.255.0.0 is subnetted, 4 subnets C     10.2.0.0 is directly connected, Serial0 R     10.3.0.0 255.255.0.0 is possibly down,         routing via 10.1.1.1, Ethernet0 C     10.1.0.0 is directly connected, Ethernet0 R     10.4.0.0 [120/1] via 10.2.2.2, 00:00:00, Serial0 Mayberry#

The third timer is the holddown timer, although RFC 1058 does not call for the use of holddowns. The Cisco implementation of RIP does use them. An update with a hop count higher than the metric recorded in the route table will cause the route to go into holddown for 180 seconds (again, six update periods).

These four timers can be manipulated with the command:

timers basic update invalid holddown flush

This command applies to the entire RIP process. If the timing of one router is changed, the timing of all the routers in the RIP domain must be changed. Therefore, these timers should not be changed from their default values without a specific, carefully considered reason.

RIP employs split horizon with poison reverse and triggered updates. A triggered update occurs whenever the metric for a route is changed and, unlike regularly scheduled updates, might include only the entry or entries that changed. Also unlike regular updates, a triggered update does not cause the receiving router to reset its update timer; if it did, a topology change could cause many routers to reset at the same time and thus cause the periodic updates to become synchronized. To avoid a "storm" of triggered updates after a topology change, another timer is employed. When a triggered update is transmitted, this timer is randomly set between one and five seconds; subsequent triggered updates cannot be sent until the timer expires.

Some hosts might employ RIP in a "silent" mode. These so-called silent hosts do not generate RIP updates, but listen for them and update their internal route tables accordingly. As an example, using routed with the -q option enables RIP in silent mode on a UNIX host.

RIP Message Format

The RIP message format is shown in Figure 5-2. Each message contains a command and a version number and can contain entries for up to 25 routes. Each route entry includes an address family identifier, the IP address reachable by the route, and the hop count for the route. If a router must send an update with more than 25 entries, multiple RIP messages must be produced. Note that the initial portion of the message is 4 octets, and each route entry is 20 octets. Therefore, the maximum message size is 4 + (25 x 20) = 504 octets. Including an eight-byte UDP header will make the maximum RIP datagram size (not including the IP header) 512 octets.

Figure 5-2. The RIP message format.


Command will always be set to either one, signifying a Request message, or two, signifying a Response message. There are other commands, but they are all either obsolete or reserved for private use.

Version will be set to one for RIPv1.

Address Family Identifier is set to two for IP. The only exception to this is a request for a router's (or host's) full route table, as discussed in the following section.

IP Address is the address of the destination of the route. This entry might be a major network address, a subnet, or a host route. The section titled "Classful Routing" examines how RIP distinguishes among these three types of entries.

Metric is, as previously mentioned, a hop count between 1 and 16.

An analyzer decode of a RIP message is shown in Figure 5-3.

Figure 5-3. An Ethereal decode of a RIPv1 message shows the values in the message fields of this specific Response message.


Several historical influences contributed to the inelegant format of the RIP message in which far more bit spaces are unused than are used. These influences range from RIP's original development as an XNS protocol, and the developer's intentions for it to adapt to a large set of address families, to the influence of BSD, and its use of socket addresses, to the need for fields to fall on 32-bit word boundaries. Whatever the original motivations, you will see in Chapter 6 that these unused fields have since been put to good use.

Request Message Types

A RIP Request message might request either a full route table or information on specific routes only. In the former case, the Request message will have a single route entry in which the address family identifier is set to zero, the address is all zeros (0.0.0.0), and the metric is 16. A device receiving such a request responds by unicasting its full route table to the requesting address, honoring such rules as split horizon and boundary summarization (discussed in "Classful Routing: Summarization at Boundary Routers," later in this chapter).

Some diagnostic processes might need to know information about a specific route or routes. In this case, a Request message might be sent with entries specifying the addresses in question. A device receiving this request will process the entries one by one, building a Response message from the Request message. If the device has an entry in its route table corresponding to an address in the request, it will enter the metric of its own route entry into the metric field. If not, the metric field will be set to 16. The response will tell exactly what the router "knows," with no consideration given to split horizon or boundary summarization.

As noted previously, hosts might run RIP in silent mode. This approach allows them to keep their route tables up to date by listening to RIP updates from routers without having to send RIP Response messages uselessly on the network. However, diagnostic processes might need to examine the route table of these silent hosts. Therefore, RFC 1058 specifies that if a silent host receives a request from a UDP port other than the standard RIP port of 520, the host must send a response.

Classful Routing

The route table in Example 5-2 contains RIP-derived routes, which are recognized from the key to the left of each entry. Of significance in these entries are the bracketed tuples; as discussed in Chapter 3, "Static Routing," the first number is the administrative distance, and the second number is the metric. It is readily seen that RIP has an administrative distance of 120, and as already stated, the metric for RIP is hop count. Therefore, network 10.8.0.0 is two hops away, via either E0 or S1. If more than one route exists to the same destination with equal hop counts, equal-cost load balancing will be performed. The route table of Example 5-2 contains several multiple, equal-cost routes.

Example 5-2. This route table contains subnets of networks 10.0.0.0 and 172.25.0.0. All networks not directly connected were derived by RIP.
MtPilate#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 Gateway of last resort is not set     10.0.0.0 255.255.0.0 is subnetted, 9 subnets R    10.10.0.0 [120/3] via 10.5.5.1, 00:00:20, Serial1                [120/3] via 10.1.1.1, 00:00:21, Ethernet0 R    10.11.0.0 [120/3] via 10.5.5.1, 00:00:21, Serial1                [120/3] via 10.1.1.1, 00:00:21, Ethernet0 R    10.8.0.0 [120/2] via 10.1.1.1, 00:00:21, Ethernet0               [120/2] via 10.5.5.1, 00:00:21, Serial1 R    10.9.0.0 [120/2] via 10.5.5.1, 00:00:21, Serial1               [120/2] via 10.1.1.1, 00:00:21, Ethernet0 R    10.3.0.0 [120/1] via 10.1.1.1, 00:00:21, Ethernet0               [120/1] via 10.5.5.1, 00:00:21, Serial1 C    10.1.0.0 is directly connected, Ethernet0 R    10.6.0.0 [120/1] via 10.1.1.1, 00:00:21, Ethernet0               [120/1] via 10.5.5.1, 00:00:22, Serial1 R    10.7.0.0 [120/2] via 10.1.1.1, 00:00:22, Ethernet0               [120/2] via 10.5.5.1, 00:00:22, Serial1 C    10.5.0.0 is directly connected, Serial1    172.25.0.0 255.255.255.0 is subnetted, 3 subnets R    172.25.153.0 [120/1] via 172.25.15.2, 00:00:03, Serial0 R    172.25.131.0 [120/1] via 172.25.15.2, 00:00:03, Serial0 C    172.25.15.0 is directly connected, Serial0

When a packet enters a RIP-speaking router and a route table lookup is performed, the various choices in the table are pruned until a single path remains. First, the network portion of the destination address is read and the route table is consulted for a match. It is this first step of reading the major class A, B, or C network number that defines a classful route table lookup. If there is no match for the major network, the packet is dropped and an ICMP Destination Unreachable message is sent to the packet's source. If there is a match for the network portion, the subnets listed for that network are examined. If a match can be found, the packet is routed. If a match cannot be made, the packet is dropped and a Destination Unreachable message is sent.

Classful Routing: Directly Connected Subnets

Classful route lookups can be illustrated with three examples (referring to Example 5-2):

  1. If a packet with a destination address of 192.168.35.3 enters this router, no match for network 192.168.35.0 is found in the route table, and the packet is dropped.

  2. If a packet with a destination address of 172.25.33.89 enters the router, a match is made to class B network 172.25.0.0/24. The subnets listed for this network are then examined; no match can be made for subnet 172.25.33.0, so that packet, too, is dropped.

  3. Finally, a packet destined for 172.25.153.220 enters the router. This time 172.25.0.0/24 is matched, then subnet 172.25.153.0 is matched, and the packet is forwarded to next-hop address 172.25.15.2.

Another look at Figure 5-2 reveals that there is no provision for RIP to advertise a subnet mask along with each route entry. And accordingly, no masks are associated with the individual subnets in the route table. Therefore, if the router whose forwarding database is depicted in Example 5-2 receives a packet with a destination address of 172.25.131.23, there is no positive way to determine where the subnet bits end and the host bits begin, or even if the address is subnetted at all.

The router's only recourse is to assume that the mask configured on one of its interfaces attached to 172.25.0.0 is used consistently throughout the network. It will use its own mask for 172.25.0.0 to derive the subnet of the destination address. As the route tables throughout this chapter illustrate, a router that is directly connected to a network will list the network in a heading along with the subnet mask of the connecting interface and will then list all the known subnets of the network. If the network is not directly connected, there is a listing only for the major-class network and no associated mask.

Because the destination addresses of packets being routed by a classful routing protocol are interpreted according to the subnet masks locally configured on the router's interfaces, all subnet masks within a major, class-level network must be consistent.

Classful Routing: Summarization at Boundary Routers

A question arises from the preceding discussion: How does a RIP process interpret the subnet of a major network if it has no interfaces attached to that network? Without an interface on the class A, B, or C network of the destination, the router has no way of recognizing the correct subnet mask to use and therefore no way of correctly identifying the subnet.

The solution is simple: If a router has no direct attachments to the network, it needs only a single route entry pointing toward a router that is directly attached.

Figure 5-4 shows a router that is attached at the boundary of two major networks, the class A network 10.0.0.0 and the class C network 192.168.115.0. This boundary router does not send details of the subnets of one major network into the other major network. As the illustration shows, it automatically performs summarization, or subnet hiding. It advertises only the address 10.0.0.0 into network 192.168.115.0 and advertises only the address.

Figure 5-4. This router, at the boundary of two major networks, does not advertise the subnets of one network to routers within the other network.


In this way, the route tables for routers within network 192.168.115.0 have only a single entry that directs packets for 10.0.0.0 toward the boundary router. The boundary router has an interface directly on network 10.0.0.0 and, therefore, has a subnet mask with which to derive the subnet for routing a packet within that network's "cloud." Example 5-3 shows what the route table of a router within 192.168.115.0 would look like with a single, subnetless entry for 10.0.0.0.

Example 5-3. This router has a single entry pointing toward network 10.0.0.0. The next-hop address is the boundary router, because the network is recorded as being one hop away.
Raleigh#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 Gateway of last resort is not set R    10.0.0.0 [120/1] via 192.168.115.40, 00:00:10, Ethernet1      192.168.115.0 255.255.255.240 is subnetted, 6 subnets C       192.168.115.32 is directly connected, Ethernet1 R       192.168.115.64 [120/1] via 192.168.115.99, 00:00:13, Ethernet0 C       192.168.115.96 is directly connected, Ethernet0 C       192.168.115.128 is directly connected, Serial0 R       192.168.115.192 [120/1] via 192.168.115.99, 00:00:13, Ethernet0 R       192.168.115.224 [120/1] via 192.168.115.130, 00:00:25, Serial0 Raleigh#

Chapter 3's brief discussion of discontiguous subnetssubnets of a major network address separated by a different major networknotes that they present a problem for classful routing protocols such as RIP and IGRP. The problem occurs when discontiguous subnets are automatically summarized at network boundaries. A case study in the configuration section of this chapter demonstrates the problem and a solution.

Classful Routing: Summary

The defining characteristic of a classful routing protocol is that it does not advertise an address mask along with the advertised destination address. Therefore, a classful routing protocol must first match the major class A, B, or C network portion of a destination address. For every packet passing through the router

  1. If the destination address is a member of a directly connected major network, the subnet mask configured on the interface attached to that network will be used to determine the subnet of the destination address. Therefore, the same subnet mask must be used consistently throughout that major network.

  2. If the destination address is not a member of a directly connected major network, the router will try to match only the major class A, B, or C portion of the destination address.




CCIE Professional Development Routing TCP/IP (Vol. 12005)
Routing TCP/IP, Volume 1 (2nd Edition)
ISBN: 1587052024
EAN: 2147483647
Year: 2005
Pages: 233

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net