RIP

CCIE blueprint: 3.4.a Implement and troubleshoot RIPv2

RIP is the easiest routing protocol on the CCIE R&S 5.1 blueprint. It is not a very widely used protocol anymore, but it is interesting to look into.

I will create several posts about RIP in the near future. These are:

• RIP configuration part 1
• RIP configuration part 2
• RIP authentication
• RIP summarization
• Miscelanious RIP commands
• RIPng

This first post will cover RIP basics

Even though RIP is the easiest routing protocol in the blueprint, this is a sizeable post.

RIPv1 and RIPv2

Here is a list of references about RIP which can be used to study for CCIE or other exams covering RIP:

• RIPv1 RFC 1058
• RIPv2 RFC 2453
• Cisco IP Routing: RIP Configuration Guide, Cisco IOS Release 15M&T
• Cisco IOS IP Routing: RIP Command Reference
• Routing TCP/IP Vol I

RIPv1 and RIPv2 are largely the same protocol, but differ on a some properties. The most important one and the reason anybody implementing RIP today would choose for version 2 is that version 2 supports CIDR and VLSM. Furthermore RIPv2 supports authentication and uses multicast.

Both protocols use the hop count as a metric and have an infinite metric of 16. This means that when there are more than 16 routers in a path the destination becomes unreachable.

Transport and updates

Both RIPv1 and RIPv2 use UDP port 520 for the transportation of routing updates. These updates must be sent to all RIP speakers on a segment. RIPv1 uses broadcast messages to do so. RIPv2 uses multicast. The usage of multicast has the benefit of only sending the messages to systems interested in receiving the update messages. This reduces the processing impact on the hosts. The introduction of multicast for RIPv2 might introduce some issues in networks that are not multicast capable. Because of this RIPv2 is able to use both unicast and broadcast updates, however, these need to be configured. The configuration required for this is covered in the RIP configuration section

RIP does not have the concept of neighborships or adjacencies like most other routing protocols. Because of this RIP does not know the state of other routers. There are no keep-alive messages exchanged. The only form of keep-alive are the routing updates themselves. These are sent every 30 seconds. A routing update contains all routes available in the router as can be seen in the image below.

The image also shows the UDP transport on port 520 and the destination IP address of 224.0.0.9 (The multicast address of RIP)

When a router has not received updates from another router in 180 seconds it assumes the originating router is dead. The routes will then be invalidated. If the router installed routes from this originating router in its routing table it will keep the route there, but increase the metric to 16 hops. This signals that the route is unreachable. This information is then shared with other RIP routers, so they know the route is unreachable. For most (if not all) modern networks these timers are too long. Nowhere I’ve been in the 10+ years I’ve been doing this work will accept a network that takes more than 3 minutes to detect a problem and act on it. Because of this the timers of RIP can be modified to lower values. Lowest values on Cisco equipment is 1 second for the update timer. You can also configure the invalid and hold timers to be 1 second, but this would not be advisable as this would cause failures in the data plane due to routes appearing and disappearing the whole time. A better way to optimize the detection of failure is using BFD. The BFD configuration will be covered in the configuration section.

CIDR support

RIPv1 is a classful protocol. This means that in version 1 RIP does not support variable length subnet masks. It assumes the subnet mask to be the same throughout the network. Because of this it has no reason to send the subnet mask in an update. The RIPv1 update does not contain the subnet mask as shown in the image below.

However, in this example we are using subnets, so how does RIP know?

RIP looks at the configured subnet mask for the interface and assumes all masks in the whole network to be the same. So if it’s subnet is a /24 (as in the example below) The whole network will be a /24. In this case that works out. See the route table below.

R10#sh ip route rip | b Gateway
Gateway of last resort is not set

      150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
R        150.1.0.0/16 
      155.1.0.0/16 is variably subnetted, 6 subnets, 2 masks
R        155.1.8.0/24 
           [120/1] via 155.1.108.8, 00:00:13, GigabitEthernet0/1.108
R        155.1.58.0/24 
           [120/1] via 155.1.108.8, 00:00:11, GigabitEthernet0/1.108

But what if the subnet mask on R10 is wrong. Say for example we configure it to be /25 and we configure R8’s 155.1.8.8 address to be 155.1.8.208. What will happen then?

Before we make the configuration change, let’s ping the IP address on R8 to make sure it works currently:

R10#ping 155.1.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

Great, so let’s change the configuration on both R10 and R8:

R10:
R10(config)#int g 0/1.108
R10(config-subif)#ip add 155.1.108.10 255.255.255.128

R8:
R8(config-subif)#int g 0/1.8
R8(config-subif)#ip add 155.1.8.208 255.255.255.0

So now we have configured an incorrect subnet mask on R10. What does the route table say on R10?

R10#sh ip route rip | b Gateway
Gateway of last resort is not set

      150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
R        150.1.0.0/16 
           [120/1] via 155.1.108.8, 00:01:32, GigabitEthernet0/1.108
      155.1.0.0/16 is variably subnetted, 6 subnets, 3 masks
R        155.1.8.0/25 
           [120/1] via 155.1.108.8, 00:00:27, GigabitEthernet0/1.108
R        155.1.58.0/25 
           [120/1] via 155.1.108.8, 00:00:27, GigabitEthernet0/1.108

As we can see the route table now shows the subnets are /25’s. This goes for all routes learned from R8 that are within the 155.1.0.0/16 (class B) network. Can we ping the ip address of R8’s G0/1.8 interface?

R10#ping 155.1.8.208
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.8.208, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R10#show ip route 155.1.8.208
% Subnet not in table

No, we can’t. The reason is that the subnet is not in the routing table. To check how RIPv2 handles this we can change the version to RIPv2.

R10(config)#router rip
R10(config-router)#version 2
R10(config-router)#^Z
R10#sh ip route rip | b Gateway
Gateway of last resort is not set

      150.1.0.0/32 is subnetted, 2 subnets
R        150.1.8.8 [120/1] via 155.1.108.8, 00:00:25, GigabitEthernet0/1.108
      155.1.0.0/16 is variably subnetted, 8 subnets, 3 masks
R        155.1.8.0/24 
           [120/1] via 155.1.108.8, 00:00:25, GigabitEthernet0/1.108
R        155.1.8.0/25 
           [120/1] via 155.1.108.8, 00:00:54, GigabitEthernet0/1.108
R        155.1.58.0/24 
           [120/1] via 155.1.108.8, 00:00:25, GigabitEthernet0/1.108
R        155.1.58.0/25 
           [120/1] via 155.1.108.8, 00:00:54, GigabitEthernet0/1.108
R10#ping 155.1.8.208           
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.8.208, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms

After changing the version to RIPv2 we see that the /24 subnets appear in the routing table. This also enables R10 to ping the G0/1.8 interface of R8. In the output we can also see the old /25 routes timing out. This takes a while for them to disappear, but for RIP routes you can always see them timing out when their age increases beyond 30 seconds (in the case of default timers)