PIM-SM with Anycast RP
Load multicast.init.cfg
Configure R2 and R4 to join (*, 239.1.1.1) and (*, ff08::1).
Configure R9 and XR4 as RPs for all IPv4 multicast groups using Anycast RP.
Use IP address 1.0.0.100/32 for Anycast RP
Configure R6 and R9 as RP for all IPv6 multicast groups using Anycast RP.
Use IP address 2001::100/128 for Anycast RP
Use R1 and R3 as the sources to verify that multicast traffic is working.
Answer
Explanation
In the previous lab, we used a single RP per group range. This does not provide any redundancy - if R9 fails, then the groups it is acting as RP for will cease to work.
To solve this, while still using the simplicitly of static RP assignment, we can use Anycast RP. In this model, multiple routers share the same Anycast IP address and advertise it into the IGP. All routers simply use a single RP, and point to the Anycast IP address. This provides fault tolerance. If one RP fails, IGP routing will simply point to the next closest node in the Anycast set.
To set this up, we simply define the RP address as the Anycast IP on all routers.
Next, we configure XR4 and R9 to have the same Anycast IP address and advertise this into the IGP. Make sure this interface is enabled for PIM.
We will see (*, G) state on whichever RP is closest to the LHR. For example, XR3’s closest RP is R9. R9 will have (*, G) state with the interface facing XR3 in the OIL:
R5’s closest RP ends up being XR4. This is because R10 has ECMP to the Anycast IP, and the highest interface IP address is used as the tiebreaker for the RPF check.
XR4 will therefore also show (*, G) state, with the interface towards XR1 in the OIL:
You may have noticed that at this point we have a problem. We have two separate multicast distribution trees setup.
Whichever RP the FHR chooses to register with will determine which RP tree is used. For example, if we ping 239.1.1.1 from CSR1, only CSR2 will respond, as CSR7 will register with only XR4.
To solve this, XR4 and CSR9 need a way to notify each other of active sources. This allows the registration process to extend to all RPs. We can re-use the inter-domain PIM protocol for registering sources for this purpose: MSDP (Multicast Source Discovery Protocol). Make sure to source the MSDP session from a non-Anycast IP on each RP.
Now, upon learning of an active source, XR4 will notify R9. This allows R9 to join a (S, G) rooted at the sender, as if the sender was learned via a PIM Register.
The multicast ping is receiving a reply from both R2 and R4 now:
On R9 we see that the source was learned via the MSDP peer:
IPv6 Anycast
IPv6 PIM does not support MSDP. We must use a different mechanism for R9 and R6 to learn of active IPv6 multicast sources that were registered with the other RP. RFC4610 (Anycast RP Using PIM) was developed exactly for this purpose.
The idea and mechanism behind this seems fairly basic. It appears that the RP that receives a Register message simply replicates this to all other statically-defined anycast RP peers. The other RP peers will see a Register message arrive from the first RP.
However, the configuration behind this is easy to get wrong. We must define the local router itself as a member of the anycast RP group.
First we define the common Anycast IPv6 address:
Next, we define the Anycast peers, being sure to include the local router itself as a peer.
For example, when R6 receives a register, it will forward it to R9. Below, we see R9 receiving a register from R6 (”Anycast RP”).
Last updated
