Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS

  • Support for constraint-aware RSVP bypass LSPs (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, you can configure RSVP bypass LSPs to be aware of and to inherit all the path constraints from the primary LSPs. You can also explicitly configure bypass constraints for individual LSPs. With this feature, you can control the MPLS path and prevent bypass LSPs from traversing through a specific geographical area in a global MPLS RSVP network.

    [See Configuring Constraint Aware Bypass LSPs.]

  • Support for LDP dual transport over IPv4 and IPv6 sessions with NSR configuration (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, you can configure the LDP dual transport mechanism to establish IPv4 and IPv6 sessions with NSR configurations. This configuration helps in forwarding IPv4 and IPv6 traffic and to support LDP IPv6 sessions in a routing instance.

    [See Carrier-of-Carrier VPNs, LDP Overview, and LDP Configuration.]

  • Enable TLS for PCEP sessions (PTX10008)—Starting in Junos OS Evolved Release 24.2R1, you can enable TLS in the Path Computation Client (PCC) to establish TCP connection with the Path Computation Element (PCE). This configuration creates a secure PCEP (PCEPS) session to transport PCEP messages.

    To enable TLS in the Path Computation Client Process (PCCD) and to establish a PCEPS session, include the tls-strict statement at the [edit protocols pcep] hierarchy level.

    [See Enabling Transport Layer Security for PCEP Sessions.]

  • Support to distribute the Entropy Label Capability (ELC) in an ISIS network (PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, you can distribute ELCs across all the routers in an ISIS network. ELC indicates the capability of a router to interpret Entropy Label Indicator (ELI), remove ELI/EL, and inspect next label. Entropy Readable Label Depth (ERLD) is the number of labels the router is able to read in a label stack and use it for its load balancing function. This can be used in cases of stacked labels (SR-MPLS) to insert ELs at ingress routers based on the different ELC and ERLD of the routers along its path.

    You can configure the entropy-label statement at the [edit protocols isis source-packet-routing] and at the [edit protocols source-packet-routing source-routing-path <*>] hierarchy levels to enable this feature. When the entropy-label statement is configured, the L-ISIS routes and SRTE for the prefixes are installed with a Entropy Label Indicator (ELI) if the endpoint is entropy label capable. Entropy labels are inserted only at the bottom of the label stack regardless of the ERLD of the routers along the path of the tunnel.

    The prefixes with entropy-label-capability-flag statement under the prefix-attribute-flags in the policy statement is advertised in the router to support entropy label based load balancing.

    ELC in ISIS network supports the following functionalities:

    • Store ELC in ISIS database.

    • Distribute ELC across all the routers participating in the ISIS network.

    • Propagate ELC information from ISIS database to TED.

    • Reflect ELC capability from TED in the lsdist table as a part of the Prefix Attribute flag.

    • Reflect ELC capability in the lsdist table and TED on the export side.

    • Reflect the Prefix Attribute flag in ISIS, TED, and BGP LS on import and export side if no-load-balance-label-capability or load-balance-label-capability statement is configured or removed.

    • Distribute ELC flag across ISIS, TED, and BGP LS if the entropy-label-capability-flag statement is added or removed from the policy-statement for the affected prefixes.

    • Update L-ISIS routes based on the activation or deactivation of entropy-label statement under the [edit protocols ISIS source-packet-routing] hierarchy level.

    • Update SR-TE routes if prefix of the tunnel endpoint is capable of doing load balancing and entropy-label statement is configured or removed.

    • Entropy Label Capability flag is preserved when the router propagates the prefix across the ISIS levels.

    • Internet, Layer 3 VPN, Layer 3 VPN, and EVPN-based services over SR and SR-TE routes using entropy-label.

    • Entropy label for both IPv4 and IPv6 prefixes.

    • Entropy label for SR-MPLS tunnels with IPv6 endpoint.

    • Entropy label for 6PE SRTE tunnels.

    • Entropy label capability advertisement for prefixes in different ISIS instance and in multi-topology.

    • Entropy label for flex algorightm prefixes.

    • Entropy label for source-routing-path-template.

    • Entropy label for ping and traceroute to SR-TE tunnel.

    • Entropy label for SBFD.

    Use the show isis database, show ted database, and show route table lsdist.0 commands to view the ELC flag in the Prefix Attribute flags. The show route command shows the load balancing capabilities for the L-ISIS and SPRING-TE routes with the entropy label. 

    The show spring-traffic-engineering lsp detail command displays the entropy-label capability of the tunnel only when the entropy-label statement is configured for the SR-MPLS in the tunnel or at the instance level.

  • Provision binding SIDs for uncolored SR-TE (SR-MPLS) LSP (PTX10008)—Starting in Junos OS Evolved Release 24.2R1, we support provisioning of binding SID for uncolored SR-TE LSP where PCE requests PCC to allocate a binding SID from PCC’s label space as follows:

    • PCE requests PCC to allocate a specific binding SID

    • PCE requests PCC to allocate binding SID of PCCs choice

    We support the following PCE functionalities:

    • PCE requests PCC to allocate binding SID of PCCs choice for delegated LSP.

    • PCE requests PCC to allocate binding SID of PCCs choice for PCE-initiated LSP.

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

    • PCE requests PCC to allocate a specific binding SID for PCE-initiated LSP.

    • Multiple candidate paths with binding SID in a policy.

    We now support both 20-bit and 32-bit binding SID provisioned or requested from a PCE controller.

    [See PCEP Configuration.]

  • Distributed CSPF support for IPv6-based SR-TE (ACX7024 and PTX10001-36MR)—Starting in Junos OS Evolved Release 24.2R1, we 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 can be router IDs or interface addresses.

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