So here's my scenario: I receive a bunch of different multicast feeds from seperate sources. This is all sparse-mode multicast and each group of feeds has its own RP address. To date, I've been managing the group-to-RP mappings using static ip pim rp-address commands, but as the number of feeds, sources, and internal routers grows, this is becoming unwieldy. I'd like to be able to map all of my groups at the edge to one RP for use internally, then have the edge router configured with the individual mappings, or at least distribute the RP mappings centrally so there's only one management point.
I've been reading about using AutoRP and BSR to distribute RP mappings throughout the network, but it seems like both of these require you to prop up one of your own routers as the RP:
AutoRP -- ip pim send-rp-announce <interface> group-list <acl>
BSR - ip pim rp-candidate <interface> group-list <acl>
ip pim rp-candidate Loopback0 group-list RP-GROUPS
RTRA correctly shows EDGERTR's loopback as the RP for a.a.a.a.
I've been able to get this working in a simple test environment using BSR, but I'm not confident in my lab setup because I can't seem to constrain the BSR messages in the "internal" part of the network (EDGERTR-RTRA). If I attempt to use ip pim bsr-border on the interface facing RTR1, it prevents data from flowing. I assume this is because the source is registering with the RTR1 RP, and the receiver is sending the join up the tree to the internal RP, but there's nothing to bridge that gap between the two RP's.
Are you familiar with Multicast Source Discovery Protocol (MSDP)? This protocol allows multiple RPs to exchange information about active sources. In your case, if your RTR1 RP becomes aware of the source to the group a.a.a.a, it will inform the EDGERTR RP so that it knows about the source and can send PIM Join towards it. I believe it would work even across BSR borders.
Read the following document about Anycast RP - your situation is quite similar.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...