Multicast PIM Bootstrap (BSR)

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 it throughout the network. Its function is similar to the mapping agent in AutoRP.
• Candidate RP: these are routers that are advertising themselves who want to become the RP.

Candidate BSR

The BSR sends messages on a hop-by-hop basis and does so by sending its packets to multicast address 224.0.0.13 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.

Candidate RP

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 address of the BSR from the BSR message 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 (3.3.3.3).

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.

RP Selection

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:

1. We look for the longest match on a multicast group. For example, let’s say we want to join multicast group 239.1.1.1. One RP advertises itself that it serves the 239.0.0.0/8 group range and another RP wants to serve the 239.1.1.0/24 range. In this case, we will prefer the second RP since 239.1.1.0/24 is the longest match.
2. 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.
3. 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.
4. If the groups, priority, and hash value of all RPs are the same then the RP with the highest IP address will be preferred.

Hash Function

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; its length is 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.

On Cisco IOS, 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 consecutive groups always map to the same 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 each block of two consecutive multicast groups will always be mapped to the same 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 each block of four consecutive multicast groups will always be mapped to the same RP.

Let me give you an example:

We have two RPs with the same priority, both want to become the RP for the entire 239.0.0.0/8 multicast range. We have multicast listeners who want to receive traffic for the following multicast groups:

• 239.0.0.0
• 239.0.0.1
• 239.0.0.2
• 239.0.0.3
• 239.0.0.4
• 239.0.0.5
• 239.0.0.6
• 239.0.0.7

Without a hash mask, all eight multicast groups will be assigned to one RP.

With a 31-bit hash mask, the groups are hashed in blocks of two. Each block goes to one RP; which RP gets which block depends on the hash, so the split is not necessarily even. For example, with RPs 1.1.1.1 (R1) and 4.4.4.4 (R4), which we’ll use later in this lesson:

• 239.0.0.0 – 239.0.0.1: R4
• 239.0.0.2 – 239.0.0.3: R4
• 239.0.0.4 – 239.0.0.5: R1
• 239.0.0.6 – 239.0.0.7: R4

If you use a 30-bit hash mask, the groups are hashed in blocks of four. With the same RPs, both blocks of 239.1.1.0 – 239.1.1.7 end up on R1:

• 239.1.1.0 – 239.1.1.3: R1
• 239.1.1.4 – 239.1.1.7: R1

This is a nice way to configure load balancing between RPs. The hash mask that you choose decides how many consecutive groups always share the same RP. It spreads the groups over the RPs, but the split is not guaranteed to be even.

Configuration

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: