Modifying the Default RIP Parameters

Problem

You want to modify the default parameters such as timers and administrative distance for IPv6 RIP.

Solution

There are several customizations that we can make to the default RIP configuration. You can modify the timers by using the timers command in the RIP configuration mode:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ipv6 unicast-routing
Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#timers 15 60 5 120
Router1(config-rtr)#exit
Router1(config)#end
Router1#

You can change the default administrative distance with the distance command:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ipv6 unicast-routing
Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#distance 100
Router1(config-rtr)#exit
Router1(config)#end
Router1#

And, in NBMA networks in particular, it is often necessary to disable the default split-horizon behavior of RIP:

Router1#configure terminal 
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ipv6 unicast-routing
Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#no split-horizon
Router1(config-rtr)#exit
Router1(config)#end
Router1#

 

Discussion

You can see the current RIP configuration with the show ipv6 rip command. Here is the output of this command before you make any changes to the default configuration:

Router1#show ipv6 rip
RIP process "RIP_PROC", port 521, multicast-group FF02::9, pid 125
 Administrative distance is 120. Maximum paths is 16
 Updates every 30 seconds, expire after 180
 Holddown lasts 0 seconds, garbage collect after 120
 Split horizon is on; poison reverse is off
 Default routes are not generated
 Periodic updates 717, trigger updates 3
 Interfaces:
 FastEthernet0/0
 Loopback0
 Redistribution:
 None
Router1#

First, we will look at the timers. As you can see, by default RIP sends updates every 30 seconds and routes time out after 180 seconds. The hold-down timer is zero by default, and garbage collection is done every 120 seconds. Now we will look at modifying these timers:

Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#timers 15 60 5 120

In this example, we have set the update period to 15 seconds and the timeout interval to 60 seconds. We have also set the holddown timer to 5 seconds, but we will leave the garbage collection period at the default value of 120 seconds:

Router1#show ipv6 rip
RIP process "RIP_PROC", port 521, multicast-group FF02::9, pid 125
 Administrative distance is 120. Maximum paths is 16
 Updates every 15 seconds, expire after 60
 Holddown lasts 5 seconds, garbage collect after 120
 Split horizon is on; poison reverse is off
 Default routes are not generated
 Periodic updates 755, trigger updates 3
 Interfaces:
 FastEthernet0/0
 Loopback0
 Redistribution:
 None
Router1#

It is important to note that with RIP, these timers are global, applying to updates sent on all RIP interfaces. So, while reducing the timers will improve the convergence time after a topology change, it could also cause serious instability problems if all of the routers in a network do not agree on the timers.

The second example in the Solution section of this recipe changed the administrative distance from the default value of 120 to 100:

Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#distance 100

If we look at the routing table now, you can see that the administrative distance is now 100:

Router1#show pv6 route rip
IPv6 Routing Table - 14 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
 U - Per-user Static route
 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
 O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R AAAA:2::/64 [100/2]
 via FE80::2E0:1EFF:FE7F:9E41, Serial0/0
 via FE80::2E0:1EFF:FE7F:9E41, FastEthernet0/0
R AAAA:99::9:0/112 [100/2]
 via FE80::20E:D7FF:FED6:1060, FastEthernet0/0

Router2#

Administrative distance for IPv6 functions exactly the same way as in IPv4. If the router has routing information for the same prefix from two or more sources, it will prefer the one with the lowest administrative distance. In this case, we have set the distance for all RIP routes to 100 so that they will always be used in preference to OSPF routes.

Split horizon means that the router will not send routes back out through the interface through which it learned them. This is normally the right behavior. On an Ethernet segment, for example, with three routers, all of the routers can see one another. So if Router1 advertises a particular prefix, Router2 does not need to re-advertise this same prefix to Router3. In fact, doing so would be potentially dangerous because if Router1 goes down, Router3 will think that Router2 is still a valid next hop for this route.

However, in Nonbroadcast Multiple Access (NBMA) networks, such as Frame Relay and ATM, it is possible to have several downstream routers on an interface, and they can't see one another directly. For example, Router1 may have connectivity to Router2 and Router3, but Router2 cannot directly communicate with Router3. In this case Router1 must readvertise the prefixes that it learns from Router2 through this interface so that Router3 can see them.

In IPv6 RIP, you can only disable split-horizon processing globally:

Router1(config)#ipv6 router rip RIP_PROC
Router1(config-rtr)#no split-horizon

This is somewhat less than optimal, as this router may have several downstream Frame Relay neighbors and several downstream Ethernet neighbors. Ideally you would want to disable split-horizon only for the Frame Relay interface, as is possible with RIP for IPv4.

In general, IPv4 RIP gives much finer control over parameters such as timers, administrative distance and split-horizon. In IPv4 RIP, you can configure different timers on each interface. You can set different distance values for different prefixes learned from different neighbors, and you can configure split-horizon processes differently on each interface. Unfortunately, Cisco has not yet implemented this level of control for IPv6. Presumably the IPv6 feature set will become richer as the protocol becomes more widely implemented.

See Also

RFC 2080; Chapter 6