Understanding and Troubleshooting RIPng

For the most part, RIPng is very similar to the RIPv2 specification. However, it is also important to remember that there are some notable differences that you should be familiar with in regards to these two routing protocols. These similarities and differences are listed in Table 10-3:

When troubleshooting RIPng, you should keep in mind that RIPng has the same limitations as RIPv2. For example, updates with a hop count of 16 (or greater) are considered unreachable. These routes will not be installed into the routing table.
The primary problems experienced when implementing RIPng are due to misconfigurations as the configuration syntax for RIPv2 and RIPng is significantly different in Cisco IOS software. For example, when configuring RIPv2, you configure the router to advertise a default route in router configuration mode using the default-information originate router configuration command. This allows the RIPv2 router to advertise the default route to all other neighbors. With RIPng, however, this functionality is now performed under the interface. Therefore, the default route is advertised only out that specified interface, which means that multiple instances of this command are required on a router with multiple RIPng-enabled interfaces and multiple neighbors that should all be receiving the default route.
Recapping what is described in the ROUTE guide, Table 10-4 lists some common configuration commands and how they are applied in RIPv2 and RIPng respectively:

As previously stated, commonly experienced problems with RIPng are due to misconfiguration on the devices running RIPng. Commonly encountered issues include the following:

• Incorrect default route advertisement configuration causes connectivity issues
• The router is not receiving routes
• The router advertising routes it should not be advertising
• No routes are installed into RIB

RIPng uses the ipv6 rip [tag] default-information [originate| only] interface configuration command to advertise a default route. By default, when this command is specified, the router will advertise the default route even if one is not present in the routing table. In most cases, when advertising a default route to downstream neighbors, there is typically no need to advertise any other specific routes. However, there are instances when you might want to advertise both the default and some other more specific routes. For example, consider the topology that is illustrated in Figure 10-1:
Fig. 10-1. RIPng Default Routing Issues

Referencing Figure 10-1, routers R1, R2 and R3 are running RIPng. In addition to this, routers R2 and R3 are peered to two ISPs and are running MP-BGP. These routers are receiving multiple routes from the ISP. Therefore, rather than redistribute these into RIPng, administrators have decided instead to configure R2 and R3 to simply send R1 a default route. Based on this solution, the current routing table on R1 shows the following entries:

While this configuration works well for Internet-based traffic, assuming both R2 and R3 have the same Internet routes, it does introduce intermediate connectivity issues from R1 to the Loopback0 subnets configured on routers R2 and R3 as illustrated in the following ping output:

The reason for this issue is that one packet is sent to R2 while another is sent to R3. The packet sent to the router on which the /128 address is configured will be responded to; however, the packet sent to the router on which the /128 address is not configured will time out. This is because the local router is load-balancing across the equal-cost path, i.e. the 0.0.0.0 route that is received from both routers R2 and R3.
As you troubleshoot, you verify the configurations of R2 and R3, you notice that their respective FastEthernet0/0 interfaces have been configured with the ipv6 rip TSHOOT default-information only interface configuration command as is illustrated below on router R2:

While this configuration allows RIPng to advertise the default route, it also suppresses all other specific routes, leading to the intermittent connectivity issue from R1 to the R2 and R3 Loopback0 subnets illustrated above. The recommended solution in this case is to allow the router to advertise the other routes in addition to the default route. The reason this is commonly an issue is because the same behavior is not applicable when using RIPv2. In other words, with RIPv2, generating the default route does not suppress all other routes. This is yet another different in protocol operation in Cisco IOS software which can cause problems. The solution is implemented on routers R2 and R3 as follows:

Following this configuration, the routing table on R1 shows the following entries:

Following this reconfiguration on R2 and R3, the same ping tests performed on R1 earlier that had a 50% success rate are now completely successful as shown below:

The most common cause for the router to not receive any routes is due to misconfiguration. This may be due to route filtering misconfiguration, i.e. incorrectly configured distribute list filters, failing to enable RIPng under the correct interfaces, or even due to the incorrect use of some commands such as the default-information command, as was illustrated in the previous example. When troubleshooting such issues, verify device configurations. If any route filters are being used and have been applied, ensure that they are permitting the correct networks.
In the event that the router is not advertising prefixes that it should be, verify that the interfaces are in an up/up state on the local router. Additionally, because RIPng does not use network statements, verify that the RIPng process has been enabled under the interface(s). You can use the show ipv6 rip command to determine which RIPng process is enabled under which interfaces, amongst other things. Following is a sample output of the information that can be garnered from this command:

As illustrated in the output above, it is possible for multiple RIPng instances to be configured under the same interface. When implementing RIPng, if you specify one process under the interface and then specify another, the interface belongs to both processes or instances. Cisco IOS software does not overwrite the previous process with the new one.
There are several reasons why the router may not install routes into the RIB. Common causes include route filtering and routes received with a metric of ‘unreachable’, i.e. routes received with a hop count of 16 or greater. In addition to basic show commands, you can also troubleshoot RIPng problems using the debug ip rip command. This command provides detailed information on RIPng received and sent updates as shown in the output below:

Referencing the debugging output above, we can determine that the local router is running two RIPng instances or processes: one named TSHOOT and the other named CCNP. Instance TSHOOT receives four prefixes from neighbor FE80::213:19FF:FE86:A20, via FastEthernet0/0.22. These prefixes have a route metric of 1, indicating that they originated on that router. However, the prefixes are installed into the RIB with a route metric of 11. This means that the original metric is being offset using the ipv6 rip TSHOOT metric-offset 11command under the FastEthernet0/0.22 interface.
The local router is also receiving four prefixes from neighbor FE80::201:96FF:FE1B:DB80 via FastEthernet0/0.33. These prefixes have are received with a route metric of 4. This is an indication that the prefixes are not local to the router, i.e. are not directly connected, or they were redistributed into RIPng on the local router and the metric was specified during redistribution. Because the metric is incremented by one (1) when the routes are installed into the RIB, we can conclude that no non-default metric offsetting is configured under the FastEthernet0/0.33 interface on the router.