Simple IPv6 Multicast Configuration

IPv6 Multicasting is something that's been confusing me a bit lately.  I think I finally have the basics figured out...  And I'm going to put there here so that you can read all about it.  Because you want to read all about it. Don't you?

I thought so.

I'm using a simple 3 router topology: two Ethernet links, and a Frame Relay link between R2 and R3 using physical interfaces (multipoint); Inverse ARP has been disabled.  The addresses all have the router number as the last chunk (chazwazza?). OSPFv3 has been spun up with everything in area 0 to give PIM something to work with.  I've also added some loopbacks.

This post is assuming that you know how to get this far...  I'm not going to cover how to get OSPFv3 running properly here.

To get started the first thing we need to do is enable IPv6 multicasting on each router:

Router(config)# ipv6 multicast-routing

Easy enough so far.  But there's a few differences in what you're going to do next compared to IPv4 multicasting.  In IPv6 PIM is automatically enabled on every interface that's already running IPv6, and it's running in what we all know as "Sparse Mode". 

At this point you should start seeing some tunnels appear.  These tunnels are used by the routers to talk to their RPs.  The PIM REGISTER and PIM STOP messages are sent over these tunnels.  For now the tunnels will be up/down, but that will change once we get the RP information distributed to our routers.  We're going to do that next.

IPv6 PIM can use a couple different methods to distribute RP information.  There's the same BSR we all know and love from IPv4.  There's also static RPs.  Lastly, a new method is embedded RP where the RP address is actually directly in the multicast address that a receiver wishes to join.  Gone is Auto-RP and the sparse-dense nonsense that accompanied it (or Auto-RP listener alternatively).

For this post I'm just going to use BSR.  Static RP is self explained, and embedded RP would be a post in itself.

In IPv6 BSR works pretty much the same way. You first define one or more BSR candidates, and you then define one or more RP candidates.  I'm going to use the loopback of R1 as my BSR.

R1(config)#ipv6 pim bsr candidate bsr 2001:11::1 ?
  <0-128>   BSR Hash mask length
  priority  Priority for this is Candidate BSR
 

Just like always, you can set a priority (default is 0, highest wins) and a hash mask. You can verify your BSR configs and information distribution with the following command:

R1#sh ipv6 pim bsr election
PIMv2 BSR information

BSR Election Information
  Scope Range List: ff00::/8
  This system is the Bootstrap Router (BSR)
     BSR Address: 2001:11::1
     Uptime: 01:00:26, BSR Priority: 0, Hash mask length: 126
     RPF: FE80::A8BB:CCFF:FE00:100,Loopback0
     BS Timer: 00:00:38
  This system is candidate BSR
      Candidate BSR address: 2001:11::1, priority: 0, hash mask length: 126

Next we need to define our RP.  I'll use the loopback of R2 as my RP.

R2(config)#ipv6 pim bsr candidate rp 2001:22::2 ?
  bidir       Specify keyword bidir to configure a bidir RP
  group-list  Group list for this is Candidate RP
  interval    Specify advertisement interval for configured RP
  priority    Specify priority for configured RP
 

Here we also find the usual suspests of config options (default priority is 192, highest wins).

It's at this point you should start seeing those tunnels that were created earlier transition to the up/up state (that is if everything is working properly).  If they don't then you most likely have an RPF failure somewhere and it's off to debug land to troubleshoot the problem.

Normally I'd like to so a little verfication at this point.  As of yet I haven't really found comparable commands in IPv6 PIM to what I'm used to in IPv4...  And it really irks me. There is this command:

R2#sh ipv6 pim bsr candidate-rp
PIMv2 C-RP information
    Candidate RP: 2001:22::2 SM
      All Learnt Scoped Zones, Priority 192, Holdtime 150
      Advertisement interval 60 seconds
      Next advertisement in 00:00:57

But as near as I can tell that's only good on the C-RP itself!  It won't show you other C-RPs, and if we try on a different router, like our BSR, it shows nothing at all!

R1#sh ipv6 pim bsr candidate-rp
No C-RP information found

That's exactly no help whatsoever.  There's also the following command:

R1#sh ipv6 pim bsr rp-cache
PIMv2 BSR C-RP Cache

BSR Candidate RP Cache

Group(s) FF00::/8, RP count 1
  RP 2001:22::2 SM
    Priority 192, Holdtime 150
    Uptime: 11:16:19, expires: 00:02:25

But this one only works on the BSR!  If you try that on anther router, even the RP itself, you get squat.

R2#sh ipv6 pim bsr rp-cache
No BSR RP-Cache information found

I clearly must be missing something here.  There just doens't seem to be the equivilent to 'sh ip pim rp map' anywhere.  So how do we verify that we have a working RP short of joing a group somewhere and firing off the traffic?  Well, we can look at our tunnels of course!

R1#sh ipv6 pi tunnel
Tunnel0*
  Type  : PIM Encap
  RP    : Embedded RP Tunnel
  Source: 2001:13::1
Tunnel1*
  Type  : PIM Encap
  RP    : 2001:22::2
  Source: 2001:11::1

Ah HAH!  The first tunnel is obviously Embedded RP related, but the second tunnel is between R1 where we ran the show command and the the RP that we configured on R2!  We can take this a bit further and look at the tunnel itself to try and glean a little more information.

R1#sh interfaces tunnel 1
Tunnel1 is up, line protocol is up
  Hardware is Tunnel
  MTU 1452 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 2001:11::1 (Loopback0), destination 2001:22::2
   Tunnel Subblocks:
      src-track:
         Tunnel1 source tracking subblock associated with Loopback0
          Set of tunnels with source Loopback0, 1 member (includes iterators), on interface
  Tunnel protocol/transport PIM/IPv6
  Tunnel TOS/Traffic Class 0xE0,  Tunnel TTL 65
  Tunnel transport MTU 1452 bytes
  Tunnel is transmit only
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output 01:14:44, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     2 packets output, 296 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

We can see our tunnel is up/up, we have valid source and destinations, and the tunnel protocol and transport are PIM and IPv6 respectively. 

OK, everything is looking good. 

If our RP wasn't configured correctly, for whatever reason, the tunnel would not be present on our routers at all.  Neither of the above commands would give us any information at all.

R1#sh ipv6 pim tunnel
Tunnel0*
  Type  : PIM Encap
  RP    : Embedded RP Tunnel
  Source: 2001:13::1

Finally, let's have one of our routers join a group (using MLD, not IGMP)

R3(conf)# interface Loopback0
R3(conf)# ipv6 mld join-group FF04::3

And then fire off some pings (because that's how network admins roll).

R1#ping ff04::3
Output Interface: loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF04::3, timeout is 2 seconds:
Packet sent with a source address of 2001:11::1

Reply to request 0 received from 2001:33::3, 8 ms
Reply to request 1 received from 2001:33::3, 4 ms
Reply to request 2 received from 2001:33::3, 4 ms
Reply to request 3 received from 2001:33::3, 4 ms
Reply to request 4 received from 2001:33::3, 4 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
5 multicast replies and 0 errors.

Ta Da!