Well, here we are with the promised Phantom RP article. I recommend to read first Configuring Anycast RP, because it explains some basics concepts about using the routing table as a RP placement tool and then Configuring Bidirectional PIM because it explains the details behind the inner workings of Bidirectional multicast traffic.
Phantom RP is a RP placement method used basically for bi-dir environments.
As we know the RP on Bidirectional PIM does not function as a control plane device but sits in the middle of all the group multicast traffic. This has some drawbacks, there is no source information available to load balance like with Anycast RP (MSDP sharing the information between RPs), the redundancy that we can achieve is based on a backup model. In other words, all the load is handled by one RP for the defined groups and in the case of failure then another RP takes over.
Why is similar to Anycast RP?, well because the decision about the active RP placement is also being handled entirely by the routing table. The difference is in the implementation. For Phantom RP, we use the longest prefix match logic in the routing process as opposed to the “closest” RP on Anycast RP. The advantages related to fail-over are almost the same since we are able to switch RP’s at the speed of the convergence of the routing protocol.
The most common method to implement Phantom RP is to assign the same network to a loopback interface on the candidates RP’s device’s but with different mask lengths, then assign the RP IP address inside that range. The actual IP does not needs to exist on any physical interface (that’s why it’s called Phantom) as long as the network is in the routing domain, the traffic will head down to the RP publishing the “best” route (longest prefix). That implementation is in my opinion the most simple, but there are some alternative methods to achieve the same end result such as redistributing floating routes, conditional network advertisements, etc.
As longs as you play with the prefix advertisements in a way you can switchover to another RP in a timely manner, you’ll be on the safe side. The RP on bidirectional PIM is even more important than on SM environments; on SM if you lose the RP only the new flows would be affected as probably the old flows have already joined the shortest path. In Bidirectional pim as the RP is at the middle of all multicast traffic, a failure needs to be recovered the fastest way possible. Having your routing protocol database already aware of the different alternatives is way better than react to a condition and advertise new information, it can save you a few seconds.
Here is our topology:
Let’s build our base configuration on all the devices:
On the RP, I’m going to use the 10.0.0.0 network but with two different network masks.
R5 Primary RP:
R6 Secondary RP (Failover):
As you can see, R2 is going to advertise a longer prefix so It’s going to be the preferred route when we look up an IP inside that range.
And on all PIM routers:
The RP address is a non-existing IP address (not assigned to any interface), it’s just an IP that is inside the ranges published by both RP.
Let’s see how the routing table looks like on R3 and R4:
Excellent!, both are pointing to R5 because it’s the router advertising the longest prefix. If you take a more detailed look at the routing table you’ll see both advertisements:
I’m going to join a group on R2 to test our network and generate some multicast traffic:
If we take a look at R5:
And on R6:
Perfect as you can see R5 is the RP and R6 knows nothing about the group.
Now I’m going to bring down R5 and see how the multicast traffic behaves and the placement of the RP:
The RP 10.0.0.2 now points to R6, and the mroute table on R6 now reflects the group:
And the traffic flows without any problems.
Don’t forget the relevance of the RP on PIM Bidir, methods like Phantom RP help us react quickly to changes in the network. Just keep in mind that the speed of the RP switchover depends of the configuration of the routing protocol, it does not make any sense to configure this kind of technology if you are going to leave a dead interval in OSPF of 40 seconds. To ensure fast recovery we would use for example OSPF fast hellos or BFD (Bidirectional Forward Detection).
The Configuring Phantom RP by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.