Part #1 – I give you the facts and the clues.
Part #2 – I give you what the problem ended up being.
Ready to play?
This is the IPv6 troubleshooting blog that started off as something else entirely. I was going to do a post on IPv6 Multicasting, so I grabbed 3 ASR1K and got them all prepped: cards, code, cables, configurations. Name the routers R1 (first hop router), R2 (rendezvous point), and R3 (last hop router). Add a couple Spirent TestCenter ports for traffic and sniffing , configure them, and we are good to go.
I know I want the Receiver to be off of R3 and the Source to be off of R1. I also know that since I want the Last Hop Router (R3) to cut over to the shortest path tree (SPT) R3 will need to know where the IPv6 source subnet of 2001:db8:14:1::/64 is. So…..
Time for “pre-flight check”, as it were.
- PIM neighbors up and running between the routers.
- Make sure that the R3 can ping 2001:db8:14:1::1.
- Send the MLDv1 from the Spirent Test Center off of R3
- On R3 make sure that the MLDv1 was received
Etc… etc. You get the idea.
But everything got derailed at #2.
Make sure that the R3 can ping 2001:db8:14:1::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.
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. So does R2 have 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 if in a picture.
At each step we seem to be moving closer and closer and closer to R1 as the source of the issue.
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 like 11pm 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 faiils.
“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/
Review the Facts and Clues Again
Thoughts? Ideas? Intrigued? Part #2 with what I found coming soon.