Mar
25

Since IPv6 multicast doesn’t support the Auto-RP process like IPv4, there must be other methods for dynamically configuring a RP. The two options are using Bootstrap Router (BSR) and embedded RP. In this post, we will walk through BSR, step by step together.

For BSR to work, we need to have at least 1 candidate BSR router, and 1 candidate RP. For fault tolerance, we would want to have at least 2 of each.   If a RP was on the network, but is powered down, I suppose that would make it a “Lost Candidate”.  :)
To understand the process, let’s watch it in action. We will use the same diagram that we did in the previous blog post. (To see the details of the topology and an example of static RP, please visit the original post).

IPV6 Multicasting

First, we will configure a couple routers as BSR candidates. The router that ends up as the BSR will listen for RP volunteers (candidate RPs), and let the rest of the network know which devices are the RPs. All of this is done directly through PIM messages, so no out of band control plane is required. Let’s set up R2 and R3 as BSR candidates. The one with the highest priority will be the winner of the BSR election. With BSR, a larger number for priority means a higher priority.

R2(config)#ipv6 pim bsr candidate bsr 2002:2222::2 priority 2
R2#show ipv6 pim bsr election
PIMv2 BSR information

BSR Election Information
  Scope Range List: ff00::/8
  This system is the Bootstrap Router (BSR)
     BSR Address: 2002:2222::2
     Uptime: 00:01:13, BSR Priority: 2, Hash mask length: 126
     RPF: FE80::C002:13FF:FE08:0,Loopback0
     BS Timer: 00:00:46
  This system is candidate BSR
      Candidate BSR address: 2002:2222::2, priority: 2, hash mask length: 126

R3(config)#ipv6 pim bsr candidate bsr 2002:3333::3 priority 1
R3#show ipv6 pim bsr election
PIMv2 BSR information

BSR Election Information
  Scope Range List: ff00::/8
     BSR Address: 2002:2222::2
     Uptime: 00:00:08, BSR Priority: 2, Hash mask length: 126
     RPF: FE80::244:44FF:FE44:4444,FastEthernet0/0
     BS Timer: 00:02:01
  This system is candidate BSR
      Candidate BSR address: 2002:3333::3, priority: 1, hash mask length: 126

Now we need some volunteers willing to be RPs. Let’s use R1 and R4. For candidate RP, the priority is backwards from that of the BSR. With RP candidates, lower is better. Notice below, that the PIM Tunnels are built, indicating that R1 has been mapped as the RP by the BSR, and R1 learned about the mapping via PIM.

R1(config)#ipv6 pim bsr candidate rp 2002:1111::1 priority 2 %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
R1#

R1#show ipv6 pim tunnel
Tunnel0*
  Type  : PIM Encap
  RP    : Embedded RP Tunnel
  Source: 2002:12::1
Tunnel1*
  Type  : PIM Encap
  RP    : 2002:1111::1*
  Source: 2002:12::1
Tunnel2*
  Type  : PIM Decap
  RP    : 2002:1111::1*
  Source:  -

R1#show ipv6 pim bsr candidate-rp
PIMv2 C-RP information
    Candidate RP: 2002:1111::1 SM
      All Learnt Scoped Zones, Priority 2, Holdtime 150
      Advertisement interval 60 seconds
      Next advertisement in 00:00:38

Now lets assign R4 as a candidate RP. Notice no PIM tunnels are built, as the priority is not as good for R4, and it is not currently being used as an RP. If R1 fails, then R4 would be used.

R4(config)#ipv6 pim bsr candidate rp 2002:4444::4 priority 3

R4#show ipv6 pim bsr candidate-rp
PIMv2 C-RP information
    Candidate RP: 2002:4444::4 SM
      All Learnt Scoped Zones, Priority 3, Holdtime 150
      Advertisement interval 60 seconds
      Next advertisement in 00:00:21

Lets take a look at this from a couple different locations in the network. On the current BSR (R2), we can see all the candidate RPs.

R2#show ipv6 pim bsr rp-cache
PIMv2 BSR C-RP Cache

BSR Candidate RP Cache

Group(s) FF00::/8, RP count 2
 RP 2002:1111::1 SM
    Priority 2, Holdtime 150
    Uptime: 00:05:46, expires: 00:01:44
 RP 2002:4444::4 SM
    Priority 3, Holdtime 150
    Uptime: 00:05:32, expires: 00:01:58

From R6, who is not a BSR nor a RP candidate, we can see who the RP currently is. (Just to verify that the BSR is correctly advertising the mapping).

R6#show ipv6 pim group-map ff00::/8
IP PIM Group Mapping Table
(* indicates group mappings being used) 

FF00::/8*
 SM, RP: 2002:1111::1
    RPF: Fa0/1,FE80::211:11FF:FE11:1111
    Info source: BSR From: 2002:2222::2(00:02:00), Priority: 2
    Uptime: 00:07:45, Groups: 0
FF00::/8
    SM, RP: 2002:4444::4
    RPF: ,::
    Info source: BSR From: 2002:2222::2(00:02:00), Priority: 3
    Uptime: 00:07:31, Groups: 0
FF00::/8
    SM
    Info source: Default
    Uptime: 00:24:03, Groups: 0

To test this, we can have R3 join a group in the FF08::/8 range, and then simulate a mcast server, by pinging that group, (let’s do the ping from R2). If all goes well, the RP of R1 will be used to start the shared tree, and then a shortest path tree will be built between the listener (R3) and the content server (R2). The replies will be unicast from R3 to R2.

R3(config-if)#ipv6 mld join-group FF08:AAAA::1
R3#show ipv6 mld groups
MLD Connected Group Membership
Group Address                           Interface          Uptime    Expires
FF08:AAAA::1 Loopback0 00:00:26 never 

R2#ping ff08:aaaa::1
Output Interface: fastethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF08:AAAA::1, timeout is 2 seconds:
Packet sent with a source address of 2002:12::2

Reply to request 0 received from 2002:3333::3, 208 ms
Reply to request 1 received from 2002:3333::3, 188 ms
Reply to request 2 received from 2002:3333::3, 216 ms
Reply to request 3 received from 2002:3333::3, 224 ms
Reply to request 4 received from 2002:3333::3, 224 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 188/212/224 ms
5 multicast replies and 0 errors.

If we look at a device in the transit path, such as R5, we can verify the multicast routing information.

R5#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
       C - Connected, L - Local, I - Received Source Specific Host Report,
       P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
       J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State

(*, FF08:AAAA::1), 00:04:00/00:03:28, RP 2002:1111::1, flags: S
  Incoming interface: FastEthernet0/0
  RPF nbr: FE80::266:66FF:FE66:6666
  Immediate Outgoing interface list:
    FastEthernet0/1, Forward, 00:04:00/00:03:28

(2002:12::2, FF08:AAAA::1), 00:01:58/00:03:28, flags: ST
  Incoming interface: FastEthernet0/0
  RPF nbr: FE80::266:66FF:FE66:6666
  Immediate Outgoing interface list:
    FastEthernet0/1, Forward, 00:01:58/00:03:28

R5#show ipv6 mfib ff08:aaaa::1
IP Multicast Forwarding Information Base
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
             AR - Activity Required, K - Keepalive
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
Interface Flags: A - Accept, F - Forward, NS - Negate Signalling
             IC - Internal Copy, NP - Not platform switched
             SP - Signal Present
Interface Counts: FS Pkt Count/PS Pkt Count
(*,FF08:AAAA::1) Flags: C
   Forwarding: 1/0/100/0, Other: 0/0/0
   FastEthernet0/0 Flags: A
   FastEthernet0/1 Flags: F NS
     Pkts: 0/1
(2002:12::2,FF08:AAAA::1) Flags:
   Forwarding: 14/0/100/0, Other: 0/0/0
   FastEthernet0/0 Flags: A
   FastEthernet0/1 Flags: F NS
     Pkts: 0/14
R5#show ipv6 pim topology
IP PIM Multicast Topology Table
Entry state: (*/S,G)[RPT/SPT] Protocol Uptime Info
Entry flags: KAT - Keep Alive Timer, AA - Assume Alive, PA - Probe Alive,
    RA - Really Alive, LH - Last Hop, DSS - Don't Signal Sources,
    RR - Register Received, SR - Sending Registers, E - MSDP External,
    DCC - Don't Check Connected
Interface state: Name, Uptime, Fwd, Info
Interface flags: LI - Local Interest, LD - Local Disinterest,
    II - Internal Interest, ID - Internal Disinterest,
    LH - Last Hop, AS - Assert, AB - Admin Boundary

(*,FF08:AAAA::1)
SM UP: 00:06:21 JP: Join(00:00:28) Flags:
RP: 2002:1111::1
RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666
  FastEthernet0/1    00:06:21  fwd Join(00:03:06) 

(2002:12::2,FF08:AAAA::1)
SM SPT UP: 00:04:19 JP: Join(00:00:28) Flags:
RPF: FastEthernet0/0,FE80::266:66FF:FE66:6666
  FastEthernet0/1    00:04:19  fwd Join(00:03:06) 

R5#

Thanks for reading!

I will include embedded RP in a separate blog post for you.

Best wishes, and keep up the dedicated studies. It is worth it.

 


You can leave a response, or trackback from your own site.

4 Responses to “BSR IPv6 Multicast, are you a candidate?”

 
  1. Yasir Ashfaque says:

    Good work :) also discuss the Anycast IPV6 RP.

  2. [...] BSR IPv6 Multicast, are you a candidate? [...]

  3. Jacob says:

    Thanks for the lost reference, much appreciated :-)

 

Leave a Reply

Categories

CCIE Bloggers