You’ve been asked to investigate and provide a solution for an increased delay from traffic that originates from host devices connected to R-1 going to destinations outbound to R-3.

RIPng Troubleshooting Topology
RIPng Troubleshooting Topology

R-1’s Lo16 represents our subnet of hosts, while R-3’s Lo36 represents traffic going outbound (maybe to a Data Center, WAN connection, etc.).

Step 1: Verify Basic Connectivity

Let’s begin by verifying that Lo16 can ping Lo36.

R-1#ping 2001:33::36 source Lo16
Sending 5, 100-byte ICMP Echos to 2001:33::36, timeout is 2 seconds:
Packet sent with a source address of 2001:11::16
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms

As expected, we have connectivity but the traffic to and from is slow for our small topology: round-trip min/avg/max = 3/3/4 ms. We'll compare these times with times after we discover and then correct the cause.

Step 2: Verify Path

Let's see what path the traffic is taking:

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

The traffic is taking the alternate path of R1>R2>R3. We need to find out why the traffic isn't using the primary path and correct the issue. Then, the ping time should be faster than what we had above.

Let’s take a look at some other commands that we could have used to discover the path taken:

R-1#show ipv6 route rip
IPv6 Routing Table – default – 8 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

Here we can see that the next hop from R-1 to the 2001:23::/64 network and to 2001:33::36 is via FE80:12::2, GigabitEthernet0/0.We can also see the administrative distance (120) and the metric (2,3) for these routes.

We could have also used:

R-1#show ipv6 route 2001:33::36
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:08:16 ago

The show ipv6 route [host address] command includes how the route was learned, AD/Metric and the routing path.

Step 3: Discovering the Cause

Step 3a: Examining the Local Router

Let’s make sure that our interfaces have the correct addresses (including prefix):

R-1#show ipv6 interface g0/1
GigabitEthernet0/1 is up, line protocol is up
   IPv6 is enabled, link-local address is FE80:13::1
   No Virtual link-local address(es):
   Global unicast address(es):
     2001:13::1, subnet is 2001:13::/64
    Joined group address(es):
R-1#show ipv6 interface Lo16
Loopback16 is up, line protocol is up
   IPv6 is enabled, link-local address is FE80:11::16
   No Virtual link-local address(es):
   Global unicast address(es):
     2001:11::16, subnet is 2001:11::16/128
    Joined group address(es):

The traffic is taking the alternate path of R1>R2>R3. This could be the cause, but to prove it we need to restore the primary path and test it.

Pro Tip: In certain situations RIPng can take longer than other routing protocols!

Let's make sure that our interfaces are active:

R-1#show ipv6 interface brief
GigabitEthernet0/0 [up/up]
GigabitEthernet0/1 [up/up]
Loopback16 [up/up]

All of our interfaces are up/up.

Let’s make sure that the appropriate interfaces are participating in the correct RIPng process:

R-1#show ipv6 protocols
IPv6 Routing Protocol is "rip RIP_TEST"

Lo16, g0/1 and g0/0 are all participating in the rip RIP_TEST process.

Everything looks fine on the local router. Let's take a look at R-3.

Step 3b: Examining the Remote Router(s)

Let’s see if we can connect to a destination on the primary path from R-1 to R-3’s Lo36. In this case, we should see if we can reach R-3’s g0/1 interface:

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