Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
What is the correct behavior for an NG-MVPN implementation?
When NG-MVPN with Protocol Independent Multicast (PIM) any-source multicast or generic routing encapsulation tunneling is used, traffic will not switch over from shared tree to shortest-path tree. Although a register packet is sent to the customer rendezvous point initially, multicast traffic is sent to the receiver through the shortest-path tree from the root.
The following figure shows the expected behavior of an NG-MVPN implementation:
This is an optimization designed to minimize state in the provider core. A drawback to this optimization is that it requires the customer rendezvous point (C-RP) to either be placed in the VRF of the PE router, or it requires a Multicast Source Discovery Protocol (MSDP) or PIM anycast-PIM connection between the C-RP and the PE router. This is because at least one PE router must know about all active sources in the VPN. This behavior is detailed in draft-ietf-l3vpn-2547bis-mcast-bgp-07: Multicast in MPLS/BGP IP VPNs.
To configure the RPT-SPT mode, include the rpt-spt statement at the [edit routing-instances routing-instance-name protocols mvpn mvpn-mode] hierarchy level for all VRFs that make up the VPN. To configure a selective provider tunnel for the shared tree, include the wildcard-group-inet, wildcard-group-inet6, and wildcard-source statements at the [edit routing-instances routing-instance-name provider-tunnel selective] hierarchy level.
CAUTION: When you configure RPT-SPT mode, receivers or sources directly attached to the PE router are not supported. As a workaround, place a CE router between any receiver or source and the PE router.
You can configure PIM to use VPN.inet.2 routes for reverse path forwarding (RPF) checks on NG-MVPN receiver site VRFs.
NG-MVPN is not supported in logical systems at this time.
For more information, click Layer 3 VPNs Feature Guide.