Multicast PIM Bootstrap (BSR)

Lessons Discussion
44

Hello Istvan

Thanks for sharing that information with us, it is quite useful. I will let Rene know so he can consider if any changes or clarifications are necessary on the lesson.

Thanks again!

Laz

45

Hi @ReneMolenaar @lagapidis

What will take precedence if we enable both auto-RP and BSR in the network?

46

Hello Nipun

In a multicast network, if both Auto-RP and BSR are enabled, BSR will take precedence over Auto-RP. BSR is considered a more advanced and scalable solution for PIM-SM group-to-RP mapping compared to Auto-RP.

Remember that BSR is an open standard that is defined in RFC 5059 and is part of the PIM-SM standard, while Auto-RP is a Cisco proprietary mechanism. BSR is generally preferred in multi-vendor environments or in larger networks due to its better scalability and improved functionality.

However, it is generally not recommended to have both mechanisms enabled at the same time, as this may lead to inconsistencies in group-to-RP mappings and potential routing issues. It is better to choose one of the mechanisms and configure it consistently across the network.

I hope this has been helpful!

Laz

47

Thanks a lot.it helps

1 Like
48

Hi Rene, Team,

Need your help please as my company will deploy a huge project using mostly multicast traffic as the main load all throughout the network.
Just need your comment if when designing the core as BSR, will it automatically receive all the multicast routes from all the connected RPs to it? My main concern is it has limited capacity of handling multicast routes compare to the RPs that are really enough to handle thousands of mroutes. We just need to be careful on the choice of device since they are really pricey.

Thanks,
John

49

Hello John

If your main concern is the type of device that will play the role of the BSR, then you don’t have to worry too much. The primary role of the BSR is to share RP information throughout a PIM domain. Routers wanting to become the RP for a group will send their candidacy to the BSR. The BSR then creates a list of these RPs and sends this list to all PIM routers in the domain. The BSR itself does not keep track of multicast routes: its main function is RP discovery. Its job is not resource-intensive.

The RPs are more of a concern when it comes to the capacity to handle multicast routes. They should be capable enough to support the amount of traffic that you expect. They should be relatively centrally placed in the topology because initially, they do route the multicast traffic. Once that’s done, traffic can then switch over to the SPT for more efficient routing, which is standard sparse mode operation.

The project sounds very interesting and I’m sure it will be an excellent experience for you to further your understanding of these topics. Let us know how you get along, and if you have any other questions feel free to post them here!

I hope this has been helpful!

Laz

50

Hi Laz,

Thank you so much for your insight and technical comment on this! Really appreciate it! I’m about to test it as well on EVE-NG to see the actual action, we just had short time to prepare the devices needed.

Thank you,
John

51

Hello John

Testing such topologies on an emulator is an excellent way of preparing for the real thing. It will be vital to ensure a smooth migration. Let us know how you get along, and if we can be of any further help!

Laz

52

Hi,

I have a question about the hash. I can understand how adjusting the mask creates different hash results with the group address, and the shorter the mask the more multicast addresses can end up with the same hash result. But for the example in the notes, ultimately you just end up with the same number of groups mapped to each RP, its just how they are distributed that is different:

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

and

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

Both result in the same number of groups spread across RPs.

Another example, if you have 2 routers and set the hash mask to 1 or 32, it doesn’t matter because in both cases the groups will be spread across both routers (approximately) evenly, just in different ways.

The only thing it seems you have to watch out for is if you make the mask too short, then not all the routers will be used. e.g. you have 4 routers but a hash mask is only 1. all the groups will fall into one of two ‘winning’ hash values, and the same two routers.

Or am I misunderstanding how it all works?

Thanks.

Sam

53

Hello Sam

Your understanding is exactly correct. The purpose of the hash function is to properly “load balance” the multicast groups across existing RPs. Now the size of the mask simply distributes the groups differently.It doesn’t affect the proportional distribution of groups per RP. But you’re right, you just have to be careful to assign a proper size so that all of your RP routers will be used.

Now there is a subtle difference that does take place with different mask sizes, and its effects are typically seen only at scale. Take a look at this description of the behavior of the distribution when long masks and short masks are used:

Long Masks (30-32 bits):

  • Adjacent group addresses (like 239.0.0.1 and 239.0.0.2) will likely map to different RPs
  • Creates an alternating, statistically random-looking distribution
  • Best for general-purpose load sharing across many unrelated multicast streams

Short Masks (16-28 bits):

  • Large contiguous blocks of addresses map to the same RP
  • Example: With a /24 mask, ALL groups in 239.1.1.0/24 will map to the same single RP
  • Best for administrative control when you want related applications to share an RP

What you end up using depends on the distribution of the multicast groups that you use within your organization. These characteristics of group usage will affect which hash mask you will use:

  • Non-uniform group usage: Organizations typically use scattered, non-consecutive multicast addresses or small clusters (e.g., just a few groups from 239.10.5.0/24). Although load balancing across RPs is uniform, multicast group usage is not. In these cases, mask length significantly affects which RPs actually get used.
  • Administrative grouping: A short mask lets you align multicast address allocation with RP assignment. For example, assign 239.10.0.0/16 to video conferencing and use a /16 hash mask to ensure all video traffic predictably uses the same RP for troubleshooting, QoS policy, or capacity planning.
  • Stability during changes: When RPs are added or removed, shorter masks cause larger blocks of groups to remap together, while longer masks minimize the number of affected groups.

So the hash mask is a subtle parameter in the whole scheme of things. It will have little effect on small networks or on labs. However, on large-scale networks, where multicast group address allocation can be vast, the hash mask you use can significantly impact your network. Does that make sense?

I hope this has been helpful!

Laz

1 Like