Basic Multicast part 6 – Anycast RP
Continuing with Multicast topics I will talk this time about Anycast RP. Anycast RP is used for RP redundancy. As I explained in my previous posts on multicast it is possible to have RP redundancy with Auto-RP by defining multiple RP servicing the same multicast groups (the RP with the highest IP will be selected as the active RP for a specific group by the MA). PIM BSR can also be used for RP redundancy and the process is the same as with Auto-RP apart from the fact that the BSR router doesn´t elect which RP is active for a specific group. In both cases the failover delay is based on the RP/BSR/MA advertisement intervals which are not fast by default (up to 60 seconds). So the whole point with Anycast RP is that the failover is based on the IGP running in the multicast domain which can be really fast (especially when using Bidirectional Forwarding Detection).
For this post I will use the same topology as the other multicast posts:
Scenario: R4 and R2 will be configured as static RPs sharing the same IP address. An MSDP session will be established between R4 and R2 in order to synchronize source IP information
RPs: R4 and R2 with IP 220.127.116.11
IGP: EIGRP AS 100
Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services
All the routers in the PIM SM topology are configured with PIM SM. For this post I will only use static RP assignment as it is the most commonly used method for group-to-RP mapping due to its deterministic nature. Auto-RP or PIM BSR could also have been used.
Anycast RP introduction
As you read in the post introduction, the Anycast RP solution provides a solution for both fast fail-over and shared-tree load balancing among any number of active RPs in a domain. All RPs in the multicast domain shared the same IP address and the PIM join/prune as well as the source registration messages are sent to the closest RP based on the unicast routing table.
In order for all the RPs in the multicast domain to be synchronized which each other regarding source information, Anycast RP is used in conjunction with MSDP (Multicast Source Discovery Protocol) protocol defined in RFC 3618.
MSDP is used primarily in two deployment scenarios:
- Between PIM domains. In this design, MSDP is used for interconnecting multiple Protocol Independent Multicast (PIM) Sparse Mode (SM) domains and allows a rendezvous point (RP) to dynamically discover active sources outside of its domain.
- Within a PIM domain. MSDP peering used in this scenario is typically based on MSDP mesh groups, where anywhere from two to tens of peers can comprise a given mesh group. MSDP for Anycast-RP without external MSDP peering is a valid deployment option and common.
In this post I will only talk about MSDP with Anycast RP which is a purely intra-domain solution and does not deal with inter-domain multicast.
Let´s have a quick look on how MSDP is working before we start with the configuration.
MSDP is enabled between RPs and runs over a TCP connection (port 639). MSDP allows RPs to exchange multicast source information.
When MSDP is implemented the following sequence of events occurs:
- When the RP receives a registration message from the PIM DR, it sends a Source-Active (SA) to all its MSDP peers. SA message contains all sources that are registered with the originator RP. The initial multicast packet sent by the source (either encapsulated in the register message or received from a directly connected source) is encapsulated in the initial SA message.
- SA messages identify the source address, the multicast group the source is sending to and the originator ID of the RP.
- SA messages are only accepted from the MSDP RPF peer that is in the best path back toward the originator.
MSDP RPF rules that apply to RPF checks for SA messages are dependent on the BGP peerings between the MSDP peers. MSDP relies upon BGP path information to learn the MSDP topology for the SA peer-RPF check. MSDP can be deployed without BGP, however, and as a result, there are some special cases where the requirement to perform a peer-RPF check on the BGP path information is suspended. These cases are:
- There is only a single MSDP peer connection
- A default peer (default MSDP route) is configured
- The originating RP is directly connected
- A mesh group is used
- An implementation is used that allows for an MSDP peer-RPF check using an IGP.
Side note: MSDP mesh group is similar in concept to iBGP loop prevention mechanism. MSDP mesh-groups assume that a member doesn’t have to forward an SA to other members of the mesh-group because the originator will forward to all members which imply that the mesh-group must be a full mesh of MSDP peering among all members.
In our case, as we will only have one MSDP peer the RPF check will not occur. A general requirement of the Anycast RP scheme is that the Anycast address must not be used as the RP address in the RP’s SA messages (otherwise the peer-RPF check will fail).
Alright!, let´s configure Anycast RP in the multicast domain described by the topology at the beginning of this post.
1. Configuration of the Anycast RP IP address
Side note: For the simplicity of the scenario I have configured R2 and R4 to be RP for all the multicast group range (no ACL configured with the ip pim rp-address command).
Once the RP IP address is configured on R2 and R4, we advertised it into the IGP. Let´s verify how R1 is routing to this IP:
Ok so R1 and R5 are routing to the closest IGP metric for the RP IP address which means that R1 will send PIM (*,G) join/prune to R2 and R5 will send PIM register message to R4.
So let´s try to make the receiver sends an IGMP report for the multicast group 18.104.22.168. Let´s check the multicast table on R2 now:
Good, R2 has received the PIM (*,G) join/prune packet from R1 for the multicast group 22.214.171.124.
So now let´s make the source send multicast traffic for this group and see what is happening:
Nothing happens really. Let´s see why!
So R5 the DR for the segment is registering with the RP (126.96.36.199) and send the PIM register packet encapsulating the multicast data to its RPF neighbor which is R4 based on the unicast routing table. But straight away R5 is receiving a register stop message from R4 as R4 has no receivers for this multicast group yet:
And this is the expected behavior as R1 sends the PIM (*,G) join/prune packet to R2 which was the closest path to the RP based on the unicast routing table. So R4 has no knowledge of any receivers for this group. On the other hand R2 has no knowledge of the active source registered with R4:
R2 has no (S,G) state as R5 registered the source with the closest RP IP address which is R4.
What we are seeing here is that R2 and R4 are not in sync with each other regarding the source information. So in order to synchronize R2 and R4 with each other for the multicast source in the multicast domain we need to use MSDP.
2. Configuration of MSDP
The configuration of MSDP is straight forward:
Side note: Both loopback 0 are advertised into EIGRP.
So now that both RP are configured to MDSP peer to each other let´s see if the MSDP session is coming up:
Side note: Like BGP, MSDP establishes neighbor relationships with other MSDP peers. MSDP peers connect using TCP port 639. The lower IP address peer takes the active role of opening the TCP connection. The higher IP address peer waits in LISTEN state for the other to make the connection. MSDP peers send keepalive messages every 60 seconds.
R4 is the MSDP server side while R2 is the MSDP client side. In this case R2 has initiated the TCP connection to R4 as R2 as the lowest IP address. We can confirm that by looking at the following output:
Now that we have the MSDP session established, let´s suppose that no receiver has joined the multicast group 188.8.131.52 yet. Let´s send multicast traffic from the source to the multicast group 184.108.40.206 and let´s see what is happening between R2 and R4.
The following wireshark capture shows the MSDP SA packet sends from R4 to R2 when R4 has just received a PIM register message from R5:
We can see in the wireshark capture above that the first multicast packet is encapsulated in the unicast MSDP SA packet. Also the RP IP is 220.127.116.11 which is the originator ID.
Upon receiving the PIM register message from R5 (the DR), R4 sends a MSDP SA message to R2 with the source, group and originator ID information. The SA message encapsulates the first multicast packet sent by the source. Here we can see that the originator ID is equal to 18.104.22.168 as it is based by default on the highest loopback IP. We saw earlier that the Anycast address must not be used as the RP address in the RP’s SA messages otherwise the peer-RPF check will fail (let´s see if R2 complains about that).
R2 is receiving the SA message from R4 and cache this information without creating any mroute state in the multicast routing table as no receiver have asked to join this multicast group yet. We can also see that the RPF check is successful because RPF-peer check is disabled in this case as we saw before in the RPF check rules (only one single MSPD peer). R2 has only one MSDP peer. If we were to add another MSDP peer, for example R1, the RPF will fail saying: “22.214.171.124: Peer RPF check failed for 126.96.36.199, we are RP”.
R2 also says in the output above that the RPF is successful as we are only using one peer.
So R2 cache the source/group information and we can verify this by using the following show command:
R4 will keep refreshing the SA cache of R2 as long as it hears from the source, that is to say as long as R4 has an (S,G) entry in its multicast table. If not, the SA cache on R2 will expire.
So if step back to the RPF-peer check discussion in the previous paragraph it is a good practice to specify the originator ID not to be the RP Anycast IP address so let´s do that on R2 and R4:
Good! So now we just need to verify what will happen when the receiver joins the multicast group 188.8.131.52 and R2 knows the source through R4 MSDP session. Let´s make the receiver send a IGMP report for 184.108.40.206 and let´s see the debug output on R2:
So R2 upon receiving the (*,G) PIM from R1, create an entry in the Multicast RIB and updates the OIL for this entry with the interface where the (*,G) has been received (towards R1). Then R2 extracts the source IP matching the group from the SA cache and creates an (S,G) entry in the MRIB.
Upon creating the (S,G) entry R1 sends a PIM (S,G) towards the RPF neighbor for the source which is in this case R3. Bellow we can see an overview of the MRIB of R2 after receiving the PIM (*,G) join/prune from R1.
The PIM (S,G) join/prune arrives at R3 and R3 creates a (*,G) and (S,G) state in its MRIB upon receiving it.
So the SPT is build and now the multicast traffic can flow down to the receiver.
Last step, we verify:
Thanks for reading.