In this post we explain the feature defined in the RFC 4610 “Anycast RP using Protocol Independent Multicast” and its configuration on Junos devices.
Prerequisites:
PIM sparse mode is the protocol that allows to build the multicast distribution tree in IPv4 or IPv6 Global Routing environment (not MPLS) from a Source of a stream and a set of multicast Subscribers.
A multicast stream is uniquely identified by a couple of addresses named (S;G) :
- The IP address of the Source : a unicast IPv4 or IPv6 address
- The Multicast IP address of a multicast group : an IP IPv4 (range 224/8) or IPv6 (range FF00::/8)
Usually final subscribers don’t know the source(s) of a given multicast stream but only the Group address of this one. They used a protocol like IGMPv2 or MLDv1 that simply provides interfaces to “Join” or “Leave” a given multicast group G.
N.B. : Enhanced protocols like IGMPv3 or MLDv2 provide the ability to also convey the associated source S of a given group G (not the scope of this post)
Therefore, IGMPv2 or MLDv1 protocols convey ASM information (Any Source Multicast). Its notation is (*,G) and refers to any source that forwards traffic under the multicast G address. In contrary, SSM information (Source Specific Information) refers to a specific stream (S;G).
PIM router receives ASM or SSM information from subscribers and translates them in ASM or SSM PIM messages :
- IGMP Report / MLD Listener report are translated in PIM Join message
- IGMP Leave / MLD Listener done are translated in PIM Prune message
PIM SM also takes in place the concept of RP router(s) : Rendez-vous Point router. This router has a critical role:
- It allows, first, to know where multicast Sources are located within the network. Via a registering mechanism, a border router, directly connected to a Source, registers the SSM information, related to the received stream, on the RP router. Then the RP will join the Source Tree (aka. SPT Short Path tree) between itself and the border router connected to the source.
- In parallel, a border router directly connected to final subscribers joins the “Shared Tree” (aka. RP tree) between itself and the closest RP that manages the Group G.
Finally from the source S to the RP the stream follows the SPT then from the RP to final customer the stream follows the Shared Tree. Usually, when the leaves routers (routers connected to subscribers)start receiving the (S;G) stream through the Shared Tree switch to the SPT, because by receiving the (S;G) stream, those routers knows now the Source S address of the G group.
The following diagrams summarize the concept explained above :
The topology :
And the principle :
Quick explanation:
1- A Source S starts to stream a multicast flow over a G address. The stream is noted (S;G)
2- First router directly connected to Source S, registering the stream by encapsulating multicast traffic in PIM register messages (unicast datagrams). Those messages reach the RP router
3- RP Router creates (S;G) and (*;G) entries.
4- RP router sends back a PIM Join (S;G) message toward the source (it follows the reverse path)
5- When RP starts to receive natively the (S;G) stream via the SPT, it stops the registering process by sending a PIM register stop message toward the border router.
6- In parallel a multicast subscriber for G appears and send a IGMPv2 or MPLDv1 subscription for G.
7- Directly connected router create the (*;G) state
8- Then it sends a PIM Join (*;G) toward the RP (it follows the revers path)
9- RP sends down the multicast stream which follows the Shared Tree until the multicast subscriber.
10- By analyzing multicast traffic the last hop router now creates (S;G) state.
11- It switches to the SPT.
12- It sends a PIM Join message toward the source (it follows the revers path)
13- Intermediate router create (S;G) entry
14- And forwards the PIM Join (S;G) message toward the source.
15- When first hop router receives the (S;G) Join message it starts to send multicast traffic toward multicast subscriber (following the SPT)
16- When last hop router starts receiving (S;G) stream via the SPT it prunes the Shared Tree by sending a PIM Prune message for (*;G) toward the RP
17- RP then prunes the SPT if there is no more routers on Shared Tree by sending a PIM Prune message for (S;G) toward the source.
Anycast RP with PIM :
As we can see, the RP router is a single point of failure. Therefore, it’s natural to want to place several RP in a network to provide failover or load balancing mechanism. One solution is Anycast RP.
Anycast is a method to share a common resource, in IP networks, it is usually an IP address. The principal of Anycast is quite simple.
Several RP share a common IP which will be the IP address configured statically on all the other routers as the RP address (not RP). This unique IP address is announced dynamically by all RP in the IGP. With this method the closest RP will be always used. A synchronization between RP is also needed. Indeed, when a border router registers a (S;G) flow to its closest RP, this one has to notify its other RP peers. Unlike Anycast RP with MSDP where a new protocol is need between RP, Anycast RP with PIM re-uses the PIM Register messages between RPs to synchronize each other.
Another thing to notice, Anycast RP with PIM supports natively IPv6 multicast unlike the MSDP based solution.
The next diagram depicts quickly the concept :
1- A border router receives a new (S;G) stream
2- It registers the stream via a PIM register Start message toward the RP : actually the nearest RP (IGP point of vue) which is in this case RP2.
3- RP2 forwards the PIM registers messages to its RP peers : here RP1.
Let start the config on Junos devices :
The example described below refers to this topology:
This is a Dual Stack network with ISIS as IGP. The Anycast RP address is for IPv4 2.2.2.2/32 and for IPv6 2003::1/128. The routers R1, R2, R3, R4 and R5 and configure with those IP address as static RPs.
The IPv4 and IPv6 Anycast address are configured as secondary address on lo0 interface which is then redistributed (primary and secondary) in ISIS.
R1-R5 configuration :
RP1 configuration :
RP2 configuration :
Now, let configure the Anycast RP feature on both RPs. On RP1 :
On RP2 :
And that’s all for the config ! Now, let start a mcast stream (10.1.1.42 ; 225.5.5.5). To simulate a source I used another router, directly connected to R4 and I used this command. Don’t forget the TTL (by default equal to 1 for mcast ping).
The (S;G) state is well created on directly attached router R4:
In parallel I put a monitoring of PIM packet on RP1 and RP2. Since RP2 is the closest RP of R4, R4 sends its Register Message for (S;G) to RP2 which then acknowledges it via a Register Stop. RP2 updates then its RP peer RP1 by sending the same Register message. RP1 then acknowledges the Register via a Register Stop. As there is no customer for this corresponding (S;G), the stream is stopped at R4 level (Number of downstream interfaces: 0)
The view on RP1 :
Then we start a customer directly attached to R1. As expected, R1 has joined first the Shared Tree. IT sent a PIM Join (*,225.5.5.5) to RP1 the closest RP for it. The RP1 which knows the Source of 225.5.5.5 (previously registered) joins the SPT to S via R3 then R4. The stream follows the SPT toward RP1 then the shared Tree toward R1. R1 switches then to SPT when it knows the source and prunes the Shared Tree. RP1 that also didn’t have customers on Shared Tree, prunes the SPT.
The state on R1 is finally :
And the state on RP1 :
Conclusion:
PIM Anycast RP is a nice feature that only relies on the PIM protocol (unlike with MSDP). Moreover, it supports natively IPv4 and IPv6 multicast. It combines the load balancing and fail over mechanismes in a very simple concept with a small part of configuration. For Sparse Mode with ASM group, it’s one of the best solution to allow multicast high availability on your network.
