Multicast PIM Bootstrap (BSR)

This topic is to discuss the following lesson:

Why is hop-by-hop messaging different from dense mode flooding ?

Hi Suman,

With dense mode flooding, the router will flood the original IP multicast packet that it receives on one interface on other PIM enabled interfaces.

The hop-by-hop behavior of BSR is a bit similar but these packets have a TTL of 1. When the router receives these packets, it replicates the receiving packet and sends a new packet (with the same information) on its PIM enabled interfaces.

Rene

Hi Rene,

Super lesson. Just noticed the first picture as the wrong pim multicast adress 224.0.1.13 instead of 224.0.0.13.

Maikel

Thanks Maikel, just fixed it.

Hi Rene,

I have another question for you. I notice that each time BSR candidate configuration is created, a new tunnel is created? Can you please elaborate?

Hi Nagender,

These tunnel interfaces are used to communicate with the RP. You can see some examples here:

IP PIM Sparse Mode

Rene

1 Like

Got a question about the hash mask - wouldn’t it always be best to use a 31 bit hash mask?

That way one group will be assigned per RP, then it “rolls over” back to the first RP etc.

Hi Chris,

If you set it to /32, you will have one group per RPR. If you use /31, each RP will have two groups.

Rene

Hi Rene,

I have one question. Can we implement both RP & BSR on the same router? Also, can we do the same thing with Cisco Auto-RP (RP & Mapping Agent on the same router)?

Thank you,
Minh

Hello Minh,

You can enable Auto-RP & BSR (and static RP) on the same router yes. Here’s a quick example:

R1#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 2.2.2.2 (?), v2v1
    Info source: 2.2.2.2 (?), elected via Auto-RP
         Uptime: 00:00:23, expires: 00:02:32
  RP 4.4.4.4 (?), v2
    Info source: 4.4.4.4 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:02:11, expires: 00:02:11

R2 advertises itself as an RP with Auto-RP, R4 with BSR. R1 seems to prefer Auto-RP.

Interesting to know is that with RP selection, the router prefers RPs that were learned through Auto-RP or BSR over static RPs!

There’s not really a reason to use both Auto-RP and BSR but technically, you could use AutoRP to serve a set of multicast groups and BSR another set of multicast groups.

Running the Auto RP and mapping agent on the same router is no problem, on small networks (and labs) I usually do this.

Rene

1 Like

Hi Rene,

The lab that I have created seems to conflict with the second determining factor you have listed, used to select the RP for a particular group. The RP with the lowest priority (default 0) wins the election.

R4#sho ip pim rp-hash 224.0.0.0
  RP 150.1.10.10 (?), v2
    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:05:53, expires: 00:01:38
  PIMv2 Hash Value (mask 0.0.0.0)
    RP 150.1.10.10, via bootstrap, priority 0, hash value 884179440
    RP 150.1.8.8, via bootstrap, priority 0, hash value 613026582

R4#sho ip pim rp-hash 224.0.0.0
  RP 150.1.8.8 (?), v2
    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:22:06, expires: 00:02:23
  PIMv2 Hash Value (mask 0.0.0.0)
    RP 150.1.8.8, via bootstrap, priority 0, hash value 613026582
    RP 150.1.10.10, via bootstrap, priority 10, hash value 884179440
1 Like

Hi Michael,

that confused me too, so i read RFC5059 stating:
“BSR Priority
Contains the BSR priority value of the included BSR. This field
is considered as a high-order byte when comparing BSR addresses.
BSRs should by default set this field to 64. Note that for
historical reasons, the highest BSR priority is 255 (the higher
the better), whereas the highest RP Priority (see below) is 0
(the lower the better).”

Summary:
- BSR election: higher priority wins
- RP election: lower priority wins!

Hello Michael

When an election for RP takes place in a particular group, the priority values exchanged are indeed used as part of the process determine the RP. Once the election is complete, even if you change the priority values, a re-election will not take place. A re-election will only take place if the RP has been detected to have gone down, after the appropriate timers expire. In order to achieve a reelection in your topology, disable the current RP router (reboot or turn off for an extended period of time) and the reelection process will eventually kick in, using the currently configured parameters.

More info about the election and reelection process can be found at RFC 5059.

I hope this has been helpful!

Laz

Thanks for explanation …I see just typo error R1 ( instead of R2) while configuring rp-candidate

simply outstanding
Thanks

1 Like

Hi Rene,

I have a doubt. Here R4 also gets BSR messages from BSR. But sparse mode is enabled on all routers. Then how R4 gets BSR message from R3?

Or is that what hop-by-hop basis means? In case of BSR selection, messages will be send to all the routers?

Hello Siji

Sparse mode allows all multicast traffic to first go to the RP and then be sent to the clients that requested it. However, with BSR, we don’t yet have an RP, so sparse mode is not yet enabled. Secondly, the specific BSR message is sent with a TTL of 1 so it is already limited in scope to only next hop routers. That’s what hop-by-hop refers to. Each router then regenerates the BSR out of all PIM enabled interfaces.

I hope this has been helpful!

Laz

Thanks for the info. Got it clear.

1 Like

The first line is R2 and the remaining lines are R1.
Should all be R2

R2(config)#interface Loopback 0
R1(config-if)#ip address 2.2.2.2 255.255.255.255
R1(config-if)#ip pim sparse-mode

R1(config)#router ospf 1
R1(config-router)#network 2.2.2.2 0.0.0.0 area 0

Now we can use the BSR command:

R1(config)#ip pim bsr-candidate loopback 0 ?
Hash Mask length for RP selection