Overview

In this lesson, we'll make good use of the Return Codes provided from the ping and traceroute commands to quickly find and solve the issue.

FYI: If you haven't already viewed OSPFv3 Troubleshooting, OSPFv3 Troubleshooting Ticket #1 and OSPFv3 Troubleshooting Ticket #2, consider viewing them before this lesson. While each lesson is certainly useful on its own, these lessons do build on each other.

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

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

OSPFv3 Troubleshooting Ticket #3
OSPFv3 Troubleshooting Ticket #3

For your convenience, the router configurations for this ticket 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 16
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 26
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 FE80::E5E:FAFF:FEE6:BA02 link-local
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 36
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
no passive-interface g0/0

int Loopback 46
ipv6 ospf 6 area 2

int g0/0 
ipv6 ospf 6 area 2

end

! ACL
conf t
ipv6 access-list ACCESS_IN
permit FE80::E5E:FAFF:FEE6:BA02/128 any
permit 2001:12::/64 any
permit 2001:23::/64 any
permit 2001:34::/64 any
deny any any
int g0/0
ipv6 traffic-filter ACCESS_IN in
end
show access-lists
  

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
AAAAA
Success rate is 0 percent (0/5)

This is interesting. We have a return code of "A" for each ping sent. The output also tells us that all of the pings were unsuccessful.

What does code "A" mean? Let's look at the following ICMP Return Code table:

  • ICMP Return Codes
  • ! = Each exclamation point indicates receipt of a reply.
  • . = Each period indicates that the network server timed out while waiting for a reply.
  • ? = Unknown error.
  • @ = Unreachable for unknown reason.
  • A = Administratively unreachable. Usually, this output indicates that an access list is blocking traffic.
  • B = Packet too big.
  • H = Host unreachable.
  • N = Network unreachable (beyond scope).
  • P = Port unreachable.
  • R = Parameter problem.
  • T = Time exceeded.
  • U = No route to host.

So "A" is for Administratively unreachable and this usually means that an Access Control List (ACL) is blocking traffic.

Step 2: Locating the Cause

To simplify testing for the cause of the connectivity issue, let's first get a good idea of where the issue is.

Routing Table

Lets check to see if we have an entry for 2001:4::4 in the routing table.

R-1#show ipv6 route 2001:4::4
Routing entry for 2001:4::4/128
  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:03:28 ago

We do.

So far we have learned that:

  • 2001:4::4 can't be pinged from 2001:1::1.
  • The cause is because it's Administratively unreachable.
  • R-1 does have an OSPFv3 learned entry for 2001:4::4 in its routing table.

To see how the ICMP packet is traveling through the network, we can use the traceroute command. The traceroute will send us a Return Code every time a packet is sent to the next hop router.

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 2001:12::2 3 msec 2 msec 2 msec
  2 2001:23::3 4 msec 3 msec 3 msec
  3 2001:34::4 !A  !A  !A

This output is very useful, we can see that traceroute's ICMP message is making it all of the way to 2001:34::4. Then, something happens Administratively (which is denoted by the "!A") between 2001:34::4 and 2001:4::4.

Administratively Unreachable
Administratively Unreachable

Since R-1 has an OSPFv3 learned entry for 2001:4::4, I'm going to presume, for now, that OSPFv3 is working properly and that the unsuccessful ping and traceroute are due to something outside of OSPFv3.

Let's review some facts that we have learned:

  • Traceroute's ICMP message makes it to R-4's g0/0 interface and then has a problem reaching Loopback 46.
  • The Return Code of "A" usually means a route is blocked because of an Access Control List (ACL).

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.

Since we have the Return Code of "A", it makes sense to check R-4's ACL next:

R-4#show access-Lists 
IPv6 access list ACCESS_IN
    permit ipv6 host FE80::E5E:FAFF:FEE6:BA02 any (11 matches) sequence 10
    permit ipv6 2001:12::/64 any sequence 20
    permit ipv6 2001:23::/64 any sequence 30
    permit ipv6 2001:34::/64 any (1 match) sequence 40
    deny ipv6 any any sequence 50

Let's examine each line of the ACL in order:

  • Sequence 10 - OSPFv3 form and maintain neighborships with Link Local Addresses (LLAs), so the LLA of R-3's g0/1 must be permitted.
  • Traffic sourced from 2001:12::/64, 2001:23::/64 and 2001:34::/64 is permitted.
  • The final statement of deny ipv6 any any denies everything else (This statement isn't necessary because the router will assume everything not explicitly permitted is to be implicitly denied. Personally, I like to have the statement written in an entry.)

Pro Tip: The deny ipv6 any any sequence 50 entry isn't required, but I recommend it. The router will assume everything not explicitly permitted is to be implicitly denied. By explicitly stating the "deny all" statement with an entry of deny ipv6 any any, it's easier for me to keep organized and it's less likely another administrator would make the mistake of not accounting for the hidden implicit "deny all".

All of these ACL entries from the above show access-lists output from above are good, but we're missing something. Notice that there is no statement to allow packets sourced from 2001:1::1.

Let's compare the following pings:

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
AAAAA
Success rate is 0 percent (0/5)

R-1#ping 2001:4::4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

The ping sourced from R-1's Lo16 fails while the ping sourced from R-1's g0/0 succeeds.

R-1's g0/0 with the address 2001:12::1 is permitted by R-4's access list while pings sourced from 2001:1::1 are denied by the explicit "deny all" entry of deny ipv6 any any sequence 50.

FYI: If the ping's source isn't specified as with the above R-1#ping 2001:4::4 , by default the packet(s) will be sourced from the egress interface.

After creating an ACL, it must be applied to an interface. For completeness with our verifications, let's check to make sure the ACL is applied to R-4's g0/0:

R-4#show running-config interface g0/0
[Some output omitted]
 ipv6 address 2001:34::4/64
 ipv6 traffic-filter ACCESS_IN in
 ipv6 ospf 6 area 2
end

Step 4: Solution

To solve this issue let's add 2001:1::1 into the access list:

There are two ways to do this:

  1. Add a new entry to the current Access Control List (ACL) entries.
  2. Remove the ACL completely, then replace it with an ACL that includes our new entry.

Both of these methods work differently and so they should both be carefully considered before moving forward. I'll illustrate why with two examples:

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