Anycast RP and SM in MVPN environment – how much fun is that…

Every now and then, as a network design engineer, you’re exposed to design failures that reflects business requirement evolving over time and a lesser attention to design planning and testing.

In a troubleshooting scenario I was involved with some time ago could’ve come straight out of the CCDE test – although maybe a bit too technical. The network was running ASM in the core with anycast rendezvous-points, but the business requirements had evolved such that it now had to provide Multicast VPNs – Rosen GRE with PIM signalling (mVPN profile 0) – for streaming services.

Test showed that the MVPN was working and traffic was able to flow, however, once reaching the threshold for the default MDT and switchover to the data MDT was executed traffic stopped for some time.

The Rosen draft states that shared-tree PIM (Bidir) is suitable the default MDT, while the data MDT is most optimal if using SSM.

In the scenario tested, both the source PE and receiver PE had a locally defined instance of the anycast RP and had a MSDP session between them.

When the first receiver joins a stream the following series of events occur;

  • The receiver PE sends and a join towards the source PE within the MVPN. The join is forwarded in the default MDT.
  • Packets start to flow across the default MDT from the source to the receiver.
  • Once a given threshold is exceeded the source PE signals to switch from the default MDT to a data MDT. The MDT update packet is encapsulated in UDP (port 3232) and contains the data MDT group and the source (PE MDT source).
  • Having received the MDT update, the receiver PE prunes out the default MDT flow and expects to start receiving the flow in the data MDT (S,G) which was signalled in the MDT update. However, running ASM, the source PE is required to have the source registered with its RP (or source-active information through MSDP).
  • At the source PE the creation of the data MDT creates a local (S,G), but does not register the source as it has a local RP defined. MSDP triggers SA update if a source registers with the RP or by receipt of the first (S,G) packet from a directly connected source (denoted by the A-flag). The data MDT group does not implement the A-flag initially, hence the SA isn’t triggered and the receiver side doesn’t know of the data MDT source.


  • Once the default MDT is pruned out the receiver PE is unable to join the data MDT as it doesn’t know the source (despite the MDT information). The receiver has to wait for approximately 60 seconds until the source PE sends an SA update/keepalive message for the data MDT (S,G).



So, in this particular case what are our options:

  1. Redesign RP placement so that the source PE doesn’t have a local RP defined.
  2. Implement source-specific multicast for – at least – the data MDT groups.

The latter would be the correct way to go with respect to the RFC/Draft and is possible to do per VPN (least impact). The first choice would impact all multicast applications within the network and might compromise the initial design.