Understanding PIM Bidir Phantom RP [GNS3 Lab]
Please refer to the following page for the PIM-Bidir configuration:
Initial setup overview
Initially, the RP is 220.127.116.11 and it was statically configured on R2:
interface Loopback0 ip address 18.104.22.168 255.255.255.255 ip pim sparse-mode ip ospf 1 area 0 ip pim bidir-enable ip pim rp-address 22.214.171.124 bidir
The router R1, R3 and R4 are configured to point to this RP address:
ip pim bidir-enable ip pim rp-address 126.96.36.199 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): 188.8.131.52/4, Static, Bidir Mode RP: 184.108.40.206 (?) R1#show ip route O 220.127.116.11 [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 18.104.22.168 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 (22.214.171.124) , but with a wider subnet LPM than R2:
interface Loopback1 ip address 126.96.36.199 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 188.8.131.52) ,but, It is more specific than R4 address, to win the LPM in IGP:
interface Loopback0 ip address 184.108.40.206 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.