RIP configuration part 2

CCIE blueprint: 3.4.a Implement and troubleshoot RIPv2

This post is part of a multipost series about RIP. Other posts in this series are:

This post is a continuation of the previous post. This post will cover the following configuration items for RIP:

  • RIPv1 and Ripv2 interoperability
  • Bidirectional Forwarding Detection

RIPv1 and RIPv2 interoperability

By default, when you enable RIP it enables version 1. If you forget to change this to version 2 on one router. What will happen? Let’s find out. I used the following configuration on all routers:

router rip
 version 2
 no auto-summary
 network 150.1.0.0
 network 155.1.0.0

Except for R3, there I omitted the version 2 command.

This results in R3 sending v1 updates to all its neighbors and receiving v2 updates from them:

R3#
RIP: sending v1 update to 255.255.255.255 via GigabitEthernet0/1.37 (155.1.37.3)
RIP: build update entries
        network 150.1.0.0 metric 1
        subnet 155.1.0.0 metric 1
        subnet 155.1.5.0 metric 2
        subnet 155.1.8.0 metric 3
        subnet 155.1.10.0 metric 4
        subnet 155.1.13.0 metric 1
        subnet 155.1.23.0 metric 1
        subnet 155.1.45.0 metric 2
        subnet 155.1.58.0 metric 2
        subnet 155.1.108.0 metric 3
        subnet 155.1.146.0 metric 2
RIP: received v2 update from 155.1.37.7 on GigabitEthernet0/1.37
     150.1.1.1/32 via 0.0.0.0 in 3 hops
     150.1.2.2/32 via 0.0.0.0 in 5 hops
     [...]
     155.1.108.0/24 via 0.0.0.0 in 5 hops
     155.1.146.0/24 via 0.0.0.0 in 2 hops

This results in a filled routing table on R3:

R3#sh ip route rip
Gateway of last resort is not set

      150.1.0.0/32 is subnetted, 10 subnets
R        150.1.1.1 [120/1] via 155.1.13.1, 00:00:17, GigabitEthernet0/1.13
R        150.1.2.2 [120/1] via 155.1.23.2, 00:00:17, GigabitEthernet0/1.23
[...]
R        155.1.67.0/24 [120/1] via 155.1.37.7, 00:00:13, GigabitEthernet0/1.37
R        155.1.79.0/24 [120/1] via 155.1.37.7, 00:00:13, GigabitEthernet0/1.37
R        155.1.108.0/24 [120/2] via 155.1.0.5, 00:00:08, Tunnel0
R        155.1.146.0/24 
           [120/1] via 155.1.13.1, 00:00:17, GigabitEthernet0/1.13

Without configuring anything. R3 is accepting a v2 update. This is because by default the implementation of RIP in Cisco routers has RIPv2 support. It’s not sending out RIPv2 updates by default, but it does understand them and accepts them. However, the opposite isn’t true. The other routers, being statically configured to use RIPv2 will not accept RIPv1 updates. When we look to R7 we can see this:

R7#
RIP: ignored v1 packet from 155.1.37.3 (illegal version)

This means that even though R3 has a filled routing table the other routers will not be aware of any networks attached to R3 or any path trough R3. We can change this behaviour by changing the receive version on the neighboring routers with the interface command

R7(config-subif)#ip rip receive version 1

This will let R7 accept the v1 update on the interface. However, because RIPv1 does not include the subnet in its advertisements a subnet mismatch might occur. Instead of changing the receive version you can also change the send version on an interface. This can be done with the interface command

ip rip send version 2

These commands are available to provide interoperability between new Cisco routers supporting RIPv2 and old devices only supporting RIPv1 (luckily you will not find many of those anymore). So in regards to the question at the beginning of this chapter. No, if you forget to enable version 2 on a router it will not function without issues. Why Cisco has not made RIPv2 the default beats me, probably because RIP isn’t used a lot anyways.

Bidirectional Forwarding Detection

As I explained earlier in the intro post about RIP, RIP is dead slow. It takes RIP three minutes to figure out something is wrong when using default timers. Changing the timers is always a possibility, but will impact the CPU of the routers. Nowadays virtually nobody touches the default timers of routing protocols anymore (I hope). Since the introduction of Bidirectional Forwarding Detection (BFD) modification of the default timers isn’t necessary anymore. The timers of the routing protocol will not be used to detect failures anymore as they used to.

The actual workings of BFD is worth a post in itself, so I will only focus on the configuration here, but suffice to say that BFD enables a routing protocol to detect failures in subsecond time without negatively impacting the CPU. This is because BFD is processed in hardware (unless of course you are running virtual routers like I am).

BFD is not a RIP function, but RIP can make use of BFD. The configuration of BFD requires two steps:

  1. Enable BFD on all interfaces that need to make use of it
  2. Register the upper layer protocol to use BFD

I will configure BFD between R8 and R10. Below is the configuration:

R10(config-subif)#bfd interval 250 min_rx 250 multiplier 3
R10(config)#router rip
R10(config-router)#bfd all-interfaces

That is it. The RIP command does not actually enable BFD on all interfaces. The command specifies that RIP should register with all BFD enabled interfaces. So if an interface is not configured for BFD, RIP will not use BFD on that interface. It actually isn’t even possible to specify any other option than all-interfaces. It might have been possible in older versions of the software, but isn’t in the version I’m using (15.6).

Now with BFD enabled, if I disable the interface on R10, R8 will immediately notice (these interfaces are not directly connected, so the link itself will not go down. Comparable to a router connected to a switch)

R10(config)#int g 0/1.108
R10(config-subif)#sh
R10(config-subif)#
%BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: ECHO FAILURE
%BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:1 neigh proc:RIP, handle:1 act
R10(config-subif)#
%BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:1 neigh proc:CEF, handle:1 act
R10(config-subif)#


R8#
%BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: ECHO FAILURE
BFD-DEBUG Event: V1 FSM ld:1 handle:1 event:ECHO FAILURE state:UP (0)
RIPv2 BFD: Got event RIP_BFD_ADJ_DOWN and admin_down 0 for session 1
BFD-DEBUG Event: notify client(RIP) IP:155.1.108.10, ld:1, handle:1, event:DOWN, cp independent failure (0)
BFD-DEBUG EVENT: bfd_session_destroyed, proc:RIP, handle:1 act
%BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed,  ld:1 neigh proc:RIP, handle:1 act
R8#
RIPv2 BFD: 245474072 Destroy Session for 155.1.108.10 on GigabitEthernet0/1.108
RIPv2 BFD: Delete Neighbor with Session_handle:  1  and from Cache
BFD-DEBUG Event: notify client(CEF) IP:155.1.108.10, ld:1, handle:1, event:DOWN, cp independent failure (0)

BFD is capable of making the detection of failures fast, even in RIP. Unfortunately, RIP is also slow on other fronts, so speeding up detection of failures is just one of the aspects of optimizing a routing protocol for subsecond convergence.