BSR (Bootstrap) is similar to Cisco’s AutoRP, it’s a protocol that we use to automatically find the RP (Rendezvous Point) in our multicast network. BSR however, is a standard and included in PIMv2, unlike AutoRP which is a Cisco proprietary protocol.
BSR uses two roles:
- Candidate BSR: this is the router that collects information from all available RPs in the network and advertises is throughout the network. It’s function is similar to the mapping agent in AutoRP.
- Candidate RP: these are routers that are advertising themselves who want to become the RP.
The BSR sends messages on a hop-by-hop basis and does so by sending its packets to multicast address 22.214.171.124 with a TTL of 1. These multicast packets have a local scope thanks to their TTL so they are not routed.When a multicast router receives the message, it will do an RPF check on the source address of the BSR and will re-send the message on all other PIM-enabled interfaces. This is a big difference with the mapping agent of AutoRP which uses multicast where we require dense mode flooding to flood the packets of the mapping agent throughout the network.
The BSR messages will contain information about the BSR and of course the RP-to-group mappings.
Here is an illustration of this process:
Above we have a small network with six routers. R3 is the BSR and sending BSR messages on its interfaces. All other routers will re-send these messages which allows the entire network to learn the information in the BSR messages.
There can be only one active BSR in the network. BSR routers will listen for messages from other BSR routers, the BSR router with the highest priority will become the active BSR. The highest BSR priority is 255 (the higher the better). When the priority is the same then the router with the highest IP address will become the BSR.
Routers that want to become an RP are called candidate RPs and they have to announce themselves to the BSR. When a candidate RP receives a BSR message, it will learn the source address of the BSR and it will register itself using unicast packets. This is another difference with AutoRP where the candidate RPs announce themselves using multicast packets.
Above you can see two routers, R2 and R6 who would like to become the RP. They are sending their RP announcement packets to the unicast IP address of the BSR (126.96.36.199).
Once the BSR receives the RP announcements, it will build a list of all RPs and the multicast groups they want to serve. This is called the group-to-RP mapping set.
The BSR will then include this list in its BSR messages so that all multicast routers receive it. One big difference with the mapping agent of AutoRP is that the BSR router does not select the RP to use. It will advertise all RPs with the multicast groups that they want to serve, it’s up to the multicast router to select the RP it wants to use.
The multicast routers will receive multiple group-to-rp mapping sets from the BSR and they’ll have to select the best RP from this list. When you have multiple RPs then it’s very likely that you have multiple RPs that want to serve the same multicast groups. Here’s how we select the RP:
- We look for the longest match on a multicast group. For example, let’s say we want to join multicast group 188.8.131.52. One RP advertises itself that it serves the 184.108.40.206/8 group range and another RP wants to serve the 220.127.116.11/24 range. In this case, we will prefer the second RP since 18.104.22.168/24 is the longest match.
- When two RPs advertise the exact same groups then we will prefer the RP with the highest priority. Unlike the BSR selection, highest priority for RP selection means the lowest priority value (0 is the highest priority). The priority is a value we can configure on the RP.
- If the groups and priority on the RP are the same then we will look at the highest hash value from a hash function to decide what the best RP is. I’ll explain the hash function in a bit.
- If the groups, priority, and hash value of all RPs is the same then the RP with the highest IP address will be preferred.
The hash function is used by all multicast routers to map multicast group addresses to different RPs.
for the sake of completeness, this is what the hash function looks like:
Value(G,M,C(i))= (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31
The input for this function is:
- G: the multicast group address.
- M: a hash mask value.
- C: the IP address of the RP.
Don’t get scared by the formula above, the router will do the calculations for you 🙂
The hash mask is a 32-bit value and advertised in the BSR messages. The router takes these values, puts them in the hash function and returns a hash value. The RP with the highest hash value will be selected.
By default, the hash mask value is 0 which means that the hash value is only calculated based on the IP address of the RP.
Things become interesting when we change the hash mask. The remaining bits in the hash mask decide how many groups we map to an RP.
The hash mask is a 32-bit value so if you use a 31-bit mask, we only have one bit left. With a single bit, we can create two values which means that two multicast groups will be mapped to one RP.
If you use a 30-bit hash mask, we have two bits left. With two bits, we can create four values which means that four multicast groups will be mapped to one RP.
Let me give you an example:
We have two RPs with the same priority, both want to become the RP for the entire 22.214.171.124/8 multicast range. We have multicast listeners who want to receive traffic for the following multicast groups:
Without a hash mask, all eight multicast groups will be assigned to one RP.
With a 31-bit hash mask, we assign two multicast groups to each RP:
If you use a 30-bit hash mask, we assign four multicast groups to each RP:
This is a nice way to configure load balancing between RPs. The hash mask that you choose decides how many groups you map to one RP.
You have now learned the basics of BSR. Let’s see it in action! I will use the following topology for this example:
First, we enable multicast routing on all routers::
Why is hop-by-hop messaging different from dense mode flooding ?
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.
Super lesson. Just noticed the first picture as the wrong pim multicast adress 126.96.36.199 instead of 188.8.131.52.
Thanks Maikel, just fixed it.
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?