IOS and IOS XR Multicast VPN with the Rosen Model Default MDT with Boot Strap Router or BSR

BSR or Bootstrap Router is the open standard, RFC 5059, for distributing RP info through out the multicast PIM enabled network. BSR messages are sent inside of PIM ver2 messages where ever PIM is enabled and flowing. PIM builds the connections per router to allow routed multicast to flow. We've already taken a look at static RP which needs to be configured on every router that will participate in multicast forwarding. This requirement makes Static RP challenging to configure. The nice thing about SP mVPN providing transport for Customer multicast is that the RP distribution method chosen by the provider is independent of the customer. The provider may choose Auto-RP and the customer could choose BSR or vice-versa. In this post we will use BSR for both the customer and provider multicast networks. For ease of migration from Static RP to BSR I have configured BSR to use the same loopback interfaces that Static RP previously used. R1's loopback 0 and R5's loopback 0 interfaces.

BSR and Auto-RP operate differently that Static RP, both support the RP information distributor and the RP assigner. These are terms I made up, the "ip pim bsr-candidate loopback 0" is the information distributor and the "ip pim rp-candidate loopback 0" is used to define the RP itself. This would mean that many different routers could be the RP. Typically an RP filter is used, where one RP would service the first half of the 224/4 range and the other the back half. We won't be testing that out in this post. The BSR candidate and RP candidate can both be the same router, which in our case is what I configured.

R5 - Customer RP
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0


R1 - Service Provider RP
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0


Not configured in our topology or scenario but worth mentioning:
IOS XR BSR Configuration
router pim
 address-family ipv4
  bsr candidate-bsr 172.16.100.19 hash-mask-len 30 priority 1
  bsr candidate-rp 172.16.100.19 priority 192 interval 60


R4 - PE Router servicing R7 and R8
R4#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 172.16.100.1 (?), v2
    Info source: 172.16.100.1 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:30:52, expires: 00:01:39


XR9 - PE Router servicing R14
RP/0/0/CPU0:XR9#sh pim rp mapping
Mon Mar  5 09:31:40.742 UTC
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
  RP 172.16.100.1 (?), v2
    Info source: 10.11.19.11 (?), elected via bsr, priority 0, holdtime 150
      Uptime: 00:31:39, expires: 00:01:56


Customer multicast receiver
R12#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 172.16.100.5 (?), v2
    Info source: 172.16.100.5 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:31:41, expires: 00:02:01

Now that we have configured BSR and verified that the RP information has been distributed, we will now test multicast.

R5#ping 224.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Reply to request 0 from 10.10.11.11, 59 ms
Reply to request 0 from 10.18.13.13, 321 ms
Reply to request 0 from 10.14.19.14, 257 ms
Reply to request 0 from 10.4.7.7, 193 ms
Reply to request 0 from 172.16.100.120, 130 ms
Reply to request 0 from 10.12.9.12, 118 ms
Reply to request 0 from 10.4.8.8, 79 ms

We can see that it does work using the BSR configuration.