Mar
11
Configuring Phantom RP
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:
Configuration
Let’s build our base configuration on all the devices:
ip multicast-routing ip pim bidir-enable
On the RP, I’m going to use the 10.0.0.0 network but with two different network masks.
R5 Primary RP:
interface Loopback1 ip address 10.0.0.1 255.255.255.252 ip pim sparse-mode ip ospf network point-to-point ip ospf 1 area 0
R6 Secondary RP (Failover):
interface Loopback1 ip address 10.0.0.1 255.255.255.248 ip pim sparse-mode ip ospf network point-to-point ip ospf 1 area 0
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:
ip pim rp-address 10.0.0.2 bidir
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.
Verification
Let’s see how the routing table looks like on R3 and R4:
R3# show ip route 10.0.0.2
Routing entry for 10.0.0.0/30
Known via "ospf 1", distance 110, metric 3, type intra area
Last update from 10.0.34.4 on FastEthernet1/0, 00:00:54 ago
Routing Descriptor Blocks:
* 10.0.34.4, from 5.5.5.5, 00:00:54 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1
R4#show ip route 10.0.0.2
Routing entry for 10.0.0.0/30
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.45.5 on FastEthernet2/0, 00:24:05 ago
Routing Descriptor Blocks:
* 10.0.45.5, from 5.5.5.5, 00:24:05 ago, via FastEthernet2/0
Route metric is 2, traffic share count is 1
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:
R4#show ip route 10.0.0.2 longer-prefixes […] O 10.0.0.0/30 [110/2] via 10.0.45.5, 00:24:29, FastEthernet2/0 O 10.0.0.0/29 [110/11] via 10.0.46.6, 00:24:29, FastEthernet0/1
I’m going to join a group on R2 to test our network and generate some multicast traffic:
interface FastEthernet0/1 ip address 192.168.2.2 255.255.255.0 ip pim sparse-mode ip igmp join-group 239.0.0.1 ip ospf 1 area 0
If we take a look at R5:
R5#show ip mroute 239.0.0.1
[…]
(*, 239.0.0.1), 00:02:11/00:03:16, RP 10.0.0.2, flags: B
Bidir-Upstream: Loopback1, RPF nbr 10.0.0.2
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:02:11/00:03:16
Loopback1, Bidir-Upstream/Sparse, 00:02:11/00:00:00
And on R6:
R6#show ip mroute 239.0.0.1 Group 239.0.0.1 not found
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:
R3#show ip route 10.0.0.2
Routing entry for 10.0.0.0/29
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 10.0.36.6 on FastEthernet2/0, 00:01:45 ago
Routing Descriptor Blocks:
* 10.0.36.6, from 6.6.6.6, 00:01:45 ago, via FastEthernet2/0
Route metric is 2, traffic share count is 1
The RP 10.0.0.2 now points to R6, and the mroute table on R6 now reflects the group:
R6#show ip mroute 239.0.0.1
[…]
(*, 239.0.0.1), 00:02:29/00:03:25, RP 10.0.0.2, flags: B
Bidir-Upstream: Loopback1, RPF nbr 10.0.0.2
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:02:29/00:02:33
Loopback1, Bidir-Upstream/Sparse, 00:02:29/00:00:00
And the traffic flows without any problems.
Conclusions
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).
More info
Rendezvous Point Engineering
RP Redundancy with PIM Bidir – Phantom RP
The Configuring Phantom RP by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
