PIM and filtering candidate PIM RP messages (BSR)

[MarcSims]

Hi,

I have a large existing PIM domain. This is based on PIM Sparse-mode, with several appropriately scoped PIM RP's, using BSR - lets call this "Domain 1). Another part of the network (previously under different admin) also configured PIM Sparse-Mode, but creating a single RP for 224.0.0.0/8 - "Domain 2". Both domains have lots of sources spread over lots of different multicast addresses - so no easy way to re-scope so that they can just merge.

I need sources on "Domain 1" to be able to join multicast groups on "Domain 2" - fortunately the few addresses that the users in Domain 1 need to join that are sourced in domain 2 are on multicast addresses that are not currently in use in domain 1 - so no problem there!

Obviously I need to find a way for the join to propagate from domain 1 to domain 2. I've searched to see if there is a way to advertise a istatic PIM-RP into the BSR announcement (as there are too many routers to be able to support adding static PIM RP config to all devices - but this doesn't seem to be an option.

I've also searched for a PIM to IGMP proxy - so that the joins and leaves between the two domains could be managed without a PIM neighbourship - but again no joy.

Finally, I have tried configuring a PIM rp-announce-filter for the PIM RP from domain 2, only accepting the PIM groups that I am interested in - but when I check the PIM RP mapping, the 224.0.0.0/8 announcement is still getting through.

Any ideas on how to either (1) propogate a multicast join from 1 PIM domain to another without a PIM neighbourship (or with a PIM boundary) - PIM BSR boundary worked when I tested it - but this then fell into the category of needing to configure every router with a static PIM RP mapping - as no way (that I can see) to ingest a static mapping into BSR). Approach 2 that I could think of was to fully establish PIM & BSR but to filter what gets through to the elected BSR's - so domain 1 only learns the required subset of PIM RP's from Domain 2 - filtering out the 224.0.0.0/8 RP announcement.

I do appreciate that the longer match PIM RP announcements that already exist in domain 1 will take precedence over the less specific 224.0.0.0/8 RP announcement - but I can't introduce a catch-all RP like that to the domain - simply not an option.

Filter attempted config on elected PIM BSR:

LAB-SWITCH#show ip access-lists GROUP-LIST
Standard IP access list GROUP-LIST
10 permit 239.1.1.0, wildcard bits 0.0.0.255

Standard IP access list RP-LIST
10 permit 10.20.10.30

LAB-SWITCH#sh ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
This system is the Bootstrap Router (v2)

Group(s) 224.0.0.0/4
RP 10.20.10.30 (LAB-SWITCH2), v2
Info source: 10.20.20.10 (LAB-SWITCH), via bootstrap, priority 0, holdtime 150
Uptime: 00:12:25, expires: 00:02:00
LAB-SWITCH#

ip pim rp-announce-filter rp-list RP-LIST group-list GROUP-LIST

Any ideas or experience appreciated!

[Giuseppe Larosa]

Hello @MarcSims ,

you can treat the two domains as separate by using :

a) MSDP between all RPs in domain 1 and MSDP with RP with domain -2 it should peer at least with two RPs in domain 1.

b) you can filter bsr at border links with ip pim bsr-border

see

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti/command/imc-cr-book/imc_i3.html#wp3437291643

c) you still run ip pim sparse mode at border links

in this way you keep two separate BSR domains . The MSDP sessions between RPs will make possible to use sources that are in the other domain.

Edit:

the command you have tried to use it looks like to apply to auto RP scenarios

>> Use the ip pim rp-announce-filter command to filter incoming Auto-RP announcement messages sent from C-RPs to RP mapping agents.

>>>> This command should only be configured on RP mapping agents.

Hope to help

Giuseppe

[MarcSims]

Giuseppe,

Thanks very much - I spent so much time trying to find a solution I forgot that the filter I was testing was only for AutoRP - I did remember that it needed to be on the RP mapping agent - but was applying it to the elected BSR device - obviously not a winner.

Sorry for the delayed response, but I wanted to hold off replying until I had tested & implemented the solution - which I have just done!

I had seen MSDP but to be honest I hoped there would be a simpler solution so didn't really explore it fully until you replied. After reading through your suggestion I looked into it and decided to implement a Anycast solution, utilising MSDP. In lab testing this appeared to work well - with only the RP that was on the other side of the boundary being replicated to the other RP on the other side - it was a good solution - so thanks..

When I came to implement this today though, I stumbled across a way to create a static PIM RP mapping that could be ingested into the BSR - and with the PIM connectivity established with full IP routing between domains, this gave a way to utilise the BSR border, and still advertise the RP to all devices by BSR. To do this, I created a loopback interface on a switch in Domain 1 with the same IP address as the actual RP in Domain 2 (as per Anycast approach) - however the next thing I was going to do was advertise this into the internal routing protocol to complete the Anycast setup - with clients in Domain 1 then finding the route to the new RP, and clients in domain 2 still finding the route to the old RP - but I realised that as soon as the RP was created against the loopback with the same RP as domain 2 this IP was advertised by the BSR - and with the newly created loopback not being advertised into the routing of domain 1, all client requests follow the route to the existing RP in Domain 2 - across the interdomain (PIM enabled / BSR border) link. Obviously the device with the fake loopback is out of the way of the multicast requests and traffic for this group - as if it were in path, it would still route to the loopback as it is locally connected - but with it not in the path this is perfect - and avoids having to use MSDP and associated complications.

So basically, I stumbled across a way to inject a PIM RP announcement for a RP in a different multicast domain into the BSR announcements - providing simple inter-domain multicast connectivity when combined with the bsr-border.

Thanks again though for the MSDP steer - this was an absolute winner and would definitely have worked - probably in a more conventional and supportable way!

Thanks - really appreciate your help.