RP Discovery Methods
Load inter-as.multicast.rp.init.cfg
#IOS-XE
config replace flash:inter-as.multicast.rp.init.cfg
#IOS-XR
configure
load bootflash:inter-as.multicast.rp.init.cfg
commit replace
y
Routing for IPv4 unicast and BGP IPv4/Multicast is already setup. Configure RPs in each AS as follows:
XR1 should be RP using AutoRP
CSR10 should be RP using BSR
XR2 should be RP using BSR
CSR9 should be RP using static
Configure filtering on the inter-as links so that BSR and AutoRP information does not leak to other domains.
Answer
Explanation
You should be familiar with Auto-RP and BSR on IOS-XE devices. If not, INE’s RSv5 workbook has good exercises.
On IOS-XR, you specificy the BSR using the IP address, not the interface:
On IOS-XR, the Auto-RP configuration is roughly similar. The Auto-RP groups appear to already be in the “listening” mode by default. The XRv forwards this in dense mode without any extra configuration.
On the edge routers in the domains running BSR, we must use the bsr-border feature to filter BSR messages in/out of the interface.
To filter Auto-RP messages, we must filter the multicast traffic for the group itself. Auto-RP is not a control message as in BSR (which uses PIM). We can filter the contents of the Auto-RP message using ip multicast boundary filter-autorp ACL on IOS-XE, but this command does not allow us to filter the messages altogether. Instead, we must use a general multicast boundary filter and deny the Auto-RP groups.
Verification
Use the command show ip pim rp mapping on all routers to verify the correct RP is learned in each domain.
AS 7:
AS 8:
AS 9:
AS 11:
Within AS 7, verify that the two edge routers are not forwarding Auto-RP traffic out their inter-AS links.
Above, the AB flag means “administrative boundary.” The interface has forwarding disabled due to the IPv4 ACL we applied as a multicast boundary.
Last updated