MPLS

Support for the EVPN-LAN and P2P services using an MPLS-based core with IPv6 underlay (MX Series)—Starting in Junos OS Release 21.2R1, we extend support for the EVPN-VXLAN and point-to-point (P2P) services using an MPLS-based IPv6 underlay. The services operate over an MPLS-based core with IPv6 addresses on the PE routers using Segment Routing with Multiprotocol Label Switching (SR-MPLS). The services also operate on the segment routing–traffic engineering (SR-TE) addresses that are responsible for the path calculation between the EVPN PE devices. You can use the EVPN-MPLS commands with the MPLS-based IPv6 underlays.

To enable EVPN-MPLS-over-IPv6 functionality, set the protocols evpn encapsulation mpls-inet6 configuration statement for each EVPN routing-instance in the [routing-instances <routing-instance-name> protocols evpn encapsulation] hierarchy level.

[See Understanding EVPN with VXLAN Data Plane Encapsulation and protocols evpn encapsulation mpls-inet6.]

RSVP signaling over IS-IS nonforwarding adjacency (MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 21.2R1, you can configure any Level 1-Level 2 (L1-L2) routers that have been configured as a flood-reflector client to expand the flood-reflector hops in the Explicit Route Objects (EROs) carried in the Path messages. This feature enables the L1-L2 routers to signal RSVP over IS-IS nonforwarding adjacency by expanding the flood-reflector hops in the EROs instead of propagating the Path messages over the UDP tunnels.

To know how to configure the flood-reflector interfaces, see How to Configure Flood-Reflector Interfaces in IS-IS Networks.

To expand the flood-reflector hops in EROs, use the rsvp expand-flood-reflector-hop configuration statement at the [edit protocols] hierarchy level.

Using the traceoptions (Protocols RSVP) command with the flag event option, you can view the new trace messages in the file that is created.

The show ted database and show rsvp session command outputs introduce the following additional information:

[See How to Configure Flood-Reflector Interfaces in IS-IS Networks, show ted database, show rsvp session, and traceoptions (Protocols RSVP).]

RSVP-TE supports preempting secondary LSPs that are signaled but not active (MX Series and PTX Series)—Starting in Junos OS Release 21.2R1, you can preempt secondary LSPs that are signaled but not active and configure the hold priority of the secondary standby label-switched path (LSP) for RSVP-Traffic Engineering (RSVP-TE). This helps to bring up non-standby secondary path LSPs with higher setup priority which are not able to come-up because of bandwidth crunch. To configure the non-active hold priority value for a secondary standby path, use the non-active-hold-priority statement at the [edit protocols mpls label-switched-path <lsp-name> secondary <path-name>] hierarchy level. You can set the priority from 0 through 7, where 0 is the highest priority and 7 is the lowest.

Support for 128 primary paths per static segment routing LSP (MX Series and PTX Series)—Starting in Junos OS 21.2R1, we've increased the maximum number of segment-list bindings to an LSP tunnel from 8 to 128, with not more than 1000 tunnels per system. A maximum of 128 primary paths are supported per static segment routing LSP.

[See Static Segment Routing LSP Limitations.]