Overview

In OSPFv3 Troubleshooting Ticket #1, we have the following requirement:

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

OSPFv3 Tshoot Ticket #1 Topology
OSPFv3 Tshoot Ticket #1 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

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/0
no shutdown
ipv6 address 2001:23::3/64
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

int Loopback 6
ipv6 ospf 6 area 2

int g0/0 
ipv6 ospf 6 area 2

end
  

Typically, issues present themselves when a lack of connectivity is discovered.

Maybe a user notices the lack of connectivity. In such a case, R-1’s Loopback 16 could represent the connection to the Internet Service Provider (ISP) and R-4’s Loopback 46 could represent a LAN to end users.

Maybe after configuration the administrator tests connectivity with the ping command and the ping fails.

Either way, testing usually begins with a ping.

Step 1: Test for Desired Result

Ping

Pinging with the standard ping of ping 2001:4::4 won't do the test we want. Without specifying the source of the ping, the ping will be automatically sent from R-1’s Gi0/0 interface.

The requirement above says that we must ping from R-1's Lo16 to R-4's Lo46. To do this, we use an extended ping that would specify the source:

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)

The ping has failed on each of the 5 attempts (Each “.” represents a failed attempt).

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.

Since the requirement is to ensure connectivity between R-1's Lo16 and R-4's Lo46, lets begin by seeing what we can learn from R-1.

R-1's Perspective

Let's see what the network looks like from R-1 with respect the issue at hand.

Traceroute

Along with the ping command, the traceroute should be one of the first commands to consider when troubleshooting.

Traceroute takes longer than pinging, especially for larger networks, but it let's us know every time it makes it to the next hop.

Traceroute is also great if there are multiple routes to the same destination. For example, we may want to know if traffic is using the primary route or the backup.

Just like the ping command, there is a standard and extended traceroute. As with the standard ping, issuing the standard traceroute of traceroute 2001:4::4 would use R-1's g0/0 interface as the source.

To specify R-1's Lo16 as the source, we need to use an extended 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  *  *  * 

For this lab, I only needed to enter the information highlighted above. 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. I gave the traceroute 10 tries before I stopped the process.

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

FYI: If you'd like to learn more about extended ping and extended traceroute and their options see the reference in the Other Material section below.

With what we have learned so far, we know that we don't have connectivity between R-1' Lo16 and R-4's Lo46 but we don't have a very good idea where the problem is.

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

Depending on filtering preference, there are several commands that we can use to check the routing table including:

  • show ipv6 route - shows all ipv6 routes
  • show ipv6 route ospf - shows all ipv6 routes learned via ospfv3.
  • show ospfv3 route - Shows ipv4 and ipv6 ospfv3 learned routes with additional information (see below).
  • show ospfv3 route [destination] - same as show ospfv3 route, but checks only for an entry for the specified destination.

For our small topology, using either the show ipv6 route ospf or the show ospfv3 route command is a good choice as we can see everything that R-1 has learned from OSPFv3. Below I show both so you can get familiar with them:

R-1#show ipv6 route ospf 
[Some output omitted]
OI  2001:2::2/128 [110/1]
     via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
OI  2001:3::3/128 [110/2]
     via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
OI  2001:23::/64 [110/2]
     via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
OI  2001:34::/64 [110/3]
     via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0

R-1#show ospfv3 route
[Some output omitted]

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


    Area 1

    Intra-area Route List

*   2001:12::/64, Intra, cost 1, area 1, Connected
      via GigabitEthernet0/0
*   2001:1::1/128, Intra, cost 0, area 1, Connected
      via Loopback6

    Inter-area Route List

*>  2001:34::/64, Inter, cost 3, area 1
      via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
*>  2001:3::3/128, Inter, cost 2, area 1
      via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
*>  2001:23::/64, Inter, cost 2, area 1
      via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
*>  2001:2::2/128, Inter, cost 1, area 1
      via FE80::E5E:FAFF:FE0A:C00, GigabitEthernet0/0
          
    First Hop Forwarding Gateway Tree

 :: on GigabitEthernet0/0, count 1
 FE80::E5E:FAFF:FE0A:C00 on GigabitEthernet0/0, count 4
 :: on Loopback6, count 1

This is interesting. We have a route to the 2001:34::/64 prefix, but not to 2001:4::4.

Pro Tip: The above commands can generate a lot of output for large OSPFv3 domains. It can be easier to check for specific routes:

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

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 04:52:08 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, but we don't know if we can reach all of the interfaces within this subnet.

However, we can deduce that since R-1 has learned of the 2001:34::/64 prefix, that R-3's g0/1 is participating in the ospfv3 domain. If it wasn't, all of the 2001:34::/64 would be cut off. (If this doesn't make sense to you, take the time to look at the topology and think about how OSPFv3 information would flow through the domain.)

To demonstrate that we can reach R-3's g0/1 as mentioned above:

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.

Let's try to ping the farthest interface in the 2001:34::/64 prefix (R-4's g0/0):

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 interfaces 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.

Direct Connect Connectivity

We should verify that there aren't any issues between R-3 and R-4 at the Physical and Data-link Layers of the OSI Model.

This can be accomplished with a simple ping:

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/7 ms

FYI: This successful ping also proves that both sides of the link are in the same subnet.

OSPFv3 Neighborship

First, I want to check if R-3 and R-4 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:31    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-3 hasn't even begun to form a neighborship with R-4. This is usually because of a mismatch with a Hello packet parameter.

The following is a list of Hello packet parameters:

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

FYI: If you'd like to review the OSPFv3 parameters that must match for a neighborship/adjacency to form 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 already know that the interfaces on both sides of the link are in the same subnet because the ping that we ran above to test direct connectivity between R-3 and R-4 was successful. Here is the output again:

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/7 ms

Again, since the ping was successful, we know that the interfaces on either side of the link are connected at layer1, 2 and 3 of the OSI Model.

  • 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 should be used often. Its output has many useful items and is easy to read. Let's compare R-3 and R-4 side by side:

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: 2 normal, 0 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

So we've verified 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

However, we can see that R-3 has been configured with 2 normal areas and no stub areas. R-4 has 1 stub area configured.

If we take a look at our topology, we can see that the R-3 and R-4 should both be have one Stub area!

Because R-3's g0/1 isn't configured as a Stub area, it's sending Hello packets to R-4 with the Stub Flag "off".

Because R-4's g0/0 is configured as a Stub area, it's sending Hello packets to R-3 with the Stub Flag "on".

This mismatch will prevent a neighborship from forming!

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

FYI: Although a Stub and Totally Stubby areas operate a little differently, they can be configured on opposite sides of a link and operate properly. They will both set the Stub Flag to "on" so a neighborship will form.

Step 4: Solution

It's important to have clear and accurate documentation so that we can easily see how the network should be configured.

As mentioned above, our topology shows that R-3 and R-4 should connect via a Stub area.

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

Let's verify the stub configurations on R-3 and R-4.

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