Mind Your IPv6 PIM Designated Routers

IPv6. Multicasting.

Anyone still here to read this?  There is?  I didn’t scare all of you off?

:)

While labbing last night I managed to configure myself a perfectly non-working IPv6 multicast configuration that appeared to have nothing wrong.  In fact, under certain circumstances it did work, but the one specific test I wanted to do to prove reachability just simply wasn’t working.  I eventually managed to sort it out, though it took a bit of brute forcing PIM parameters to get it to work, and to then sort out why it worked.





Behold!  Our topology:

Assume that all layer 3 routing is already in place, and working properly (all interfaces are reachable by all routers).

R1 is advertising its Loopback0 interface via BSR as an RP Candidate.

R2 is configured as our BSR.

All routers agree that R1’s Loopback0 is the RP for FF00::/8.

R1
==
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
 ipv6 address FE80::1 link-local
 ipv6 address 2001::1/128
 ipv6 mld join-group FF08:1234::1
 ipv6 ospf 1 area 0
!
interface FastEthernet0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:12::1/64
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
!
ipv6 pim bsr candidate rp 2001::1
!

R2
==
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ipv6 address FE80::2 link-local
 ipv6 address 2001::2/128
 ipv6 ospf 1 area 0
!
interface FastEthernet0/0
 ipv6 address FE80::2 link-local
 ipv6 address 2001:12::2/64
 ipv6 ospf 1 area 0
!
interface Serial0/0/0
 ipv6 address FE80::2 link-local
 ipv6 address 2001:23::2/64
 ipv6 ospf 1 area 0
 clock rate 2000000
!
ipv6 router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
!
ipv6 pim bsr candidate bsr 2001::2
!

R3
==
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ipv6 address FE80::3 link-local
 ipv6 address 2001::3/128
 ipv6 ospf 1 area 0
!
interface FastEthernet0/1
 ipv6 address FE80::3 link-local
 ipv6 address 2001:34::3/64
 ipv6 eigrp 34
!
interface Serial0/0/0
 ipv6 address FE80::3 link-local
 ipv6 address 2001:23::3/64
 ipv6 pim hello-interval 2
 ipv6 ospf 1 area 0
!
ipv6 router eigrp 34
 eigrp router-id 3.3.3.3
 no shutdown
 redistribute connected metric 1 1 1 1 1
 redistribute ospf 1 metric 1 1 1 1 1 include-connected
!
ipv6 router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 redistribute connected
 redistribute eigrp 34 include-connected
!

R4
==
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ipv6 address FE80::4 link-local
 ipv6 address 2001::4/128
 ipv6 eigrp 34
!
interface FastEthernet0/1
 ipv6 address FE80::4 link-local
 ipv6 address 2001:34::4/64
 ipv6 eigrp 34
!
ipv6 router eigrp 34
 no shutdown
!

You can ignore the redistribution nonsense on R3.  I was testing the redistribute include-connected keyword, which BTW didn’t work at all.  Not even a little bit.  A complete bunch of lies. 

But I digress.

To the point, I decided that the test I wanted to run was the following:

And for my troubles I was rewarded with the following:

This, my friends, made me very sad.  It also had me very confused.  You see, as I said above everything looked right.  There was no reason why this shouldn’t be working.  Multicasting was enabled, PIM neighbours were all established, RPF checks were good, all the routers knew about the RP…  What else can we possibly look at?  Multicast routes!

OK…  Odd, but not really if you think about it. 

What about R3?

Ok now we’re getting somewhere.  Well we were until we see that it’s Pruned and the OIL is NULL. 

This is the point where I started really scratching my head.  By my thinking R3 should have been sending a Register message to the RP, and who also being the receiver for this group should have sent a PIM Join up towards the source building the SPT.

For argument’s sake, here’s R2 and R1’s mroutes:

R2 isn’t looking good, and R1 looks about what we’d expect if it was never receiving a Register for our multicast source.  Why is it not getting a Register?

Well, because no one is sending one.  That’s why.  (Debugging IPv6 PIM confirmed this)

This is one of those times where a subtle difference between IPv4 behaviour and IPv6 behaviour is just slightly different.  I’ll give you a hint.  What happens if I try my same ping from R4, but I set the outgoing interface to loopback0?

If you’ve figured it out then wait till the end so you don’t ruin it for everyone else ;)

When I discovered this I was at first relieved that my MC config did in fact work, and I was doing things correctly (or at least mostly correct). But there was obviously a problem, and I needed to figure this out. 

The problem here is one of two things, depending on your perspective.  The first problem is that when you ping an IPv6 multicast address in IOS you are asked for the outgoing interface for that ping. This differs from an IPv4 ping in that the IPv4 ping will be sent out ALL interfaces (and this is why you usually see multiple replies: you sent multiple requests!).  Or put another way, if I did this exactly the same in IPv4 the ping would have succeeded because, as you saw, it works when sent out lo0.  This would normally satisfy a given task and we’d be on our way.  Not so fast in IPv6.

The second problem, the one I alluded to in the title, is that R4 just happens to be the PIM DR for the segment between R3 and R4.  Why is R4 out DR? Well my friend, highest IP wins!  OK, first highest priority wins, but they’re both at the default of 1 and therefore the decision went to the tiebreaker of highest IP. 

I’d like to direct your attention to the second paragraph of the following link from the DocCD:

http://www.cisco.com/en/US/docs/ios-xml/ios/ipv6/configuration/12-4t/ip6-multicast.html#GUID-5222D94C-4930-4255-814E-DCD0DB853DFF

“The designated router is responsible for sending PIM register and PIM join and prune messages toward the RP to inform it about active sources and host group membership.”

When I realized that of course R4 was the DR it was one of those “Well eff me silly” moments.  R4 was the DR!  That’s why R3 was showing Pruned and had not OIL!  It assumed that R4 was sending the Register message, but R4 wasn’t because it was the source!

Gotta love it when things suddenly click.

The ping sent out the loopback worked because the ping looped back into the R4, which then “saw” itself go active as the source, and send the Register as it should.  When it sent the same ping out F0/1 it never “saw” itself go active as the source (as per the empty mrouting table) and therefore a Register was never sent and pings failed miserably.

Once I managed to work all that out it was a simple matter to fix things up so my test would work.