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 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.

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:

bsr bootstrap router topology

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 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.

Multicast PIM Bootstrap RP Announcement

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 is 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 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 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, we assign two multicast groups to each RP:

RP1:

  • 239.0.0.0
  • 239.0.0.1

RP2:

  • 239.0.0.2
  • 239.0.0.3

RP1:

  • 239.0.0.4
  • 239.0.0.5

RP2:

  • 239.0.0.6
  • 239.0.0.7

If you use a 30-bit hash mask, we assign four multicast groups to each RP:

RP1:

  • 239.0.0.0
  • 239.0.0.1
  • 239.0.0.2
  • 239.0.0.3

RP2:

  • 239.0.0.4
  • 239.0.0.5
  • 239.0.0.6
  • 239.0.0.7

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.

Configuration

You have now learned the basics of BSR. Let’s see it in action! I will use the following topology for this example:

multicast pim bsr topology




First, we enable multicast routing on all routers::

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now!

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 800 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)
529 Sign Ups in the last 30 days
satisfaction-guaranteed

  • 100% Satisfaction Guaranteed!
  • You may cancel your monthly membership at any time.
  • No Questions Asked!

Tags:


Forum Replies

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

  2. 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

  3. 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

  4. 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?

42 more replies! Ask a question or join the discussion by visiting our Community Forum