Configuring RIPng

The steps for configuring RIPng are the same as RIPv1 and v2: Create the routing process, enable the routing protocol on interfaces, and perform any desired customization. The commands, however, are very different. In fact, the creation of the routing process and enabling the routing protocol on the first interface is accomplished in one step, using an interface command. The case studies for RIPng will be similar to those of RIPv1 and v2 to illustrate the similarities in the processes and the differences in configuration.

Case Study: Basic RIPng Configuration

After IPv6 unicast routing is enabled on the router, only one command is required to enable RIPng for IPv6 routing. It is an interface command: ipv6 rip process-name enable. This creates the RIPng process called process-name and enables RIPng on the interface at the same time. The command is entered on each interface that will run RIPng.

Figure 6-15 shows that IPv6, RIPng, and some new Ethernet interfaces have been added to a portion of the network in Figure 6-14.

Figure 6-15. IPv6 addresses are configured on Laguna, Taos, and Sandia's interfaces that are to run RIPng.

Example 6-11 shows Taos's configuration.

Example 6-11. Taos's IPv6 and RIPng configuration.

ipv6 unicast-routing interface Ethernet0  ipv6 address 2001:db8:0:6::1/64  ipv6 rip bigMountain enable interface Ethernet1  ipv6 address 2001:db8:0:4::1/64  ipv6 rip bigMountain enable interface Ethernet2  ipv6 address 2001:db8:0:5::1/64  ipv6 rip bigMountain enable

The RIPng process is created and activated on an interface with a single interface command. This is the difference between configuring RIPv1 and v2, and configuring RIPng. Recall that the RIPv1 and v2 configuration requires a global command (router rip) to create the process, and the network <address> statement to specify the interfaces on which to run the RIP process. With RIPng, when the interface command ipv6 rip bigMountain enable is configured on the first interface, the RIPng process called bigMountain is automatically created. In addition, IOS automatically creates an entry in the configuration (ipv6 router rip bigMountain) for the routing process.

The process name specified on Taos is bigMountain. Notice that the process name is specified on each interface. This name is relevant only to the local router, and is used to distinguish between multiple RIPng processes that might be running on the router. Different interfaces can each run a unique RIPng process, without exchanging information between these interfaces, or multiple processes might be running on a single interface. Only a single RIPv1 or RIPv2 process, on the other hand, can run on a router, and an interface either belongs to this process, or it doesn't run RIP.^[13]

^[13] MPLS VPNs allow multiple RIP processes to run on a single provider edge router. A single RIP process is configured for a given VPN. MPLS and VPNs are outside the scope of this book.

Example 6-12 shows Sandia's IPv6 route table. All the addresses in the network are listed because Taos is configured with a single RIPng process on each of its IPv6 interfaces.

Example 6-12. Taos's IPv6 route table.

Sandia#show ipv6 route IPv6 Routing Table - 16 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 C   2001:DB8:0:4::/64 [0/0]      via ::, Ethernet0 L   2001:DB8:0:4::2/128 [0/0]      via ::, Ethernet0 R   2001:DB8:0:5::/64 [120/2]      via FE80::205:5EFF:FE6B:50A1, Ethernet0 R   2001:DB8:0:6::/64 [120/2]      via FE80::205:5EFF:FE6B:50A1, Ethernet0 C   2001:DB8:0:10::/64 [0/0]      via ::, Ethernet1 L   2001:DB8:0:10:2B0:64FF:FE30:1DE0/128 [0/0]      via ::, Ethernet1 C   2001:DB8:0:11::/64 [0/0]      via ::, Ethernet2 L   2001:DB8:0:11:2B0:64FF:FE30:1DE0/128 [0/0]      via ::, Ethernet2 C   2001:DB8:0:12::/64 [0/0]      via ::, Ethernet3 L   2001:DB8:0:12:2B0:64FF:FE30:1DE0/128 [0/0]      via ::, Ethernet3 C   2001:DB8:0:13::/64 [0/0]      via ::, Ethernet4 L   2001:DB8:0:13:2B0:64FF:FE30:1DE0/128 [0/0]      via ::, Ethernet4 R   2001:DB8:0:18::/64 [120/3]      via FE80::205:5EFF:FE6B:50A1, Ethernet0 L   FE80::/10 [0/0]      via ::, Null0 L   FF00::/8 [0/0]      via ::, Null0

Two new Ethernet interfaces have been added to Acoma, as shown in Figure 6-16. New network policy states that IPv6 traffic in the network of Figure 6-16 should be segmented according to the following policy: Hosts on the LANs connected to Sandia access each other, and they also access devices on Ethernet1 connected to Acoma. Hosts connected to the Laguna router access the devices on Ethernet2 of Acoma. Sandia and Laguna hosts do not need to access each other. Acoma Ethernet1 and Ethernet 2 do not access each other.

Figure 6-16. Acoma has been added to the network, with two IPv6-enabled Ethernet user LAN segments.

The configuration in Example 6-13 is loaded into Taos.

Example 6-13. Taos's configuration to support network policy to segment IPv6 network traffic by creating multiple RIPng routing processes.

Interface Ethernet0  ipv6 rip bigMountain enable Interface Ethernet1  no ipv6 rip bigMountain enable  ipv6 rip smallMountain enable interface Ethernet2  ipv6 rip bigMountain enable  ipv6 rip smallMountain enable ipv6 router rip smallMountain  port 527 multicast ff02::9

Interface Ethernet 0, the link to Laguna, still belongs to the bigMountain RIPng process. A new process, smallMountain, is now enabled on Ethernet 1, the link to Sandia, and bigMountain has been disabled on the interface. Both processes are enabled on Ethernet2, connecting to Acoma. No two RIPng routing processes can use the same UDP port number if both processes are going to be active on a single interface. By changing the port number on the smallMountain process, Taos sends updates for smallMountain to UDP port 527, and updates for the bigMountain process to the default RIPng port, UDP 521. Receiving routers use the port number to distinguish which routing process a received update belongs to. A RIPng router running a single routing process, receiving updates from more then one RIPng process running on a router using identical UDP port numbers, will process each update. If there is conflicting information about an address in both updates, such as a differing metric, the receiving route table may be changing with each update. If a receiving router is running multiple RIPng processes and the same UDP port number is used on both, the receiving router will not be able to distinguish which RIPng process should receive the update. Changing the UDP port number on the second and subsequent RIPng process eliminates these problems. All routers and hosts that need to participate in the RIPng process with the modified UDP port number must use the same UDP port number. Because routers and other TCP/IP devices use port numbers identify which UDP process the packets need to be forwarded to, and RIPng updates are multicast to all RIPng routers, the new UDP port number must not be the same as any other process running on any RIPng router. The smallMountain process is configured to use port 527 in this example. The port number must be changed on the routers exchanging RIPng updates with the smallMountain RIPng process. Sandia and Acoma's configuration changes follow in Example 6-14 and Example 6-15, respectively.

Example 6-14. Sandia's RIPng configuration with a modified UDP port number.

ipv6 router rip smallMountain   port 527 multicast-group FF02::9

Example 6-15. Acoma's RIPng configuration with a modified UDP port number.

interface Ethernet0  ipv6 address 2001:DB8:0:5::2/64  ipv6 rip hill enable  ipv6 rip summit enable interface Ethernet1  ipv6 address 2001:DB8:0:20::/64  ipv6 rip hill enable interface Ethernet2  ipv6 address 2001:DB8:0:21::/64  ipv6 rip summit enable ipv6 router rip hill   port 527 multicast-group FF02::9

Notice that the process names on Acoma are not the same as those on Taos. RIPng process names are relevant only to the local router. They are not exchanged in route updates. Acoma's Ethernet0 is connected to Taos's Ethernet2. It is running two routing processes: hill and summit. hill is also running on interface Ethernet1. Ethernet1's IPv6 address is advertised to Taos using the modified UDP port number 527. This is associated with the smallMountain RIPng process on Taos, and therefore, the IPv6 address gets advertised to Sandia, not Laguna.

Example 6-16 displays information about the RIPng routing processes running on Taos. The command show ipv6 rip displays each process individually. Notice that the default maximum number of parallel paths is 16, and the timer values have not been modified from the default.

Example 6-16. show ipv6 rip displays information about each RIPng process running on a router.

Taos#show ipv6 rip RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104      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 1078, trigger updates 5   Interfaces:     Ethernet2     Ethernet0   Redistribution:     None RIP process "smallMountain", port 527, multicast-group FF02::9, pid 117      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 1080, trigger updates 5   Interfaces:     Ethernet1     Ethernet2   Redistribution:     None

The process bigMountain is running on interfaces Ethernet0 and Ethernet2. Interfaces Ethernet1 and Ethernet2 belong to the smallMountain process, using UDP port number 527.

The IPv6 route table shows that Taos has installed routes from both processes into its route table (Example 6-17).

Example 6-17. IPv6 route table displays all known routes from each active RIPng process.

Taos#show ipv6 route IPv6 Routing Table - 15 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 C   2001:DB8:0:4::/64 [0/0]      via ::, Ethernet1 L   2001:DB8:0:4::1/128 [0/0]      via ::, Ethernet1 C   2001:DB8:0:5::/64 [0/0]      via ::, Ethernet2 L   2001:DB8:0:5::1/128 [0/0]      via ::, Ethernet2 C   2001:DB8:0:6::/64 [0/0]      via ::, Ethernet0 L   2001:DB8:0:6::1/128 [0/0]      via ::, Ethernet0 R   2001:DB8:0:10::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:11::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:12::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:13::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:18::/64 [120/2]      via FE80::204:C1FF:FE50:F1C0, Ethernet0 R   2001:DB8:0:20::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 R   2001:DB8:0:21::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 L   FE80::/10 [0/0]      via ::, Null0 L   FF00::/8 [0/0]      via ::, Null0

Taking a look at Laguna and Sandia's route tables in Example 6-18 and Example 6-19, you can see that each router learns about the routes belonging to the appropriate RIPng process. Taos does not forward smallMountain addresses into the bigMountain process, and vice versa.

Example 6-18. IPv6 route table displays Laguna's routes learned from the bigMountain RIPng process on Taos.

Laguna#show ipv6 route rip IPv6 Routing Table - 8 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   2001:DB8:0:5::/64 [120/2]      via FE80::205:5EFF:FE6B:50A0, Ethernet0 R   2001:DB8:0:21::/64 [120/3]      via FE80::205:5EFF:FE6B:50A0, Ethernet0

Example 6-19. IPv6 route table displays Sandia's routes learned from the smallMountain RIPng process on Taos.

Sandia#show ipv6 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   2001:DB8:0:5::/64 [120/2]      via FE80::205:5EFF:FE6B:50A1, Ethernet0 R   2001:DB8:0:20::/64 [120/3]      via FE80::205:5EFF:FE6B:50A1, Ethernet0

Example 6-17 shows that Taos has learned four addresses from Sandia on Ethernet1, which belongs to the smallMountain RIPng process: 2001:db8:0:10::/64, 2001:db8:0:11::/64, 2001:db8:0:12::/64, and 2001:db8:0:13::/64. 2001:db8:0:5::/64, connected to Ethernet2, is advertised into both the smallMountain and the bigMountain processes. Laguna's route table in Example 6-18 shows that no smallMountain routes have been installed.

Debugging RIPng on Taos (Example 6-20) shows the RIPng updates that are sent out and received into each interface for each process.

Example 6-20. debug ipv6 rip displays the RIPng updates on each interface for each active process.

Taos#debug ipv6 rip RIP Routing Protocol debugging is on Taos# RIPng: Sending multicast update on Ethernet2 for bigMountain         src=FE80::205:5EFF:FE6B:50A0         dst=FF02::9 (Ethernet2)         sport=521, dport=521, length=72         command=2, version=1, mbz=0, #rte=3         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=1, prefix=2001:DB8:0:6::/64         tag=0, metric=2, prefix=2001:DB8:0:18::/64 RIPng: Sending multicast update on Ethernet0 for bigMountain         src=FE80::205:5EFF:FE6B:50A0         dst=FF02::9 (Ethernet0)         sport=521, dport=521, length=72         command=2, version=1, mbz=0, #rte=3         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=1, prefix=2001:DB8:0:6::/64         tag=0, metric=2, prefix=2001:DB8:0:21::/64 RIPng: response received from FE80::2B0:64FF:FE30:1DE0 on Ethernet1 for   smallMountain         src=FE80::2B0:64FF:FE30:1DE0 (Ethernet1)         dst=FF02::9         sport=527, dport=527, length=112         command=2, version=1, mbz=0, #rte=5         tag=0, metric=1, prefix=2001:DB8:0:4::/64         tag=0, metric=1, prefix=2001:DB8:0:10::/64         tag=0, metric=1, prefix=2001:DB8:0:11::/64         tag=0, metric=1, prefix=2001:DB8:0:12::/64         tag=0, metric=1, prefix=2001:DB8:0:13::/64 RIPng: response received from FE80::204:C1FF:FE50:E700 on Ethernet2 for   smallMountain         src=FE80::204:C1FF:FE50:E700 (Ethernet2)         dst=FF02::9         sport=527, dport=527, length=52         command=2, version=1, mbz=0, #rte=2         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=1, prefix=2001:DB8:0:20::/64 RIPng: response received from FE80::204:C1FF:FE50:F1C0 on Ethernet0 for bigMountain         src=FE80::204:C1FF:FE50:F1C0 (Ethernet0)         dst=FF02::9         sport=521, dport=521, length=52         command=2, version=1, mbz=0, #rte=2         tag=0, metric=1, prefix=2001:DB8:0:6::/64         tag=0, metric=1, prefix=2001:DB8:0:18::/64 RIPng: response received from FE80::204:C1FF:FE50:E700 on Ethernet2 for bigMountain         src=FE80::204:C1FF:FE50:E700 (Ethernet2)         dst=FF02::9         sport=521, dport=521, length=52         command=2, version=1, mbz=0, #rte=2         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=1, prefix=2001:DB8:0:21::/64 RIPng: Sending multicast update on Ethernet1 for smallMountain         src=FE80::205:5EFF:FE6B:50A1         dst=FF02::9 (Ethernet1)         sport=527, dport=527, length=72         command=2, version=1, mbz=0, #rte=3         tag=0, metric=1, prefix=2001:DB8:0:4::/64         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=2, prefix=2001:DB8:0:20::/64 RIPng: Sending multicast update on Ethernet2 for smallMountain         src=FE80::205:5EFF:FE6B:50A0         dst=FF02::9 (Ethernet2)         sport=527, dport=527, length=132         command=2, version=1, mbz=0, #rte=6         tag=0, metric=1, prefix=2001:DB8:0:4::/64         tag=0, metric=1, prefix=2001:DB8:0:5::/64         tag=0, metric=2, prefix=2001:DB8:0:10::/64         tag=0, metric=2, prefix=2001:DB8:0:11::/64         tag=0, metric=2, prefix=2001:DB8:0:12::/64         tag=0, metric=2, prefix=2001:DB8:0:13::/64

smallMountain updates are sent out Ethernet1, to Sandia, and Ethernet2, to Acoma. bigMountain updates are sent out Ethernet0, to Laguna, and Ethernet2, to Acoma. Two updates are received on Ethernet2 from Acoma. One uses the default UDP port 521. The other uses UDP port 527, the UDP port associated with smallMountain. The update that uses port 527 includes the prefix 2001:DB8:0:20::/64. This is the prefix assigned to Ethernet1 on Acoma, the prefix which Sandia is permitted to access. The update received on Ethernet2 using UDP port 521 includes prefix 2001:DB8:0:21::/64. This prefix is assigned to Ethernet2 on Acoma and is distributed into the bigMountain process on Taos, and sent to Laguna.

Case Study: RIPng Process Customization

Some customization to the routing process is achieved in a way similar to RIPv1 and v2. The global configuration command ipv6 router rip process_name lets you configure global parameters to that RIPng process.

The administrative distance, the maximum number of paths the routing process will use for load sharing, and RIP timers were discussed in Chapter 5. These parameters are used the same way for RIPng as they are for RIPv1 and v2. RIPng's default administrative distance is 120, the same as RIPv1 and v2. The default maximum number of paths over which RIPng will load share is 16. RIPng can load share on up to 64 paths. The timer parameters, although not all the values, are the same as for RIPv1 and v2: update every 30 seconds, expire after 180 seconds, holddown is 0, garbage collection is 120 seconds.

A configuration for Taos that modifies the distance, maximum-paths, and timers is shown in Example 6-21.

Example 6-21. Taos's configuration modifies the administrative distance, the maximum number of paths for load sharing, and the protocol times.

ipv6 router rip bigMountain   timers 10 30 30 60   maximum-paths 8   distance 200

Example 6-22 shows the output of show ipv6 rip and displays the new parameter values.

Example 6-22. The show ipv6 rip command on Taos shows the modified RIPng values.

Taos#show ipv6 rip RIP process "bigMountain", port 521, multicast-group FF02::9, pid 104      Administrative distance is 200. Maximum paths is 8      Updates every 10 seconds, expire after 30      Holddown lasts 30 seconds, garbage collect after 60      Split horizon is on; poison reverse is off      Default routes are not generated      Periodic updates 2513, trigger updates 7   Interfaces:     Ethernet2     Ethernet0   Redistribution:     None RIP process "smallMountain", port 527, multicast-group FF02::9, pid 122      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 2511, trigger updates 0   Interfaces:     Ethernet2     Ethernet1   Redistribution:     None Taos#

Compare the values in the bigMountain process with those in the smallMountain process, which still has the default values. Be careful modifying the timers and the administrative distance. All routers running the same RIPng process must have the same timer values. The administrative distance is only relevant to the local router, but consider carefully the consequence of changing the administrative distance if multiple routing protocols or routing processes are running on the router and addresses are being learned from multiple routing processes. Changing the administrative distance changes the degree of preference for the routing process. An address learned via a process with a lower distance will get inserted into the routing table. If the same address is learned via a higher administrative distance process, the address will get inserted into the routing table only if the first entry fails. The configuration in Example 6-23 changes the values back to the defaults.

Example 6-23. Taos's RIPng parameters are changed back to the default values in this configuration.

ipv6 router rip bigMountain  no timers 10 30 30 60  no maximum-paths 8  no distance 200

Case Study: Metric Manipulation

As with RIPv1 and v2, RIPng metrics are adjusted by adding an offset. RIPng does not, however, increment the metrics of each entry in a list of prefixes. RIPng modifies the hop count that is associated with an interface. This increments the metric of every prefix that is advertised to the router via this interface by the amount of the hop count configured on the interface. By default, RIPng adds a single hop to the metric of prefixes advertised by a neighboring router. Example 6-24 shows the RIPng route table on Taos and a RIPng update received from Sandia. Notice that each of the metrics in the route table has a value of two. Each RIPng route in the table is directly connected to a router that is one hop away, either Sandia or Laguna. Sandia and Laguna advertise their prefixes with a metric of one. Taos adds a hop count of one to each of the received metrics. To change the value that Taos adds to the received metric, use the metric-offset command, as in Example 6-25.

Example 6-24. RIPng route table and debug ipv6 rip showing a received update illustrates the metric offset added to a received metric.

Taos#show ipv6 route rip IPv6 Routing Table - 15 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   2001:db8:0:18::/64[120/2]      via FE80::204:C1FF:FE50:F1C0, Ethernet0 R   2001:db8:0:10::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:db8:0:11::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:db8:0:12::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:db8:0:13::/64 [120/2]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:20::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 R   2001:DB8:0:21::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 Taos#debug ipv6 rip RIP Routing Protocol debugging is on    RIPng: response received from FE80::2B0:64FF:FE30:1DE0 on Ethernet1 for      smallMountain         src=FE80::2B0:64FF:FE30:1DE0 (Ethernet1)         dst=FF02::9         sport=521, dport=521, length=112         command=2, version=1, mbz=0, #rte=4         tag=0, metric=1, prefix=2001:db8:0:10::/64         tag=0, metric=1, prefix=2001:db8:0:11::/64         tag=0, metric=1, prefix=2001:db8:0:12::/64         tag=0, metric=1, prefix=2001:db8:0:13::/64

Example 6-25. The RIPng metric-offset is increased to three on Taos's Ethernet1 interface.

interface Ethernet1  ipv6 rip smallMountain metric-offset 3

Example 6-26 shows the new route table on Taos. Taos has added a hop count of 3 to each of the prefixes the router received on Ethernet1.

Example 6-26. RIPng route table after the metric offset has been modified on the receiving interface shows a higher metric value for each prefix learned via the modified interface.

Taos#show ipv6 route rip IPv6 Routing Table - 15 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   2001:DB8:0:10::/64 [120/4]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:11::/64 [120/4]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:12::/64 [120/4]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:13::/64 [120/4]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:18::/64 [120/2]      via FE80::204:C1FF:FE50:F1C0, Ethernet0 R   2001:DB8:0:20::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 R   2001:DB8:0:21::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2

This command allows you to adjust the hop count associated with a given link. All addresses received by the adjusted interface will have the adjusted metric. By contrast, RIPv1 and v2 allow you to add the offset to a subset (or all) of the addresses received by the interface before they are added to the route table, or the offset can be added to the addresses just before they are advertised out of the interface.

Case Study: Route Summarization

As with RIPv2, RIPng routes can be summarized before they are advertised to neighbors. Sandia advertises routes for 2001:DB8:0:10::/64, 2001:DB8:0:11::/64, 2001:DB8:0:12::/64, and 2001:DB8:0:13::/64. The routes can be summarized into a single entry: 2001:DB8: 0:10::/62. Sandia's configuration is in Example 6-27.

Example 6-27. Sandia is configured to summarize advertised RIPng addresses.

interface Ethernet0  ipv6 address 2001:DB8:0:4::2/64  ipv6 rip bigMountain enable  ipv6 rip bigMountain summary-address 2001:DB8:0:10::/62

The more specific prefixes are automatically suppressed when an encompassing summary address is configured. Example 6-28 shows Taos's new route table.

Example 6-28. Four consecutive prefixes with a length of 64 bits have been summarized into a single entry with a length of 62 bits.

Taos#show ipv6 route rip IPv6 Routing Table - 12 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   2001:DB8:0:10::/62 [120/4]      via FE80::2B0:64FF:FE30:1DE0, Ethernet1 R   2001:DB8:0:18::/64 [120/2]      via FE80::204:C1FF:FE50:F1C0, Ethernet0 R   2001:DB8:0:20::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2 R   2001:DB8:0:21::/64 [120/2]      via FE80::204:C1FF:FE50:E700, Ethernet2