Overview

In this troubleshooting ticket, as in Ticket #1 and Ticket #2, the path from R-1's Lo16 to R-3's Lo36 is the alternate route of R1>R2>R3.  While the symptom is the same, the cause is different.

Here's the topology diagram:

RIPng Troubleshooting Topology
RIPng Troubleshooting Topology

Troubleshooting Ticket #3

Let's begin by making sure that R1's Lo16 can reach R3's Lo36 with a ping using Lo16 on R-1 as the source address. If we send a ping without specifying Lo16 as the source address, then the Gi0/1 will be used as the source.

What's the difference? Maybe an ACL is blocking traffic from Lo16's prefix, but not Gi0/1's.

R-1#ping 2001:33::36 source Loopback 16  
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 = 1/1/1 ms

As expected our ping is successful. What path are we connecting to R3's Lo36 with?

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

Okay. So we've confirmed the information in our ticket that says traffic from 2001:11::16 to 2001:33::36 is taking the alternate route of R1>R2>R3.

 Let's look at our local router of R1 first to see why it's not sending traffic destined to 2001:33::36 out Gi0/1.

R-1#show ipv6 interface brief  
GigabitEthernet0/0     [up/up] 
   FE80:12::1 
   2001:12::1 
GigabitEthernet0/1     [up/up] 
   FE80:13::1 
   2001:13::1 
Loopback16             [up/up] 
   FE80:11::16 
   2001:11::16

All of the interfaces that we're using in this lab are up/up and are addressed correctly per the topology diagram. Since layer 1 and 2 look good, let's move on to layer 3.

Before checking to see if we have a route to R3's Lo36 in R1's routing table, let's see what routing protocols and their processes are running on the router. We should only see RIPng's RIP_TEST process.

Some may prefer to check the routing table before checking the protocols and their processes - player's choice.

R-1#show ipv6 protocols  
[Some output omitted]
IPv6 Routing Protocol is "rip RIP_TEST"
 Interfaces: 
   GigabitEthernet0/1 
   GigabitEthernet0/0 
   Loopback16

Things are good here. Routing table:

R-1#sh 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

Well, this is no surprise. Traffic destined to 2001:33::36 (R3's Lo36) is sent out Gi0/0 and not the preferred Gi0/1.

Things look good on R1. The interfaces are up/up and addressed properly. The appropriate interfaces have the RIPng RIP_TEST process enabled.

Let's use the same steps on to R3:

R-3#show ipv6 interface brief  
GigabitEthernet0/0     [up/up] 
   FE80:23::3 
   2001:23::3 
GigabitEthernet0/1     [up/up] 
   FE80:13::3 
   2001:13::3 
Loopback36             [up/up] 
   FE80:33::36 
   2001:33::36

Our interfaces are up/up and properly addressed.

FYI: Loopbacks are always up/up - they can't go down.

Let's check to see if the interfaces are participating in the RIPng process.

R-3#sh ipv6 protocols
IPv6 Routing Protocol is "rip RIP_TEST"
    Interfaces:
       GigabitEthernet0/0
       Loopback36
    Redistribution:
        None
IPv6 Routing Protocol is "rip RIP-TEST"
    Interfaces:
       GigabitEthernet0/1
    Redistribution:
        None

This isn't good. The g0/1 interface that connects to R-1 is running the wrong RIPng process!

In the RIPng Configuration and Verification lesson, we saw that RIPng automatically creates a process when the process is enabled on an interface. The process does not need to be created first. Misspelling the process when enabling it on an interface will cause a new process to be created and assigned to the interface!

Let's correct this:

R-3(config-if)#do show run interface g0/1
[some output omitted]
interface GigabitEthernet0/1
ipv6 address FE80:13::3 link-local
ipv6 address 2001:13::3/64
ipv6 rip RIP-TEST enable
end

Issuing this command has the following benefits:

  • We can verify the addressing (including prefix)
  • We see again that the RIPng process is incorrect
  • The line ipv6 rip RIP-TEST enable line can be copy/pasted into the next command to prevent a typo. Typing the process manually is what got us into trouble in the first place

Pro Tip: Use a Text Editor like VS Code has many benefits...including helping to avoid typos.

R-3(config-if)#no ipv6 rip RIP-TEST enable

R-3(config-if)#do sh ipv6 protocols
[some output omitted]
Interfaces:
GigabitEthernet0/0
Loopback36
Redistribution:
None
IPv6 Routing Protocol is "rip RIP-TEST"
Interfaces:
None

Interface g0/1 has been removed from the rip RIP-TEST process. Let's remove the wrong process completely:

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