Table of contents
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.

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.

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:
- Add a new entry to the current Access Control List (ACL) entries.
- 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...
You must be logged in to post a comment.