Using Anycast RP for Video Multicasting

In my earlier post on Bridging Dense-Mode to Sparse-Mode PIM, I mentioned about using Sparse-Mode Anycast Rendezvous Point (RP). But what is it about?

First of all, let's understand what Sparse-Mode Rendezvous Point is. For all multicast PIM, there is always at least one source (which is typically a video streaming server like the Microsoft Windows Media Services) and many client receivers. Instead of sourcing from the streaming server directly (as in the case of Source-Specific Multicast), multicast sources and receivers must register with their local rendezvous point (RP). So think of RP like a common meeting point for all sources and receivers. It is also known as a Shared Tree multicast model. In Cisco, there are a few configuration models for RP, including Manual RP (i.e. "hard-coding" of RP in every router), Auto-RP (i.e. elect one of many RP candidates), bootstrap RP (similar to Auto-RP) and Anycast RP.

Most RP models support only a single active RP at any one time. Only the Anycast RP model provides load sharing and redundancy in the multicast network. Anycast RP allows two or more rendezvous points (RPs) to share the load for source registration and the ability to act as hot backup routers for each other. Two or more RPs are configured with a common IP address on loopback interfaces with a 32-bit mask, making it a host address. All other routers are statically configured to map the RP to this common address and are likely to be linked up to the nearest RP. The protocol that links up multiple RPs is known as the Multicast Source Discovery Protocol (MSDP).

Static Anycast RP is also relatively easy to configure and troubleshoot. Consider the following example from Cisco.com:

As you can see from above example, both RP1 and RP2 share the common IP address of 10.0.0.1 on loopback 0 interface. MSDP is enabled to peer both RPs on the respective loopback 1 interfaces using the ip msdp commands. All other routers (the 2 routers at the bottom) just statically map the RP to this common IP address using the ip pim rp-address 10.0.0.1 command. Of course, you have to ensure that the loopback addresses are routable within your domain, which can be easily achieved in any dynamic IGP, such as OSPF.

Troubleshooting Summary

For troubleshooting, the most common failure is the breaking of Reverse Path Forwarding (RPF), which is a mechanism for the receiving routers to determine the best path to the source or the RP in this case. The most common omission is the missing  ip pim sparse-mode or ip pim sparse-dense-mode on all router interfaces.

After which still fail, have a client join to the multicast address. Alternatively,  you may simulate the joining by having the client's next-hop L3 access switch or router to join the multicast group using ip igmp join-group 239.1.1.1 (replace this address with the actual multicast address configured on your streaming server) on the receiver's interface level. Trace on every router from the receiver to the source using show ip mroute command (with vrf option in MPLS VPN or VRF-lite situation). Check for broken reverse path (.e.g. take note of missing RPF neighbor with Null incoming interface).

#show ip mroute 239.1.1.1
.....
(10.1.12.4, 239.1.1.1), 00:00:01/00:02:58, flags:
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Dense, 00:00:02/00:00:00
Vlan111, Forward/Dense, 00:00:02/00:00:00

Take note of above output, if you see that the incoming interface is null and the neigbour is empty on a router (bold red), it usually means a missing "ip pim" on some interfaces or an issue on the underlying unicast routing issue. If it's latter, perform standard routing troubleshooting on the underlying IGP or static routes.

There is this good blog post that further elaborates the detailed steps on RPF troubleshooting.