Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS

  • Static Adjacency SID support per AE member link (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.4R1, we support static adjacency SID for any specific aggregated Ethernet (AE) interface member link.

    [See Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using Single-hop Static LSP.]

  • Support for Bridge Protocol Data Unit (BPDU) transparency on CCC) interfaces (PTX10001-36MR, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.4R1, we support BPDU transparency on CCC interfaces. All Layer 2 control packets received at a local provider edge (PE) device in a Layer 2 VPN will be tunneled to the remote PE devices, unless you have configured the respective protocol on the local PE device's interface that connects to its CE device. Earlier, you were required to use the l2circuit-control-passthrough configuration statement under the forwarding-options hierarchy level to allow tunneling to remote PE. This configuration statement is no-longer needed and the option is removed from configuration hierarchy. We’ve implemented this feature per “MEF 6.1.1 Layer 2 Control Protocol Handling Amendment.”

    [See Layer 2 Protocol Tunneling.]

  • Support for LDP Tunneling over SR-TE (ACX7100-32C, ACX7100-48L, PTX10003, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.4R1, you can tunnel LDP label-switched paths (LSPs) over segment routing traffic engineering (SR-TE) in OSPF networks. Tunneling LDP over SR-TE provides consistency and co-existence of both LDP LSPs and SR-TE LSPs.

    To configure LDP tunneling over SR-TE, include the tunnel-source-protocol configuration statement at the [edit protocols ospf traffic-engineering] and the ldp-tunneling configuration statement at the [edit protocols ospf source-packet-routing source-routing-path] hierarchy levels.

    [See Tunneling LDP over SR-TE.]

  • PCEP multipath support for SR-TE (PTX10008)—Starting in Junos OS Evolved Release 22.4R1, you can configure the multipath feature (primary or secondary paths) for Path Computation Element Protocol (PCEP) segment routing-traffic engineering (SR-TE) as defined in draft-ietf-pce-multipath-06. We support the following multipath capabilities:

    • When the PCEP multipath feature is enabled, you can configure multiple primary or secondary paths in a candidate path that you configure and control using Path Computation Client (PCC). Note that the PCEP multipath feature is enabled by default.

    • When the PCEP multipath feature is disabled, you can configure only one primary path in a candidate path. Note that a secondary path configuration is not allowed.

    The PCEP multipath feature removes the compute-profile restriction of 1 on the maximum number of segment lists (maximum-computed-segment-lists

    Note:

    When PCEP multipath is enabled, PCCD will not send constraints for PCC-controlled candidate paths.

    [See Configuring Multiple Paths for Path Computation Element Protocol SR-TE Overview.]

  • Auto Derivation of remote discriminator for S-BFD session in SR-TE (PTX10003, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.4R1, you can use the automatically derived route discriminator for Seamless BFD (S-BFD) sessions on segment routing–traffic engineering (SR-TE) paths. With this feature, you don't need to configure a remote discriminator in the S-FBD configuration on the ingress or transit device. Instead, the egress provider edge device will now accept an IP address as a local discriminator.

    To configure this feature, use the set protocols bfd sbfd local-discriminator-ip command.

    Additionally, you can now use a common sBFD template with the S-FBD configurations on multiple controller-provisioned SR-TE policies. In these sBFD sessions, Junos OS automatically derives the remote discriminator from the tunnel endpoint for matching SR-TE policies.

    [See sbfd and Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution.]

  • Compute traffic-engineered path delays using delay metrics (PTX10001-36MR, PTX10003, PTX10004, and PTX10008)—Starting in Junos OS Evolved Release 22.4R1, you can use delay-based metrics for a Path Computation Element (PCE) to compute traffic-engineered paths. You can use delay-based metrics to steer packets on the least-latency paths or the least-delay path. To do this, you need to measure the delay on every link and advertise the delay using a suitable routing protocol (IGP or BGP-LS) so that the ingress has the per link delay properties in its TED.

    See [ Computing Delay Optimized Intradomain and Interdomain Segment Routing Paths] .

  • Support for RSVP delay constraint (PTX10001-36MR, PTX10003, and PTX10008)—Starting in Junos OS Evolved Release 22.4R1, you can configure RSVP label-switched paths (LSPs) to use a delay metric for computing the path. To configure LSPs in this way, use the new CLI options that we've introduced under the [edit protocols mpls label-switched-path name] hierarchy. We've also updated the output of the following show commands:

    • show ted link detail

    • show ted database extensive

    • show route protocol bgp table lsdist.0 extensive

    • show spring-traffic-engineering lsp detail

    • show express-segments name name detail

    • show mpls lsp detail

  • Support for Software driven Wide Area Network (SWAN) ping and traceroute command for PRPD static routes (PTX10008 and PTX10016 )—Starting in Junos OS Evolved Release 22.4R1, SWAN ping and traceroute commands verify the PRPD static path by sending the MPLS echo request packet with the entire labelstack along the same data path that carries the data traffic. To forward this echo request, Junos OS follows a similar process it uses to forward any other packet.

    [See ping-mplstraceroute mpls segment-routing static egress-ip and traceroute mpls segment-routing static egress-ip.]