Home › Routing › IPv6 › The Case of the Failed IPv6 Ping – Part 1: The Facts and Clues

The Case of the Failed IPv6 Ping – Part 1: The Facts and Clues

By Denise "Fish" Fishburne on June 12, 2016 • ( 4 )

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

Part #1 – We hit the crime scene together and we work methodically together to

Gather the Facts
Collect the Clues
Follow the Evidence
Interview the Witnesses
Question the Suspects

Part #2 – I give you what the problem ended up being.

Ready? 🙂 Let’s PLAY!

The Facts of the Case of the Failed IPv6 Ping

It all started when I was going to do a post on IPv6 Multicasting. I grabbed 3 ASR1K and got them all prepped: cards, code, cables, configurations. Name the routers R1, R2, and R3. Add a couple Spirent TestCenter ports for traffic and sniffing , configure them, and we are good to go.

Time for “pre-flight check”, as it were.

PIM neighbors up and running between the routers – CHECK
Make sure that the R3 can ping 2001:db8:14:1::1 – Um……

Oh… crap… that didn’t work.

Let’s go to the active crime scene!

Troubleshoot Ride-Along

Let’s troubleshoot and narrow the focus.

Can R3 can ping 2001:db8:14:1:: ?

Does R3 Have a Route to 2001:db8:14:1:: ?

Well that didn’t work did it? Let’s check the routing table on R3.

From R3’s IPv6 routing table we see

R3 does not know about 2001:db8:14:1::
R3 has an OSPF peer with R2 (FE80::2) out Gig 0/0/2.

Do R1 and R2 Have OSPFv3 Up Between Them ?

Maybe the OSPFv3 neighbor is not up and running between R1 and R2. Let’s go look at this.

Okay, so OSPFv3 neighbor is up between R1 and R2.

Does R2 Have a Route to 2001:db8:14:1:: ?

No, apparently R2 does NOT have 2001:db8:14:1:: ?

Let’s Review the Facts and Clues

One thing about troubleshooting that is very important – sometimes if you don’t keep track of what all you have checked, you are going to go around in circles and waste time. So let’s get methodical here. So let’s look at the facts as we know them thus far and review.

Now let’s take that checklist of facts and see it in a picture.

At each step we seem to be moving closer and closer and closer to R1 as the source of the issue.

Time to Check in with R1

So let’s go to R1 and find out why it is not advertising this subnet. What are the obvious guesses?

Admin Down: R1’s interface for 2001:db8:14:1:: is still administratively shut down
Not in OSPFv3: R1’s interface for 2001:db8:14:1:: is not configured to be advertised in R1’s OSPFv3
No IPv6 Address Configured: R1 doesn’t have an interface configured with 2001:db8:14:1::.

Off to R1 to see which one it is.

Hmmmm….. okay so upon quick glance it all looks good. Looks like none of those three.

Just to double check, I’ll ping 2001:db8:14:1::1 from R1 itself.

What the…. ???? Okay, it’s late and I’m tired. I’m probably just typing the IPv6 address incorrectly. Let’s just copy and paste directly from the config. Nope. Same thing. Ping fails.

“Duh, Denise, you are an idiot”, I think to myself. “Just because it is not administratively down doesn’t mean it is up/up!”

Check to see if it is up/up –