Overview

In this lesson, we’ll examine routing behavior during a RIPng failover.

This lesson builds on the RIPng Configuration and Verification lesson.

How it Works

Here is our topology for this lab:

RIPng Configuration and Verification Topology
RIPng Configuration and Verification Topology

We’re concerned with R-1 having connectivity to R-3’s Lo36 interface.

Verify Normal Operation

Let’s start this lab with connectivity using the optimal path of R1>R3>Lo36.

Using the traceroute command is a good way to ensure connectivity and to verify the path of the traffic flow.

R-1#traceroute 2001:33::36
Tracing the route to 2001:33::36
  1 2001:13::3 8 msec 2 msec 2 msec

Great. We can see that the route is active and the next hop from R-1 was 2001:13::3.

Examine Failover Operation

RIPng Failover Topology
RIPng Failover Topology

Let’s shutdown R-3’s Gi0/1 interface and re-run the same traceroute command:

R-3(config)#interface g0/1
R-3(config-if)#shutdown
*Dec 1 10:50:32.687: %LINK-5-CHANGED: Interface GigabitEthernet0/1, changed state to administratively down
*Dec 1 10:50:33.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

R-1#traceroute 2001:33::36
Type escape sequence to abort.
Tracing the route to 2001:33::36
  
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * *
   2001:23::3 3 msec

Well, this doesn't look pretty. Let's examine what happened.

As expected, after R-3's g0/1 was shutdown it took some time for R-1 to learn the alternate route of R-1>R-2>R-3.

The asterisks mean that R-1 was sending out traceroute messages, but not receiving a reply. A disadvantage of RIPng is that, by default, it is slow to notify neighbors to use an alternate route.

Pro Tip: Give careful consideration before changing RIPng timers! Timers are discussed in more detail in the RIPng for IPv6 Introduction lesson.

Let’s re-run the traceroute command.

R-1#traceroute 2001:33::36
Tracing the route to 2001:33::36
  1 2001:12::2 7 msec 3 msec 1 msec
  2 2001:23::3 1 msec 1 msec 1 msec

There we go. Now we can see that there has been a complete transition from R-1 to 2001:33::36 from R1>R3 to R1>R2>R3.

Let’s examine the output from other useful show commands so we can get more familiar with them:

R-1#show ipv6 route rip
IPv6 Routing Table - default - 7 entries
R 2001:23::/64 [120/2]
      via FE80:12::2, GigabitEthernet0/0
R 2001:33::36/128 [120/3]
      via FE80:12::2, GigabitEthernet0/0

From the output we can see that traffic being sent to the 2001:33::36 network:

  • has an AD of 120 and a metric of 3 (One hop for R-2’s ingress interface of g0/0, one hop for R-3’s ingress interface of g0/0 and one hop for the loopback on R-3 because it’s a connected interface).
  • is being sent out R-1's g0/0 interface to FE80:12::2 (R-2’s g0/0 link-local address).

The show ipv6 route [network/prefix] command is one of my favorites:

R-1#show ipv6 route 2001:33::36/128
Routing entry for 2001:33::36/128
  Known via "rip RIP_TEST", distance 120, metric 3
  Route count is 1/1, share count 0
  Routing paths:
    FE80:12::2, GigabitEthernet0/0
      Last updated 00:06:24 ago

This output has a lot of the same information as the show ipv6 route rip command, but also specifies the RIP process. It's also a clean way to look at routing information for one specific route.

The show ipv6 rip database command has the same information we've already seen, except for the invalid timer countdown value:

To continue reading, please login or become a member for full access...