IOS and IOS XR Multicast VPN with the Rosen Model Default MDT with BSR and AutoRP

Auto RP is the Cisco proprietary RP distribution mechanism. It uses the same logic as BSR, or I should say, BSR uses the same logic as Auto RP. Auto RP leverages the mapping agent and the rp candidate options like BSR. IOS XR support it as well. I have configured R1 as the Auto RP mapping agent and RP candidate and XR9 as another RP candidate. Since we are not running PIM dense mode anywhere we need to add a command "ip pim autorp listener".

Candidate RPs (C-RP):

• Routers willing to be the RP
• Announce themselves to the MA via 224.0.1.39

Mapping Agent (MA):

• Decide who will be the RP from the Candidates RP
• Will inform the rest of the network about the elected RP via 224.0.1.40

I configured Auto RP in the SP core and left BSR configured in the customer network.

R1 is a Mapping agent and a RP candidate. XR9 is a RP candidate. 

R1

ip pim autorp listener

ip pim send-rp-announce Loopback0 scope 255

ip pim send-rp-discovery Loopback0 scope 255

XR9

router pim

 address-family ipv4

 auto-rp candidate-rp Loopback0 scope 255 group-list 224-4 interval 60

Now we can check on R3 to see what the rp mappings info has to say.

R3#sh ip pim rp mapping 

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

  RP 172.16.100.19 (?), v2

    Info source: 172.16.100.1 (?), elected via Auto-RP

         Uptime: 01:36:48, expires: 00:02:35

RP/0/0/CPU0:XR8#sh pim rp mapping 

Mon Mar  5 11:28:24.979 UTC

PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4

  RP 172.16.100.19 (?), v2

    Info source: 172.16.100.1 (?), elected via autorp

      Uptime: 00:47:56, expires: 00:02:40

Group(s) 224.0.0.0/4

  RP 172.16.100.1 (?), v2

    Info source: 0.0.0.0 (?), elected via config

      Uptime: 14:53:30, expires: never

XR9 is the RP for the SP core. XR9 communicated with R1 to let R1 know XR9 is an RP candidate. R1 is the distributor of information in the SP core. 

So now we'll check on R12 to see what it sees an as RP for the customer network.

R12#sh ip pim rp map

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: 02:19:19, expires: 00:01:41

We see that R12 sees R5 as the BSR and RP candidate. Let's make sure that reachability is still there.

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.4.8.8, 51 ms

Reply to request 0 from 10.18.13.13, 374 ms

Reply to request 0 from 10.14.19.14, 227 ms

Reply to request 0 from 10.10.11.11, 195 ms

Reply to request 0 from 10.4.7.7, 138 ms

Reply to request 0 from 172.16.100.120, 127 ms

Reply to request 0 from 10.12.9.12, 119 ms

We see that when R5 pings the multicast group 224.1.1.1 that all the customer routers respond, these are the customer include those connected to XR 5.3 PEs, not XR 6.0