Overview

FYI: If you haven't already viewed OSPFv3 Troubleshooting Ticket #1, consider viewing it before this lesson. While these tickets have a different cause and solution, there are similarities so some explanations in this lesson are shorter. Please know there is information that is purposefully repeated from Ticket #1 because it's part of the process and also to help you remember it.

In OSPFv3 Troubleshooting Ticket #2, we have the same requirement as in OSPFv3 Troubleshooting Ticket #1:

  • R-1’s Loopback 16 must be able to ping R-4’s Loopback 46.

OSPFv3 Tshoot Ticket #1 Topology
OSPFv3 Tshoot Ticket #2 Topology

For your convenience, the router configurations are below:

! R1
configure terminal
hostname R-1

ipv6 unicast-routing

interface Loopback 16
ipv6 address 2001:1::1/128

interface Gi0/0
no shutdown
ipv6 address 2001:12::1/64

end

! R1 OSPFv3
configure terminal
ipv6 router ospf 6

router-id 1.1.1.1

int Loopback 6
ipv6 ospf 6 area 1

int g0/0 
ipv6 ospf 6 area 1

end

! R2
configure terminal
hostname R-2
ipv6 unicast-routing
interface Loopback 26
ipv6 address 2001:2::2/128
interface Gi0/0
no shutdown
ipv6 address 2001:12::2/64
interface Gi0/1
no shutdown
ipv6 address 2001:23::2/64
end

! R2 OSPFv3
configure terminal
ipv6 router ospf 6
router-id 2.2.2.2
area 2 stub

int Loopback 6
ipv6 ospf 6 area 0

int g0/0 
ipv6 ospf 6 area 1

int g0/1
ipv6 ospf 6 area 0

end
  

! R3
configure terminal
hostname R-3
ipv6 unicast-routing
interface Loopback 36
ipv6 address 2001:3::3/128
interface Gi0/1
no shutdown
ipv6 address 2001:34::3/64
end

! R3 OSPFv3
configure terminal
ipv6 router ospf 6
router-id 3.3.3.3
area 2 stub

int Loopback 6
ipv6 ospf 6 area 0

int g0/0 
ipv6 ospf 6 area 0

int g0/1
ipv6 ospf 6 area 2

end
 

! R4
configure terminal
hostname R-4
ipv6 unicast-routing
interface Loopback 46
ipv6 address 2001:4::4/128
interface Gi0/0
no shutdown
ipv6 address 2001:34::4/64
end

! R4 OSPFv3
configure terminal
ipv6 router ospf 6
router-id 4.4.4.4
area 2 stub
passive-interface default

int Loopback 6
ipv6 ospf 6 area 2

int g0/0 
ipv6 ospf 6 area 2

end
  

Step 1: Test for Desired Result

Ping

R-1#ping 2001:4::4 source 2001:1::1 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4::4, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
.....
Success rate is 0 percent (0/5)

We have proved that there is a connectivity issue between R-1's Lo16 and R-4's Lo46.

No End-to-End Connectivity
No End-to-End Connectivity

Step 2: Locating the Cause

To simplify testing for the cause of the connectivity issue, let's first isolate where the issue is.

R-1's Perspective

Traceroute

R-1#traceroute 
Protocol [ip]: ipv6
Target IPv6 address: 2001:4::4
Source address: 2001:1::1
Insert source routing header? [no]: 
Numeric display? [no]: 
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Priority [0]: 
Port Number [0]: 
Type escape sequence to abort.
Tracing the route to 2001:4::4

  1  *  *  * 
  2  *  *  * 
  3  *  *  * 
  4  *  *  * 
  5  *  *  * 
  6  *  *  * 
  7  *  *  * 
  8  *  *  * 
  9  *  *  * 
 10  *  *  * 

I only needed to enter the information highlighted above to meet the requirement of ping from the source address of R-1's Lo16. The rest of the parameters I hit enter to use the default.

The traceroute from R-1 didn't make it one hop out of the router.

Pro Tip: Most terminal emulators use Ctrl+Shift+6 for the break.

Since the traceroute from R-1 didn't even make it to R-2, let's check to see if R-1's routing table has a route for 2001:4::4.

Routing Table

R-1#show ipv6 route 2001:4::4
% Route not found

R-1 doesn't have a route to R-4's Lo46.

Let's check if we have a route to the 2001:34::/64...

R-1#show ipv6 route 2001:34::/64
Routing entry for 2001:34::/64
  Known via "ospf 6", distance 110, metric 3, type inter area
  Route count is 1/1, share count 0
  Routing paths:
    FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
      Last updated 00:02:43 ago

We have a better idea now of where the problem is. It's somewhere between the prefix 2001:34::/64 and 2001:4::4.

Issue Better Isolated
Issue Better Isolated

We have a route to the 2001:34::/64 subnet, so we know that R-3's g0/1 is participating in the OSPFv3 domain.

It's always a good idea to verify, and possibly document, with output:

R-1#ping 2001:34::3 source 2001:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:34::3, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

Good.

We need to test to see if R-4's g0/0, on the other side of the link, is participating:

R-1#ping 2001:34::4 source 2001:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:34::4, timeout is 2 seconds:
Packet sent with a source address of 2001:1::1
.....
Success rate is 0 percent (0/5)

We've completed an important step by proving that the issue lies between R-3 and R-4.

More specifically, we've proven that R-4 is failing to advertise inerfaces into the OSPFv3 domain via R-3's g0/1 interface.

Step 3: Discover What the Cause Is

Now that we have a good idea where the issue is, it's time to look for the cause.

By pinging the directly connected interface from R-3 to R-4, we can learn if the following are operating correctly:

  • OSI Layer 1 (Physical)
  • OSI Layer 2 (Data-Link)
  • OSI Layer 3 (Network) - A successful ping also proves both interfaces are in the same subnet.

R-3#ping 2001:34::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:34::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/6 ms

Great! We now know that R-3 and R-4 are working at Layers 1,2 and 3.

Let's see how the route to 2001:34::4 was learned:

Routing entry for 2001:34::/64
  Known via "connected", distance 0, metric 0, type connected
  Route count is 1/1, share count 0
  Routing paths:
    directly connected via GigabitEthernet0/1
      Last updated 00:06:23 ago

As shown above, the route is directly connected.

OSPFv3 Neighborship

Since R-3 and R-4 are good at OSI layers 1,2 and 3 but R-3 isn't processing OSPFv3 updates from R-4, it makes sense to next check if they are OSPFv3 neighbors.

FYI: The show ospfv3 neighbor and show ipv6 ospf neighbor commands have the same output. I prefer the show ospfv3 neighbor command because I don't want to confuse:
OSPFv3's show ipv6 ospf neighbor command with
OSPFv2's show ip ospf neighbor command.

R-3#show ospfv3 neighbor

          OSPFv3 6 address-family ipv6 (router-id 3.3.3.3)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/BDR        00:00:30    3               GigabitEthernet0/0

We see that we have a FULL Adjacency with R-2 (Neighbor RID 2.2.2.2), but nothing for R-4. This means that R-4 hasn't even begun to form a neighborship with R-4. If OSI layers 1,2 and 3 are operating correctly, this is usually do to a mismatch with one or more Hello packet parameters.

Hello packet parameters include:

  • Subnet
  • OSPFv3 Process
  • Unique Router ID
  • Stub Flag
  • Area ID
  • Authentication
  • Hello and Dead Timers
  • MTU Size

FYI: If you'd like to learn about the above OSPFv3 parameters in more detail, see the Neighborship Criteria section of the OSPFv3 Neighborship and Adjacency lesson.

Let's work our way down the list of required matching parameters to verify that they are a match between R-3 and R-4.

Subnet

We had already verified that R3's g0/1 and R-4's g0/0 are in the same subnet when we successfully pinged between these interfaces in Step 3: Discover What the Cause Is.

  • Subnet
  • OSPFv3 Process
  • Unique Router ID
  • Stub Flag
  • Area ID
  • Authentication
  • Hello and Dead Timers
  • MTU Size

OSPFv3 Process, Unique RID, Stub Flag and Area ID

The show ipv6 protocols command is great for verifying lots of useful information about any and all routing protocols running on the router:

R-3#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "application"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 6"
  Router ID 3.3.3.3
  Area border router
  Number of areas: 1 normal, 1 stub, 0 nssa
  Interfaces (Area 0):
    Loopback36
    GigabitEthernet0/0
  Interfaces (Area 2):
    GigabitEthernet0/1
  Redistribution:
    None

R-4#show ipv6 protocols 
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "application"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 6"
  Router ID 4.4.4.4
  Number of areas: 0 normal, 1 stub, 0 nssa
  Interfaces (Area 2):
    Loopback46
    GigabitEthernet0/0
  Redistribution:
    None

The above output shows us that R-3 and R-4 both:

  • Share the OSPFv3 Process of 6
  • Have unique RIDs
  • Have adjacent interfaces that share the same Area ID of 2
  • Have a match with the number of stub areas and the topology diagram. We need to do more checking to verify the stub areas were configured correctly, though.

Let's scratch these items off our Hello packet parameters list:

  • Subnet
  • OSPFv3 Process
  • Unique Router ID
  • Stub Flag
  • Area ID
  • Authentication
  • Hello and Dead Timers
  • MTU Size

FYI: The show ospfv3 interface brief command is another great command that should be used often:

R-3#show ospfv3 interface brief 
Interface    PID   Area            AF         Cost  State Nbrs F/C
Lo6          6     0               ipv6       1     LOOP  0/0
Gi0/0        6     0               ipv6       1     DR    1/1
Gi0/1        6     2               ipv6       1     DR    0/0

R-4#show ospfv3 interface brief 
Interface    PID   Area            AF         Cost  State Nbrs F/C
Lo6          6     2               ipv6       1     LOOP  0/0
Gi0/0        6     2               ipv6       1     DR    0/0

The show ospfv3 interface brief command shows us a lot of useful information, including that R-3's g0/1 and R-4's g0/0 haven't formed a neighborship. We know this because they can't both be DRs with each other and they both have 0/0 neighbors on the link.

If you don't know what an OSPFv3 Designated Router (DR) is, consider viewing the Non-Broadcast Multi-Access (NBMA) section of the OSPFv3 Neighborship and Adjacency lesson.

Let's check the next item on our list, the Stub Flag:

  • Subnet
  • OSPFv3 Process
  • Unique Router ID
  • Stub Flag
  • Area ID
  • Authentication
  • Hello and Dead Timers
  • MTU Size

We can do this by checking all OSPF (OSPFv2 and OSPFv3) commands issued on the router with the show run | section ospf command.

R-3#sh run | sec ospf
 ipv6 ospf 6 area 0
 ipv6 ospf 6 area 0
 ipv6 ospf 6 area 2
ipv6 router ospf 6
 router-id 3.3.3.3
 area 2 stub

R-4#sh run | sec ospf
 ipv6 ospf 6 area 2
 ipv6 ospf 6 area 2
ipv6 router ospf 6
 router-id 4.4.4.4
 area 2 stub
 passive-interface default

We've further verified the routers have unique RIDs and both routers have area 2 as a stub area.

  • Subnet
  • OSPFv3 Process
  • Unique Router ID
  • Stub Flag
  • Area ID
  • Authentication
  • Hello and Dead Timers
  • MTU Size

However, R-4 has the passive-interface default command issued under the router ospfv3 6 process!!!

An OSPFv3 passive-interface isn't a Hello packet parameter, but it will prevent OSPFv3 messages from being sent!!!

A passive-interface can also be discovered by:

R-4#show ospfv3 interface g0/0
GigabitEthernet0/0 is up, line protocol is up 
  Link Local Address FE80::E5E:FAFF:FE2F:CF00, Interface ID 2
  Area 2, Process ID 6, Instance ID 0, Router ID 4.4.4.4
  Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 4.4.4.4, local address FE80::E5E:FAFF:FE2F:CF00
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    No Hellos (Passive interface) 
  Graceful restart helper support enabled
  Index 1/2/2, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0 
  Suppress hello for 0 neighbor(s)

The show ospfv3 interface g0/0 command shows a lot of information for the specified interface including that no Hello packets have been received due to a passive interface. If you discover a passive-interface with this command the show run | section ospf command can be used to discover whether a passive-interface was configured in OSPFv3 router configuration mode with the passive-interface default command or at the interface level with the ospfv3 passive-interface command.

Step 4: Solution

For this lab, there are two solutions:

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