Hide Navigation Pane
Show Navigation Pane
Feedback
Download
SHA1
MPLS Layer 3 VPN on MX Series, M Series, and T Series Routers Frequently Asked Questions
This section presents frequently asked questions and answers related to MPLS Layer 3 VPNs on Juniper MX Series, M Series, and T Series routers.
Can I manually select the upstream multicast hop in NG MPVN instead of having it default to the highest IP address?
When a multicast source connects to two PE routers, the receiver PE router selects the upstream multicast PE router. By default, it selects the router whose upstream address is numerically highest.
In Junos OS 9.6 and later, it is possible to change the upstream PE router selection behavior, for example, if the primary sender PE router has a lower address than the backup sender PE router.
You can select the upstream multicast hop (UMH) based on the unicast route preference, using the unicast-umh-election statement as shown:
Cautions on the use of the unicast-umh-election statement include:
- The unicast preference-based single forwarder election only works with the default deterministic path-selection algorithm in BGP. When a PE router is configured with the cisco-non-deterministic path selection algorithm in BGP, the unicast preference-based single forwarder election might fail. The unicast-umh-election statement can only be configured when cisco-non-deterministic path selection algorithm is not configured.
- All PE routers must prefer the same route to the upstream multicast hop. The unicast preferences for routes to the sources must not depend on any BGP path selection criteria (such as lowest IGP metric) that will cause one PE router to choose one UMH while another PE router chooses a different UMH.
Is four-label push/pop for MPLS supported on Juniper Networks devices?
Although there is no inherent limit to the total number of labels that a given packet can support, the number of labels that a router can push/pop is limited.
Four-label push/pop is not supported for MPLS for Juniper Networks devices. Support for four-label push/pop would only be needed for VPN PE routers that could be the ingress for an RSVP LSP as well as for an LDP LSP that tunnels over the RSVP, and then egresses at a router beyond the endpoint of the RSVP LSP.
For Juniper Networks devices, the VPN PE routers only need to push two labels (VPN and LDP) and the core routers only need to swap and then push up to two labels (swap LDP, push RSVP, and bypass). This provides LDP tunneling in RSVP LSPs, along with link protection.
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. Is this the correct behavior?
Yes, this is the expected behavior of an NG-MVPN implementation, see Figure 3. 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.
Figure 3: NG-MVPN Shortest-Path Tree and Shared Tree Flow
In Junos OS 10.0 and later, there is an NG-MVPN RPT-SPT mode that implements Section 13 of the BGP-MVPN draft. This mode allows shared rendezvous-point trees to be signaled across the NG-MVPN core. This allows you to place the C-RP anywhere, with the cost of slightly more state in the core.
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. |
Can VPN.inet.2 routes be used for reverse path forwarding (RPF) checks in NG-MVPN?
Yes. PIM can be configured to use VPN.inet.2 for RPF on NG-MVPN receiver site VRFs.
Is the smart-optimize-timer statement available for point-to-multipoint LSPs? Is the optimize-timer statement available?
No, the smart-optimize-timer statement isn't supported for point-to-multipoint LSPs. Only the optimize-timer statement is available for point-to-multipoint LSPs.
Is the adaptive statement supported in point-to-multipoint LSPs?
The adaptive statement is not supported in point-to-multipoint LSPs, because the point-to-multipoint LSP is expected to be adaptive by default.
How is composite next hop used in Layer 3 VPNs?
Composite next hop infrastructure provides optimized data structures to handle a label-per-prefix case and to help with convergence. Prior to Junos OS version 9.5, handling label-per-prefix consumed a lot of kernel memory, restricting overall chassis scale. Now, the standard Junos OS method is to use label-per-VPN, which is very scalable.
With chained or composite next hop, memory usage is optimized in both the kernel and the Packet Forwarding Engine. However, on the I-chip this is available only for the Packet Forwarding Engine. The scaling numbers for I-chip based platforms are:
- Junos OS versions prior to 9.5 -- 250,000 to 300,000 labels per prefix
- Junos OS version 9.5 and later -- 600,000 labels per prefix
Data structure optimization within the Packet Forwarding Engine leads to significant savings in DRAM, with the most gains in the next-hop space and in the Layer 2 descriptors.
Can multicast ping be used with a static IGMP join in Rosen MVPN?
When static IGMP is used to join any group, multicast ping does not get any response because static IGMP is not a real IGMP host. Consequently, the ping fails. If Session Announcement Protocol (SAP) is used instead of static IGMP, multicast ping can be used if interface and bypass routing is specified. To do this, include the sap-listen statement at the [edit protocols] hierarchy level on the CE router on the main configuration (not under the routing-instance hierarchy):
Is NG-MVPN supported in logical systems?
No, NG-MVPN is not supported in logical systems at this time.
Is fast reroute supported in point-to-multipoint LSP?
Fast reroute provides a mechanism for automatically rerouting traffic on an LSP if a node or link in an LSP fails, thus reducing the loss of packets traveling over the LSP. For point-to-multipoint LSPs with fast reroute, only link protection is supported; node protection is not supported.
Supported functionality for link protection on point-to-multipoint includes:
- Link protection can be provided for all constituent sub-LSPs of a point-to-multipoint LSP in the event of a link failure.
- The protection LSP is a point-to-multipoint bypass LSP, set up using existing point-to-point bypass LSP (facility backup) mechanisms. The path of the bypass point-to-point LSP can be determined using Constrained Shortest Path First (CSPF) or it can be configured.
Not supported functionality for link protection on point-to-multipoint includes:
- Global repair is not supported: If a link fails and local repair is performed using link protection, the ingress does not attempt to perform global repair. Because there is no secondary LSP or CSPF, traffic remains on the bypass LSP until the link comes back up.
- Regular fast reroute one-to-one detours are not supported because node protection is not supported; instead, link protection is provided by using bypass LSPs.
