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