Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS

  • M-LDP Recursive FEC support (MX960, MX10004, MX10008)—Starting in Junos OS Release 23.4R1, we partially support RFC 6512. We've introduced the recursive opaque value type for the MLDP forwarding equivalence class (FEC) element. The recursive opaque value helps to form Multipoint LDP (MLDP) point-to-multipoint (P2MP) tunnels between two autonomous systems (ASs), where the intermediate nodes do not have the route to reach the root node.

    To enable the recursive opaque value, configure the fec statement at the [edit protocols ldp p2mp recursive] hierarchy level.

    [See Understanding Multipoint LDP Recursive FEC.]

  • Computation of unreserved bandwidth optimized RSVP dynamic bypass LSP (MX204, MX240, MX304, MX480, MX960, MX10003, MX10008, MX10016, MX2008, MX2010, MX2020, QFX10008, and QFX10016)—Starting in Junos OS Release 23.4R1, the Constrained Shortest Path First (CSPF) can optionally use a different approach to protect a link or a node by leveraging the computation based on unreserved bandwidths on traffic engineering (TE) links. To enable this feature, use the optimize bandwidth configuration statement at the edit protocols rsvp interface interface link-protection hierarchy level. While the default approach of RSVP bypass produces a bypass method that optimizes traffic engineering (TE) metric, enabling the new configuration statement maximizes the end-to-end unreserved bandwidth.

    [See Configuring Link Protection on Interfaces Used by LSPs.]

  • Capability to compute diverse paths between a set of LSPs (MX960, MX10004, and MX10008 )—Starting in Junos sOS Release 23.4R1, you can associate a group of LSPs (RSVP LSPs or SR MPLS LSPs) to the Path Computation Element Communication Protocol (PCEP) to compute diverse paths for the associated LSPs. The Junos PCC advertises to a Path Computation Element (PCE) that a particular LSP belongs to a diversity-association group. RFC 8800 defines PCEP protocol extensions to associate a set of LSPs that belong to the same association group. This enables a PCE to compute diverse paths for each of the LSPs in each diversity association group and then push the results to the PCC. A PCE can also associate set of LSPs across different PCCs.

    You can enable diversity-association capability in the open message by configuring the following statement:

    After enabling diversity-association capability, you need to also configure the diversity-association group using the following statement:

    For RSVP LSPs:

    For SR LSPs:

    You can provision and delegate the following LSPs:

    • Provision PCE initiated RSVP LSPs with diverse paths

    • Delegate RSVP LSPs with diverse association groups

    • Provision PCE initiated SR MPLS uncolored LSPs with diverse paths

    • Delegate SR MPLS uncolored LSPs with diverse association groups

    • Provision PCE initiated SR MPLS colored LSPs with diverse paths

    • Delegate SR MPLS colored LSPs with diverse association groups

    • Provision PCE initiated SRv6 colored LSPs with diverse paths

    • Delegate SRv6 colored LSPs with diverse association groups

    • Provision PCE initiated SRv6 uncolored LSPs with diverse paths

    • Delegate SRv6 uncolored LSPs with diverse association groups

    [See PCEP Configuration.

  • PCE requests to allocate binding SIDs for SR-TE Colored LSPs (MX480)—Starting in Junos OS Release 23.4R1, a Path Computation Element (PCE) can request Path Computation Client (PCC) to allocate a binding SID from PCC’s label space. PCE can request PCC to allocate a specific binding SID and can also allocate binding SID of PCC’s choice.

    The following PCEP operations are now supported:

    • PCE requests PCC to allocate binding SID of PCC’s choice for delegated LSPs

    • PCE requests PCC to allocate binding SID of PCC’s choice for PCE-Initiated LSPs

    • PCE requests PCC to allocate a specific binding SID for delegated LSPs

    • PCE requests PCC to allocate a specific binding SID for PCE-Initiated LSPs

    • BGP LS for binding SID for colored SR LSP

    The following SRTE binding SID database and label show commands has been introduced to display all binding SIDs with brief and detail outputs:

    • show spring-traffic-engineering binding-sid database brief

    • show spring-traffic-engineering binding-sid database detail

    • show spring-traffic-engineering binding-sid database label label brief

    • show spring-traffic-engineering binding-sid database label label detail

    • show spring-traffic-engineering binding-sid label label brief

    • show spring-traffic-engineering binding-sid label label detail

    [See PCEP Configuration.

  • Support for ICMP MTU exceed error message generation for labeled MPLS packets - Layer 3 VPN and static LSPs (MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2010, MX2020)—Starting in Junos OS Release 23.4R1, we now support ICMP error message generation for MTU exceed errors in an MPLS environment. If a MPLS labeled packet failure occurs at the egress interface of the core or transit nodes due to MTU exceed errors, an ICMP error message is received at the source or Customer Edge devices.

    To enable ICMP MTU exceed error message generation, you need to include the icmp-tunnelling configuration statement at the [edit protocol mpls] hierarchy on the core routers.

    RFC3032 defines ICMP tunnel mechanism to handle ICMP error message generation for MPLS packets for TTL expiry and MTU exceeded exceptions.

  • Map static IPv6 route to next-hop using service label (MX204, MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2008, MX2010, MX2020, virtual-chassis-fabric, QFX10002-60C, QFX10002, QFX10008, and QFX10016)—Starting in Junos OS Release 23.4R1, you can enable static IPv6 routes to be mapped to the next-hop over an IPv4 MPLS network. 6PE is a transitional IPv6 over IPv4 technology that uses MPLS tunnels to carry services.

    You can use the explicit-null configuration statement under the [edit routing-options rib inet6.0 static route ipv6-address] hierarchy level to push ingress service label as part of the static next hop configuration for static IPv6 routes. The explicit-null configuration statement only supports configuring IPv4 mapped IPv6 address.

    The static configuration statement under the [edit routing-options forwarding-table chained-composite-next-hop ingress] hierarchy provisions chained composite next-hop.

    Note:

    The static configuration statement must be enabled before configuring the explicit-null configuration statement.

  • Containerized Bandwidth Prediction Service using ML-TE (cRPD)—Starting in Junos OS Release 23.4R1, we introduce containerized BW Prediction Service (cBPS), which is a container-based software solution in the containerized Routing Protocol Daemon (cRPD) family of products. Using cBPS, you can forecast future bandwidth requirements for MPLS tunnels (LSPs) based on historic traffic patterns. cBPS orchestrates the initial data management, leverages the combination of statistical and machine learning algorithms, and provides changes in the bandwidth through programmable JET APIs.

  • Distributed CSPF support for IPv6-based SR-TE (MX480, MX960, MX2010, and MX2020)—Starting in Junos OS Release 23.4R1, we now support distributed CSPF path computation and auto-translation of IPv6 addresses through SR-TE configuration. A path’s destination address family determines the address family of the SIDs used for the path. Configuring IPv6 addresses through SR-TE results in auto-translation of IPv6 addresses to the associated SIDs. IPv6 hops are defined in compute segment-lists.

    Use the following CLI configurations to enable auto-translation of IPv6 addresses:

    Use the following CLI configurations to define IPv6 hops in compute segment-lists:

    Use the following CLI configurations to enable IPv6 path end points:

    Note:

    End points must be IPv6 router IDs. Other addresses may be router IDs or interface addresses.

    The show spring-traffic-engineering lsp command has been enhanced to show the details of IPv6 addresses.

  • Support IPv6 address for seamless BFD over static segment routing MPLS LSPs (MX204, MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2008, MX2010, and MX2020)—Starting in Junos OS Release 23.4R1, MX Series devices support IPv6 address family for seamless Bidirectional Forwarding Detection (S-BFD) over static segment-routing MPLS LSPs. The mode of operation for sBFD support for IPv6 in centralised and distributed mode is as follows:

    • IPv6 support for sBFD over static segment routing MPLS LSP for responder and initiator in distributed mode.

    • IPv6 support for sBFD over static segment routing MPLS LSP for initiator in centralised mode.

    sBFD IPv6 responder session can only be configured by including the local-ipv6-address configuration statement at the [edit protocols bfd sbfd local-discriminator disc] hierarchy level as follows:

    The IPv6 address that is configured is used as the source IPv6 address in the reply packet.

  • New CLI commands for MPLS LSPs (ACX5448, ACX5448-M, ACX5448-D, MX204, MX240, MX304, MX480, MX960, MX10003, MX10008, MX10016, MX2008, MX2010, MX2020, QFX10008, and QFX10016)—Starting in Junos OS 23.4R1, you can get more visibility into the current state of the MPLS LSPs on the router to debug suspected anomalies in high scale conditions with the following newly introduced CLI commands.

    • show rsvp session bypass [bypass-name] [protected] and show rsvp session [unprotected] provides visibility into LSPs protected by a specific bypass tunnel.

    • show mpls lsp [make-before-break] and show rsvp session [multiple-lsp-sessions] provides sisibility into LSPs undergoing make-before-break.

    • show mpls tunnel-manager-statistics provides statistics on all local repair and make-before-break events for LSPs.

    • show rsvp session [fr-ingress] provides visibility into LSPs on flood-reflector edge routers.

  • PCC Policy Association with SR and RSVP LSP (MX960, MX10004, and MX10008)—Starting in Junos OS 23.4R1, PCC (Path Computation Clients) can link policies with a group of Label Switched Paths (LSPs). This enhancement allows Junos PCC to communicate with a Path Computation Element (PCE) using an extended communication protocol (PCEP). Through this extension, Junos PCC can tell the PCE that a specific LSP is part of a certain Policy Association Group.