Understanding PIM Bidir Phantom RP [GNS3 Lab]

Please refer to the following page for the PIM-Bidir configuration:

Topology

Initial setup overview

Initially, the RP is 2.2.2.2 and it was statically configured on R2:

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0

ip pim bidir-enable
ip pim rp-address 2.2.2.2 bidir

The router R1, R3 and R4 are configured to point to this RP address:

ip pim bidir-enable
ip pim rp-address 2.2.2.2 bidir

We can verify this on R1 for example, we can that RP is via R2:

R1#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static, Bidir Mode
    RP: 2.2.2.2 (?)

R1#show ip route

O        2.2.2.2 [110/11] via 172.30.2.2, 00:09:26, Ethernet1/2

But, what if R2 went down for some reason, The multicast traffic will just stops, since all Routers are pointing to RP 2.2.2.2 and based on their IGP table it is via R2 and there is no backup for the route matching the RP address.

So Basically, in PIM Bidir, a Phantom RP is a virtual rendezvous point (RP) that is configured in the network to allow for redundancy and load sharing of multicast traffic.

PIM Bidir phantom RP Configuration

In our example, The router R4 will be the backup for the Rendez Point.

On the router R4, we have configured a loopback interface with an IP subnet in the range of the actual RP address (2.2.2.2) , but with a wider subnet LPM than R2:

interface Loopback1
 ip address 2.2.2.1 255.255.255.240
 ip ospf network point-to-point
 ip pim sparse-mode
 ip ospf 1 area 0

On the Router R2, we configure a loopback interface with same or different IP (that include the real RP address 2.2.2.2) ,but, It is more specific than R4 address, to win the LPM in IGP:

interface Loopback0
 ip address 2.2.2.1 255.255.255.252
 ip ospf network point-to-point
 ip pim sparse-mode
 ip ospf 1 area 0

PIM Bidir phantom RP Redundancy Verification

we are running live Wireshark captures on the link between R1 and R2 and also between R1 and R4:

We can see that the multicast traffic is flowing through R2 as it represent the RP now:

Now, to test our Phantom RP configuration, we will shutdown R2 and see what happens to the multicast flow:

With this, we are able to achieve redundancy for the RP, in case of failover.