Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS

  • Support for GRE tunnels over PWHT interfaces (MX240, MX304, MX480, MX960, MX10003, and MX10004)—Starting in Junos OS Release 24.2R1, you can set up a GRE tunnel over your pseudowire headend termination (PWHT) interaface with existing configuration commands.

    [See Pseudowire Headend Termination (PWHT) and Configuring GRE Tunnel Interfaces.]

  • Support for constraint-aware RSVP bypass LSPs (MX204, MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2008, MX2010, and MX2020)—Starting in Junos OS Release 24.2R1, you can configure RSVP bypass label-switched paths (LSPs) to be aware of and 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 (MX204, MX240, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—Starting in Junos OS Release 24.2R1, you can configure the LDP dual-transport mechanism with NSR support to set up IPv4 and IPv6 sessions. This feature helps to forward IPv4 and IPv6 traffic and to support LDP IPv6 sessions in a routing instance.

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

  • Support to increase the retry-timer value (MX10004, MX10008, MX10016, MX2010, and MX2020)—Starting in Junos OS Release 24.2R1, you can increase the amount of time the ingress router waits between to receive a response. Use the adaptive-wait-timer statement at the [edit protocols mpls] hierarchy level to configure the minimum period the ingress router must to wait for receiving a path response message. If the router does not receive any response within the specified time, the wait timer expires and the router terminates the path message and resends the message in the next path maintenance. The default value of the adaptive-wait-timer statement is 180 seconds.

    To apply the default time to all LSPs, configure the initial-time statement at the [edit protocols mpls adaptive-wait-timer] hierarchy level.

    You can optionally configure the max-time statement at the [edit protocols mpls adaptive-wait-timer] hierarchy level to set a maximum exponential backoff timer value for the adaptive-wait-timer statement. When the first adaptive-wait-timer expires, the router continues to retry the path message. In each attempt, the router exponentially backs off the time specified in adaptive-wait-timer to get more time to receive the response.

    When the exponential backoff time reaches the max-time value, the router can no longer back off the waiting time and waits only for the max-time period in further attempts. If you configure initial-time and max-time with the same value, the router waits for the same period during further attempts without any exponential backoff. The default value of the max-time statement is 1800 seconds.

    Note:

    When the adaptive-wait-timer statement is not configured, the router follows the default behavior of waiting for five times the retry-timer value that you configure.

    You can increase the exponent-base value by configuring the backoff-multiplier statement at the [edit protocols mpls adaptive-wait-timer] hierarchy level. The default value of the backoff-multiplier statement is 2. For example, if the initial-time for the adaptive-wait-timer is 180 seconds, then with the default backoff-multiplier value of 2, the exponentially backed-off values of adaptive-wait-timer will be 180 seconds, 360 seconds, 720 seconds, and so on. If you configure backoff-multiplier as 3, then the exponentially backed-off values of adaptive-wait-timer will be 180 seconds, 540 seconds, 1620 seconds, and so on.

    We've enhanced the show mpls tunnel-manager-statistics command to additionally display the number of path messages a router sent and the minimum, maximum, and average time a router takes to receive a response. You can see these statistics only at the global level.

  • Support to exclude a list of hops in the RSVP LSP path (MX480, MX960, MX10004, MX10008, MX10016, and vMX)—Starting in Junos OS Release 24.2R1, you can configure a list of hops to be excluded in the label-switched path (LSP) so that RSVP LSPs avoid those hops and links in the traffic engineering (TE) domain. When an RSVP LSP is signaled in the network, the path message carries the excluded list of hops. When the downstream routers perform loose hop expansion, such as inter-domain LSP or abstract node expansion, the transit routers use the same excluded list of hops that the ingress router uses for path computation.This mechanism enables intermediate routers to avoid the routers included in the excluded hop list. The routers try alternative paths to help with the convergence of LSPs when a complete end-to-end path computation is not possible.

    Additionally, ingress routers receive PathErr messages and when computing another path, the routers use a PathErr message sender's address to avoid the link or node that generates an error. Transit routers also need this error avoidance information during retry attempts. RFC4874 defines the exclude hop information and is accepted in RSVP signaling.

    To configure LSPs to exclude a list of hops, include the exclude statement at the [edit protocols mpls path path-name next-hop] hierarchy level. The ingress routers exclude the hops in CSPF computation and are also included in RSVP LSP signaling.

  • Enhancements to RSVP debug and service commands (MX204, MX480, MX960, MX2020, and vMX)—Starting in Junos OS Release 24.2R1, we have enhanced the following show commands to help you analyze and debug the following information:

    • History of major events on the label-switched paths (LSPs) and RSVP neighbors that the label-switching router (LSR) maintains

    • Actual time taken for certain events. With this information, you can understand whether certain timer values configured are appropriate or not.

    We have enhanced the show rsvp session extensive command to display the timeline of the major events that occur for a session and are maintained in a path state block (PSB). The command output also displays message statistics such as Path, Resv, Err sent, and received for a session.

    We have enhanced the show rsvp neighbor command with the display level extensive to display the timeline of major events that take place for an RSVP neighbor.

    The show mpls tunnel-manager-statistics command has been enhanced to display the minimum, maximum, and average time that clients of an LSP take to relinquish references to an old LSP instance after a make-before-break switchover.These metrics are computed even if the optimize-adaptive-teardown statement is not enabled for LSPs.

    We have enhanced the show rsvp statistics command to display the minimum, maximum, and average time taken for LSPs to be cleaned up by RSVP after the triggering of soft preemption.

    We have increased the maximum configurable value of teardown-timeout at the [edit protocols mpls oam bfd-liveness-detection failure-action make-before-break] hierarchy level from 30 seconds to 65535 seconds.

    We have increased the maximum configurable value of lsp-ping-multiplier at the [edit protocols mpls oam lsp-ping-multiplier] hierarchy level from 1 through 255 (previously 1 through 5).

  • Support for IPv4 static route over IPv6 next-hop (MX204, MX240, MX304, MX480, MX960, MX10003, MX10016, MX2020, QFX5110, and QFX5200)—Starting in Junos OS Release 24.2R1, you can configure an IPv4 static route over an IPv6 next hop to enable routing of IPv4 packets through the IPv6 next hop. The following IPv4 static route over IPv6 next-hop are supported:

    • IPv4 static route over IPv6 direct next-hop

    • IPv4 static route over IPv6 indirect-next-hop

    • IPv4 static route over IPv6 next-hop with preference

    Use the following configuration to support IPv4 static route over IPv6 next-hop:

  • Support for dynamic tunnel for best effort SRv6 tunnels (MX204, MX240, MX304, MX480, MX960, MX10003, MX10004, MX10008, MX10016, MX2008, MX2010, and MX2020)—Starting in Junos OS Release 24.2R1, you can configure Segment Routing for IPv6 (SRv6) Layer 3 VPN dynamic tunnel over a traditional Layer 3 VPN network.

    The following functionalities are supported:

    • DT4, DT6, DT46, uDT4, uDT6, uDT46 SIDs.

    • Signal SRv6 locator based dynamic tunnel from BGP.

    • Resolve BGP route over dynamic tunnel route.

    • Resolve BGP route over dynamic tunnel and create transport tunnel composite next hop (TCNH) with BGP, IGP, and static as the underlay. Have single or multiple router next hops.

    • Forward policies under dynamic tunnels.

    • Propagate DSCP for dynamic tunnel at ingress.

    • Display dynamic tunnel (dyn-tunnel) flag information for SRv6 tunnel as part of show route extensive command.

  • Support to distribute the Entropy Label Capability (ELC) in an ISIS network (MX10003, MX10004, MX10008, and MX10016)—Starting in Junos OS 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 (MX480 and QFX5200)—Starting in Junos OS 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.]