Bootstrap router or BSR is standard-based protocol available with PIMv2. The protocol performs the same function as Cisco’s proprietary Auto-RP, i.e. disseminates RP information. Both protocols use the concept of candidate RP, i.e the router that is announcing itself as a potential RP. Unlike Auto-RP, BSR does not use any dense-mode groups to flood candidate RP and RP mapping information. Instead, the information is flooded using PIM messages, on hop-by-hop basis. The flooding procedure utilizes reverse path forwarding: when a router receives a BSR message, it applies RPF check, based on the source IP address in the packet. If the RPF check succeeds, the message is flooded out of all PIM-enabled interfaces until all routers in the domain learn the information.

Let’s briefly discuss BSR functions. BSRs listen and accumulate candidate RP announcements, performing the role similar to Auto-RP MA. However, unlike Auto-RP MA, the BSR does not elect the best RP for every group range it learns about. Instead of this, for every group range known, the BSR builds a set of candidate RPs, including all routers that advertised their willingness to service this range. This is called “group range to RP set mapping”. The resulting array of group range to RP set mappings is distributed by the BSR using PIM messages and the same flooding procedure described above. PIM BSR operates in two phases:

Phase 1: BSR discovery. Every router configured as BSR floods bootstrap messages and listens to other BSR candidates. The BSR that hears another BSR with a higher priority gives up its role of the BSR. Eventually there is only one BSR, and every router in the domain, including the candidate RPs learn about it.
Phase 2: RP discovery. Every RP unicasts its own address and the configured group ranges to the BSR. Eventually, BSR learns of every RP and continuously keeps flooding the new information through the domain.

To set up a candidate RP in Cisco IOS, use the command ip pim rp-candidate < PIM-Enabled-Interface > [group-list ] [interval ] [priority <0-255>] . If you omit all optional arguments, the router will start advertising itself as the RP for all groups. You may specify the list of groups using the group-list argument. All entries in this list are “positive”, if you compare them to Auto-RP functionality. You cannot use “negative” groups, singnaling dense-mode forwarding. RP priority value is used only when the routers select the best RP for a given group, and lower values are preferred. The default RP priority is zero (which is against standard, which specifies 192) and is the highest possible value. You may rarely want to change the priority value for a candidate RP, possibly only in cases when you want to gracefully take the RP out of service.

The command to set up a BSR in Cisco IOS is ip pim bsr-candidate < Interface-Name > [hash-mask-length] [priority]. Ignore the hash-mask-length parameter for a moment, and notice the priority field. This field is used to elect a single BSR that broadcast mapping information in the domain. If a BSR hears a message with higher priority or IP address, it immediately stops its own BSR advertisements. By default, the priority of zero is advertised in all BSR messages and the IP address of the interface used to source the BSR messages is used as a tie-breaker - the higher IP is preferred. If there are multiple BSRs, they constantly listen to other BSR messages flooded through the domain and stop sending their own information if they detect a better BSR candidate. This electiong process ensures BSR uniqueness in the domain while maintaining redundancy in case if the primary BSR fails.

Ultimately, the bootstrap messages containing Group to RP-set mappings are received by every multicast router in the domain and used to populate their RP caches. It's up to the routers to select the best matching RP from the sets advertised by the BSR router. It is important that all routers select the same RP for the same group, otherwise the multicast sources might miss receivers. In order to make full use of Group to RP-set information routers might want to select different RPs for different groups. As mentioned previously, the load balancing procedure must yield the same result on all routers, to maintain synchronous mapping. Here is how this distribution procedure works, in pseudo-code.

Input: Group Address (G), RP-Set (R1, R2… Rn), Mask. This information is used as the input to the hash funcation. R1, R2.. Rn are IP addresses of the RPs mapped to the Group address G. The Mask is calculated based on the mask-length distributed by the BSR.

1) Among the routers in RP-Set, select those that have numerically lowest priority values. By default all cRPs advertise priority of zero, so they all are eligible.

2) For every RP IP address, calculate the hash function value:

value1 = Hash(G&Mask, R1),
value2 = Hash(G&Mask, R2) …
valueN = Hash(G&Mask,Rn).

Notice that Group IP address is ANDed with the Mask value. Thus, only first hash-mask-length bits of the Group IP address are used to calculate the hash value. Using the “pseudo-random” selection procedure, the whole multicast address space is partitioned among different RPs. Every RP will get approximately 2^[32-hash-mask-length] groups assigned, provided that there is enough RPs to evenly distribute the load. Notice that the default mask length value is zero - i.e. the group IP address is ignored when computing the hash value and all groups map to the same RP.

Now, for the practical part. You may quickly find which RP would be selected for a given group using the show ip pim rp-hash command. For example:

Rack1R4#show ip pim rp-hash 239.1.1.1

  RP 150.1.10.10 (?), v2

    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 202

         Uptime: 00:05:03, expires: 00:02:51

  PIMv2 Hash Value (mask 255.255.255.254)

    RP 150.1.10.10, via bootstrap, priority 0, hash value 989207280

    RP 150.1.8.8, via bootstrap, priority 0, hash value 718054422
Rack1R4#show ip pim rp-hash 239.1.1.2

  RP 150.1.8.8 (?), v2

    Info source: 150.1.5.5 (?), via bootstrap, priority 0, holdtime 205

         Uptime: 00:05:07, expires: 00:02:55

  PIMv2 Hash Value (mask 255.255.255.254)

    RP 150.1.10.10, via bootstrap, priority 0, hash value 1093093598

    RP 150.1.8.8, via bootstrap, priority 0, hash value 1364246456