Home › Routing › IPv6 › The Case of the Failed IPv6 Ping – Part 2: The Solution

The Case of the Failed IPv6 Ping – Part 2: The Solution

By Denise "Fish" Fishburne on June 16, 2016 • ( 7 )

Put your detective hat on your head and your Network Detective badge on your lapel. It is time to SOLVE for the Case of the Failed IPv6 Ping.

Review the Facts and Clues Again

Let’s review where we left off in our Part 1 of this case — “Case of the Failed IPv6 Ping – Part1: Facts and Clues“. At the end of Part 1…..we were ON R1 and unable to ping the IPv6 address of our directly connected interface gig0/0/3, 2001:db8:14:1::1.

As you recall the facts were as below. Interface up/up, OSPFv3 configured properly, proper IPv6 address configured on interface gig0/0/3. Still, we cannot ping R1’s directly connected IPv6 address from anywhere including from R1 itself.

Totally confused. Time to just stare at the list above, absorb the oddness, and think.

Wait! I Remember Seeing Something Strange!

Wait one second!!!! “No valid route for destination” ??? Even the ping from R1 said that?

“That can’t be true“, I think to myself while I type show ipv6 route connected.

How Can We Be Missing and Up/Up Interface in the IPv6 Routing Table?

What the????….. Why don’t I have R1’s gig0/0/3 interface in the routing table? It is up/up and with the proper IPv6 address configured. Now what? Think… think… think. Hmmm… I wonder if I configured an IPv4 address on that same interface if it would also not respond to pings or show up in the routing table locally.

Add a IPv4 address to R1’s gig 0/0/3 interface.
Look at IPv4 routing table.
- Dang it’s in there. Hmmmm.
Ping the IPv4 address on R1’s gig0/0/3 interface.
- Works.

Arg! What is going on?

Square 1

Back to square 1 again. Confused and still not “seeing it” yet. Time to stare at the diagram to see if I can trigger any ideas.

Time to Guess, Play, and Explore This Oddness

Hmmmm…. you know R3 also has a connection to a Spirent. I wonder if it’s 2001:db8:14:4:: subnet is experiencing the same thing over there that R1’s connection to the Spirent is experiencing.

Going to R3 I can

see 2001:db8:14:4:: in the IPv6 routing table
ping 2001:db8:14:4::1

Okay… well that ping worked. Oh well. It was a thought.

Go back to R1. Obviously I’m missing something. Let’s go a little deeper. We know the interface is up/up. I have by now followed the cable and confirmed all is well there. The IPv6 address is on there. The interface does not show up in the IPv6 routing table. Time to go deeper. Let’s look not just at R1’s gig0/0/3 configuration and state, let’s look at it from an IPv6 perspective.

IPv6 is “Stalled”? What Does That Mean?

My mind starts racing with thoughts:

IPv6 is “stalled”? Never seen that before. What does that mean? Hmmmm…. I’m guessing that isn’t good. Maybe I have found it. Should I Google “IPv6 is stalled”?

…but I continue to review the rest of the show ipv6 interface command for more clues first.

I’m going to make 2 guesses here.

DUP might mean “duplicate”
TEN might mean “tentative”

If that is correct then I would guess that the IPv6 being “stalled” has something to do with one of those two or both. But this doesn’t make any sense. It is a cable from R1’s gig0/0/3 directly into the Spirent TestCenter port. I only have two devices on the wire. How can DUP mean duplicate? Okay….. time to sniff the wire.

Ooops! Ouch! Guess DUP does mean duplicate!

If you have ever played with Spirent TestCenter that “00:10:94” source MAC should look very familiar. But suffice it to say that source MAC address is NOT R1’s gig0/0/3 interface. R1’s IPv6 link local address I was using for all of its interfaces (FE80::1) is the exact same default link local address that Spirent uses.