Modifying the Default RIP Parameters

2017-11-03 09:05:05

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.

Категории