PIM-BiDir with Phantom RP

Load multicast.init.cfg

#IOS-XE
config replace flash:multicast.init.cfg
 
#IOS-XR
configure
load bootflash:multicast.init.cfg
commit replace
y

Configure R9 and XR14 as the RPs for all IPv4 and IPv6 groups using BiDir. R9 should be primary and XR14 should be secondary. Define the RP statically on all routers.

Answer

#R5-R10
ip pim bidir-enable
ip pim rp-address 1.0.0.129 bidir
ipv6 pim rp-address 2001::f0 bidir

#XR1-4
router pim
 add ipv4
  rp-address 1.0.0.129 bidir
 add ipv6
  rp-address 2001::f0 bidir

#XR4
int lo100
 ip add 1.0.0.130/29
 ipv6 add 2001::F1/126
!
router ospf 1
 area 0
  int lo100
   loopback stub-network enable
!
router ospfv3 1
 area 0
  int lo100
   network point-to-point
!
multicast-routing
 add ipv4
  int lo100 en
 add ipv6
  int lo100 en

#R9
int Lo100
 ip address 1.0.0.130 255.255.255.252
 ip ospf 1 area 0
 ip ospf net point-to-point
 ip pim sparse-mode
 ipv6 add 2001::F1/127
 ospfv3 1 ipv6 area 0
 ospfv3 1 net point-to-point

Explanation

In PIM-BiDir, the RP does not have an active role to play in the control plane. In PIM-SM, the RP must accept PIM Registers, decapsulate them, send the traffic down the shared tree, and join a (S, G) rooted at the sender. However, in PIM-SSM, the RP simply accepts incoming traffic and forwards it out interfaces in the OIL in a corresponding (*, G) entry.

For this reason, the BiDir RP address must point “towards” an RP but the literal RP address does not have to be assigned to a particular router. This allows us to implement a sort of anycast redundant RP setup for BiDir mode. This is not anycast however, because we can use a longest match routing trick to prefer one RP over another.

In this lab we are asked to prefer R9, so we assign a longer prefix mask to its loopback. XR4 has a prefix mask that is one bit shorter. This is advertised into the IGP.

#R9
int Lo100
 ip address 1.0.0.130 255.255.255.252
 ipv6 add 2001::F1/127

#XR4
int lo100
 ip add 1.0.0.130/29
 ipv6 add 2001::F1/126

Note that on IOS-XR, advertising a loopback as type point-to-point in OSPFv2 doesn’t work. Instead, you need to use “loopback stub-network enable.” An equivalent command does not appear to be available for OSPFv3, so IPv6 RP failover will not actually work in this lab.

#XR4
router ospf 1
 area 0
  int lo100
   loopback stub-network enable

It is important to not use the actual IP address of the routers for the phantom RP. For example, in this lab we use .129 and ::F0 for the RP address, while the loopbacks are set to .130 and ::F1. Otherwise, if the standby RP is in the path, it will consider itself the RP instead of considering the other router as the active RP. You would need to deploy MSDP or RFC-based anycast RP so that the RPs would share active sources in that case. However, in BiDir, there is no notion of building (S, G) trees once the RP “discovers” a source, so this simply would never work.

Currently all routers, including XR4, see the RP as pointing towards R9:

Even R9 considers the RP reachable out the Loopback, not itself.

On R5 we’ll join two groups:

#R5
int lo0
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
 ipv6 mld join-group ff08::5

The tree is built towards R9. In actuality it is built towards R9’s loopback, but in terms of the data plane this doesn’t make a difference.

Traffic from any sender is received by R5:

We can implement failover by shutting down Lo100 on R9. R9 will find that the RPF interface is now pointing towards XR14, so it will send a PIM Join out that interface. In the mean time, we’ll leave a ping running from R1 to 239.1.1.1.

#R1
ping 239.1.1.1 repeat 10000 time 1

In total, only one ping was lost. This was in the process the IGP converging and R9 building the tree towards XR4 as the new RP.

Note that because OSPFv3 network-type point-to-point doesn’t appear to be supported on IOS-XR, we cannot test IPv6 traffic.

In summary, the RP in PIM-BiDir does not have any control plane functions, allowing us to use a longest-match routing trick to implement active/standby HA. The RP in BiDir plays a big role, because it is always in the data plane. In PIM-SM, the RP is only used for joining new sources to receivers. Once the receiver is discovered, a shortest path tree is established by default. So an RP failure in PIM-SM does not implact existing multicast traffic. However, in PIM-BiDir, since the RP is always in the data path, an RP failure impacts all multicast traffic. This makes it very important to implement RP redundancy in a PIM-BiDir environment.

Using AutoRP for RP propagation

Instead of configuring the RP statically, you can use AutoRP to propagate this information for IPv4. Note that for this to work, the RP the router is announcing must be reachable via a directly connected route. This does not appear to be supported for IOS-XR.

#R9
int lo0
 ip pim sparse-mode
!
ip pim send-rp-discovery lo0 scope 255
ip pim send-rp-announce 1.0.0.129 scope 255 bidir

On IOS-XE, BSR is not supported to disseminate the phantom RP address because we can only reference an interface. We cannot manually enter an IP address. On IOS-XR, it allows us to manually enter an address, however it does not seem to actually work. It seems the router only allows a local IP address to be used.

#XR4
multicast-routing
 add ipv4
  int lo0 enable
!
router pim
 add ipv4
  bsr candidate-bsr 1.0.0.14
  bsr candidate-rp 1.0.0.129 bidir  ! This does NOT appear to work to advertise the phantom IP

For IPv6, BSR does allow us to specify the manual address on IOS-XE and IOS-XR. However, this doesn’t seem to work on IOS-XR.

#R9
! The "bsr announced rp" is used instead of "bsr candidate rp"
!
ipv6 pim bsr candidate bsr 2001::9
ipv6 pim bsr announced rp 2001::F0 bidir   

#XR4
multicast-routing
 add ipv6
  int lo0 enable
!
router pim
 add ipv6
  bsr candidate-bsr 2001::14 
  bsr candidate-rp 2001::f0 bidir ! This does NOT appear to work on IOS-XR