Table of contents
There are times when a route may be learned by a RIPng process, but a route learned from another source with a lower AD (Administrative Distance) is inserted into the routing table.
In this example, routes to the desired destination are learned by RIPng and OSPFv3. We want to use the route learned by RIPng so we set its AD to be lower than OSPFv3’s AD.
Let’s use the same topology.
In this scenario, there's another network administrator that is in the process of replacing RIPng with OSPFv3 (Open Shortest Path First). OSPFv3 has only been partially configured and isn’t ready to be in production yet.
A traceroute reveals that the path from R-1’s Lo16 to R-3’s Lo36 is taking the alternate route of R1>R2>R3.
Discover why this is happening and restore the primary route (R1>R3). Ensure that OSPFv3 isn’t influencing any routing behavior.
Troubleshooting Ticket #2
Let’s begin by verifying with the traceroute command that the traffic is indeed taking the alternate path of R1>R2>R3.
R-1#traceroute 2001:33::36 Tracing the route to 2001:33::36 1 2001:12::2 8 msec 2 msec 3 msec 2 2001:23::3 4 msec 21 msec 4 msec
Knowing that work was done with OSPFv3 is a good clue. Our routing table isn’t very big so the show ipv6 route command is fine:
R-1#show ipv6 route IPv6 Routing Table - default - 8 entries [Some output omitted] O 2001:33::36/128 [110/2] via FE80:12::2, GigabitEthernet0/0
The route to R-3’s Lo36 was learned through OSPFv3, not RIPng. Note that the Administrative Distance (AD) for OSPFv3 is 110. RIPng has an AD of 120. If R-1 is learning of 2001:33::36 from both routing protocols, it will use the route from OSPFv3 because it has the lower AD.
We could have also checked the route with the show ipv6 route [destination address] command:
R-1#sh ipv6 route 2001:33::36 Routing entry for 2001:33::36/128 Known via "ospf 1", distance 110, metric 2, type intra area Backup from "rip RIP_TEST " Route count is 1/1, share count 0 Routing paths: FE80:12::2, GigabitEthernet0/0 Last updated 00:07:00 ago
This is a nice command. It tells us that it has learned the route via ospf 1 with an AD of 110. The backup is rip RIP_TEST with an AD of 120. We also see the next hop link-local address and the local router’s egress interface.
Let's see exactly what routing protocols have been assigned to what interfaces:
R-1#show ipv6 protocols [Some output omitted] IPv6 Routing Protocol is "rip RIP_TEST" Interfaces: GigabitEthernet0/1 GigabitEthernet0/0 IPv6 Routing Protocol is "ospf 1" Router ID 126.96.36.199 Number of areas: 1 normal, 0 stub, 0 nssa Interfaces (Area 0): GigabitEthernet0/0
Let's also verify that RIPng has learned a path to 2001:33::36 to R-3 by checking the RIPng database:
R-1#show ipv6 rip database RIP process "RIP_TEST", local RIB 2001:12::/64, metric 2 GigabitEthernet0/0/FE80:12::2, expires in 171 secs 2001:13::/64, metric 2 GigabitEthernet0/1/FE80:13::3, expires in 178 secs 2001:23::/64, metric 2 GigabitEthernet0/0/FE80:12::2, expires in 171 secs GigabitEthernet0/1/FE80:13::3, expires in 178 secs 2001:33::36/128, metric 2 GigabitEthernet0/1/FE80:13::3, expires in 178 secs
RIPng has inserted what it considers to be the optimal path to R3's Lo36 into the RIPng database on lines 10 and 11.
Once again, OSPFv3 has an AD of 110 which is lower than RIPng’s metric of 120. The route with a lower AD wins entry to the routing table.
This issue could be resolved by:
- Increasing OSPFv3’s default AD value above RIPng’s default AD of 120
- Lowering RIPng’s default value below OSPFv3’s
While both would work, I prefer lowering RIPng’s AD below 110. The reason for this is that in the end we want OSPFv3 to be the only routing protocol in the network and I want OSPFv3 to have its default value. Using other than the default value could cause confusion in the future!
Pro Tip: A good method of replacing a routing protocol is to configure the new protocol with a higher AD than the existing one. When the new routing protocol is ready to be tested, its AD value is set lower than the initial protocol. If there is an issue, the AD can be raised again. If the test is successful, the undesired protocol can then be peeled away. Lastly, reset the new protocol's AD to its default value. This technique would have avoided an issue in this scenario.
We want RIPng to be the primary and alternate route so we need to change its AD on R-1, R-2 and R-3.
R-1(config)#ipv6 router rip RIP_TEST R-1(config-rtr)#distance 105 R-2(config)#ipv6 router rip RIP_TEST R-2(config-rtr)#distance 105 R-3(config)#ipv6 router rip RIP_TEST R-3(config-rtr)#distance 105
Let's verify that RIPng, with its lower AD has replaced OSPFv3:
R-1#sh ipv6 route IPv6 Routing Table - default - 8 entries [Some output omitted] R 2001:33::36/128 [105/2] via FE80:13::3, GigabitEthernet0/1
This is good news. Our route from R-1 to R-3’s Lo36 is no longer learned from OSPFv3 with an AD of 110 and a next hop of R-2. Now the route is learned through RIPng with an AD of 105 and with a next hop of R-3.
Let’s check out the sh ipv6 route [destination address] command:
R-1#sh ipv6 route 2001:33::36 Routing entry for 2001:33::36/128 Known via "rip RIP_TEST", distance 105, metric 2 Backup from "ospf 1 " Route count is 1/1, share count 0 Routing paths: FE80:13::3, GigabitEthernet0/1
Here we have more information about R-1’s knowledge of the route to 2001:33::36 than the other commands, including the backup path. Wait a second...the backup path is OSPFv3...no good! Remember, RIPng will only insert its best path into the RIPng database. RIPng doesn’t have an alternate path to offer. So having OSPFv3 as the backup is the appropriate behavior...for now.
What happens if we shutdown R-3’s g0/1 interface and then check the route?