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:

Phantom RP 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

Daniel Rodriguez

Daniel is the co-founder of Network Faculty. He holds the following certifications: CCNA, CCNP, CCIP, LPIC Level 2 and Security+. He loves Perl Programming, Linux, IPv6 and Multicast deployments. When not doing network related study/work, he is training for triathlons and other endurance sports.

More Posts - Website - Twitter - Facebook

Creative Commons License
The Configuring Phantom RP by CCIE Blog, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

Tags: , ,

9 Responses to "Configuring Phantom RP"

  • jomih says:
  • AndyO says:
  • AndyO says:
  • AndyO says:
      • AndyO says:
  • AndyO says:
Leave a Comment

*

Notify me of followup comments via e-mail. You can also subscribe without commenting.