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
  RP (?), v2
    Info source: (?), via bootstrap, priority 0, holdtime 202
         Uptime: 00:05:03, expires: 00:02:51
  PIMv2 Hash Value (mask
    RP, via bootstrap, priority 0, hash value 989207280
    RP, via bootstrap, priority 0, hash value 718054422

Rack1R4#show ip pim rp-hash
  RP (?), v2
    Info source: (?), via bootstrap, priority 0, holdtime 205
         Uptime: 00:05:07, expires: 00:02:55
  PIMv2 Hash Value (mask
    RP, via bootstrap, priority 0, hash value 1093093598
    RP, via bootstrap, priority 0, hash value 1364246456
About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website

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

14 Responses to “Understanding BSR Protocol”

  1. Nick says:

    Nice work. Thanks IE.

  2. Muhammad says:

    hey Petr, i how this hash value is calculated, i am a little confused in that? and why this hash value is used ?

    btw ur article’s are coool, love them..
    Thanks & Regards

    • The function is defined as follows:

      Value(G,Mask,RP(i))=(1103515245 * ((1103515245 * (G&Mask)+12345) XOR RP(i)) + 12345) mod 2^31

      and the output is value between 0 and 2^31. What is really important is that is it theoretically should provide fair distribution among the RPs.

  3. Naveen says:

    Thanks Petr. You clarified some of the least understood concepts like Multicast VLAN Registration, BGP Extension, DVMRP, SSM etc.

    Waiting for THE “BGP” thing. I have my lab date booked next week. If IE team can post by this weekend, it would be great.

    Thanks, Naveen.

  4. Naveen says:

    I tried the new v5 Multicast and wanted to update all regarding one issue with initial config.

    The port-channel members are shutdown in the initial config and hence the very first task would fail. Am not sure if this was intentional, but wanted to let people know.

  5. Hi, if you use BSR, would you still expect to see on your routers?

    Also, in this msg it says to use the same RP for every router for any given group. This would seem to be contrary then “auto RP,” in which the same group is fed by 2 different RPs.

    Thanks! Lisa G

  6. Moath Rawashdeh says:

    Hi everyone,

    So lets say we want to load balance the work among three different RPs, what would be the best hash value to use?

    I’ve noticed in task 8.19 WB I that we used a hash value 31 to load balance between two RPs. In the case of three, would the hash value be 30?

  7. Moath Rawashdeh says:

    “Every RP will get approximately 2^[32-hash-mask-length] groups assigned, provided that there is enough RPs to evenly distribute the load.”

    Let’s assume we chose a hash-mask-length of 31,
    2^(32-31) = 4. What does this number mean? Does mean that every RP will be assigned only 4 groups?

    am I on the right path here? :)


  8. wahlberg1979 says:

    Hi Petr,

    Do you know if on a router both auto-rp and bsr is configured, which protocol overrides the other ?

    I couldnt come across this answer on WWW.


  9. bluelotus101 says:

    Good..! Article cleared many of my doubts… but i m curious about how to calculate the said formula on Calculator of WinXP machine….? Has anyone tried…….

  10. Andrei says:

    @wahlberg1979: It looks like If we might have both enabled, we’ll have the group2RP mapping learned via both methods

    Rack1SW3#show ip pim rp map
    PIM Group-to-RP Mappings
    RP (?), v2v1
    Info source: (?), elected via Auto-RP, via bootstrap, priority 5, holdtime 16
    Uptime: 00:35:48, expires: 00:00:13

    NOTE: R5(cRP,MA)
    R4 and R5 cRP, SW1 cBSR


Leave a Reply


CCIE Bloggers