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
What will take precedence if we enable both auto-RP and BSR in the network?
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
Thanks a lot.it helps
1 Like
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
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
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
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
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.1RP2:
239.0.0.2
239.0.0.3RP1:
239.0.0.4
239.0.0.5RP2:
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.3RP2:
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
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
How do you determine which routers become BSR candidates? Also can I make the rp router a BSR?
Hell Leo
Any PIM router can be manually configured as a Candidate-BSR (C-BSR), thereās no automatic nomination process or mechanism. On Cisco IOS, you simply use:
ip pim bsr-candidate <interface> [hash-mask-length] [priority]
This is purely an administrative choice, not something determined dynamically. Once you have multiple C-BSRs configured, then the election happens automatically and dynamically as described in the lesson (via the highest priority and the highest IP address).
Yes, absolutely. A single router can simultaneously be configured as both a Candidate-RP (C-RP) and a Candidate-BSR (C-BSR), and if elected, it will function as both the active RP and the active BSR at the same time.
The two roles are completely independent in the PIM Bootstrap specification (RFC 5059). Each configuration simply activates a separate state machine on the router. Thereās nothing in the protocol that prevents both from running on the same device.
In labs, it is perfectly fine to do this, but in production networks, it is preferable to spread the RP and BSR roles across different routers for redundancy. If a single combined router fails, both BSR and RP are lost. But this is a design best practice, not a limitation of the protocolā¦
I hope this has been helpful!
Laz
Is there a difference in configuring the BSR on nexus 9k than IOS? I am stuck in this anycast rp lab where I am trying to announce my rp using BSR.
Hello Leo
Yes, there are a couple of differences on Nexus 9K/NX-OS compared to the IOS configuration used in the lesson.
The main one to check is the candidate-RP configuration. On IOS, the lesson can simply use:
ip pim rp-candidate Loopback0
On NX-OS, you normally specify the multicast group range explicitly, for example:
ip pim rp-candidate loopback0 group-list 224.0.0.0/4
Also make sure the Nexus devices that need to propagate the BSR information have:
ip pim bsr forward listen
Ciscoās NX-OS BSR example specifically includes both of these commands.
I would start there and then check show ip pim bsr and show ip pim rp to see whether the BSR is being learned and whether the candidate RP is actually being advertised.
Let us know how you get along!
I hope this has been helpful!
Laz
Thanks Laz, and to take this a step forward I tried to use BSR to distribute anycast RP information. Is it ok to use BSR and Anycast RP configuration together?
Also the lesson has a footnote that says NX-OS can do anycast RP without MSDP. Is that just for Vxlan or in general?
Hello Leo
The short answer is yes, BSR and Anycast RP are compatible and theyāre actually designed to work together. This is because they solve two different problems:
- Anycast RP is a redundancy mechanism where multiple routers share one common RP IP address, so sources and receivers reach the topologically nearest RP based on the routing metric. The RP set members synchronize active-source state using MSDP (or PIM-based register forwarding per RFC 4610).
- BSR is a mechanism to distribute RP-to-group mappings to all PIM routers in your domain dynamically.
BSR doesnāt care what IP address you advertise as the RP. It just floods that mapping to every router. If you advertise your anycast loopback address (shared by multiple RP routers) as the Candidate-RP, BSR distributes that anycast address just as easily as it would a single RP address.
The short answer is anycast RP without MSDP is a general NX-OS multicast capability. Itās not VXLAN-specific. It works for any PIM-SM multicast setup on Nexus switches.
The feature appears in the VXLAN lesson because it demonstrates the feature in a spine-leaf topology. This is a common and practical use case for RP redundancy in modern data centers. But the underlying PIM mechanism works the same way in any multicast network, not just with VXLAN.
I hope this has been helpful!
Laz