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

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!


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.

ipv6_1

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

  1. PIM neighbors up and running between the routers – CHECK
  2. 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!


Make sure that the R3 can ping 2001:db8:14:1::

ipv6 ping

ping

no_ping

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

ipv6_R3

From R3’s IPv6 routing table we see

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

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

r2_ospf

Okay, so OSPFv3 neighbor is up between R1 and R2. So does R2 have 2001:db8:14:1:: ?

ipv6_R2

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.

checklist3

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

review1

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

review2

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

  1. Admin Down: R1’s interface for 2001:db8:14:1:: is still administratively shut down
  2. Not in OSPFv3: R1’s interface for 2001:db8:14:1:: is not configured to be advertised in R1’s OSPFv3
  3. 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.

r1_configs

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.

pingR1

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 –

upup

ARG!!!

Review the Facts and Clues Again

Thoughts? Ideas?  —  Part #2 coming tomorrow.

2nd_checkList_59523931

 

badge


NOTE:  The above blog originally appeared on Packet Pushers, September, 2014. It was modified slightly and posted here as part of the Techniques of a Network Detective Series.