Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Key Features in Junos OS Evolved Release 22.2

Start here to learn about the key features in Junos OS Evolved Release 22.2. For more information about a feature, click the link in the feature description.

  • Blocking asymmetric EVPN Type 5 routes (QFX5130-32CD and QFX5700)—Starting in Junos OS Evolved Release 22.2R1, you can configure the local node to reject asymmetric EVPN Type 5 routes on EVPN-VXLAN networks. The local node examines the incoming EVPN Type 5 route packets and rejects the route when the virtual network identifier (VNI) in the ingress route differs from the locally configured VNI.

    To block asymmetric EVPN Type 5 routes, include the reject-asymmetric-vni statement at the [edit routing-instance routing-instance-name protocols evpn ip-prefix-routes] hierarchy level.

    [See EVPN Type 5 Route with VXLAN encapsulation for EVPN-VXLAN and ip-prefix-routes.]

  • Collect ON_CHANGE BGP RIB telemetry statistics (PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, and QFX5220)

    [See Telemetry Sensor Explorer.]

  • EVPN-MPLS E-LAN flow-aware transport (FAT) label load balancing (PTX10001-36MR, PTX10004, PTX10008, PTX10016) —Starting in Junos OS Evolved 22.2R1, you can configure provider edge (PE) devices to use FAT labels in an EVPN-MPLS routing instance, according to RFC 6391. Provider edge devices use these labels to load-balance EVPN-MPLS unicast packets across ECMP paths without needing to do deep packet inspection of the MPLS payload. This feature supports E-LAN with single-homing and multi-homing active/standby and active/active topologies and supports the VLAN-based, VLAN-bundle, and VLAN-aware bundle EVPN-MPLS variants.

    To enable load balancing using FAT labels in an evpn routing instance:

    • Configure the flow-label-static statement at the [edit routing-instances routing-instance-name protocols evpn hierarchy level on PE devices to insert FAT flow labels into pseudowire packets sent to remote PE devices.

    • Configure the flow-label statement at the [edit routing-instances routing-instance-name protocols evpn hierarchy level on PE devices to signal flow-label capability in the EVPN Layer 2 Attributes Extended Community by setting the flow-label (F) bit in the EVPN Type 3 route.

    [See flow-label and flow-label-static.]

  • gRIBI sensor support (PTX10008 and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, JTI streams programmable routing protocol process (prpd) statistics and gRPC routing information base (RIB, also known as routing table) programming interface-related statistics.

    [See Telemetry Sensor Explorer.]

  • Interconnect EVPN-VXLAN in a data center to an EVPN-VXLAN control plane in a WAN using a gateway model (QFX5130-32CD and QFX5700)—Starting in Junos OS Evolved 22.2R1, we support Data Center Interconnect (DCI) stitching for EVPN-VXLAN gateway tunnels. The gateway connects the data center and the WAN, and both data center and WAN gain forwarding states for route distinguishing, route targeting, and interconnect Ethernet segment identifier (I-ESI) support.

    DCI control plane stitching also:

    • Supports multihoming.

    • Extends the Layer 2 (L2) connectivity required for some tenants in a data center.

    • Uses the unknown MAC route to prevent MAC scale issues on data center network virtualization edge (NVE) devices.

    [See Understanding the MAC Addresses For a Default Virtual Gateway in an EVPN-VXLAN or EVPN-MPLS Overlay Network.]

  • Queue-depth monitoring support for virtual output queues (PTX10001-36MR, PTX10004, PTX10008, and PTX10016)—Virtual output queue (VOQ) queue-depth monitoring, or latency monitoring, measures peak queue occupancy of a VOQ. Starting with Junos OS Evolved Release 22.2R1, PTX Series routers running Junos OS Evolved support VOQ queue-depth monitoring to report peak queue length for a given physical interface for each individual Packet Forwarding Engine.

    [See VOQ Queue-depth Monitoring.]

  • Support for CoS within MPLS networks (QFX5220)—Starting in Junos OS Evolved Release 22.2R1, you can use CoS within MPLS networks to prioritize certain types of traffic during periods of congestion by applying packet classifiers and rewrite rules to the MPLS traffic. We have also added MPLS EXP rewrite support.

    • Default CoS on the provider (P) and provider edge (PE) routers for MPLS interfaces–The MPLS traffic uses the default EXP classifier. MPLS traffic is treated as best-effort traffic using the 802.1 default untrusted classifier. The default EXP classifier applies to all MPLS traffic on interfaces configured as family mpls. Differentiated Services code point (DSCP) classifiers are not applied to MPLS traffic.

    • Default CoS on PE routers for Layer 3 interfaces–By default, all Layer 3 VPN logical interfaces are bound to default DSCP classifiers.

    If you apply an EXP classifier on a penultimate-hop popping (PHP) node, then by default, the MPLS header TLL value overwrites the IP header time-to-live (TTL) value. In this case, a zero (0) overwrites the IP header DSCP bits, which signifies uniform mode. To use pipe mode, where nothing overwrites IP header TTL values or IP header DSCP bits, you should configure the following command:

    set protocols mpls no-propagate-ttl

    Note:

    The DSCP of IP in MPLS packets can’t be remarked either at PE or P routers.

    [See Understanding CoS MPLS EXP Classifiers and Rewrite Rules.]

  • Support for DHCPv6 on zero-touch provisioning (ZTP) (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.2R1, ZTP supports the DHCPv6 client on management and WAN interfaces. During the bootstrap process, the device first uses the DHCPv4 client to request information regarding image and configuration files from the DHCP server. The device checks the DHCPv4 bindings sequentially. If one of the DHCPv4 bindings fails, the device continues to check for bindings until provisioning is successful. If no DHCPv4 bindings exist, however, the device checks for DHCPv6 bindings and follows the same process as for DHCPv4 until the device can be provisioned successfully. The DHCP server uses DHCPv6 options 59 and 17 and applicable sub-options to exchange ZTP-related information between itself and the DHCP client.

    See [Zero Touch Provisioning ].

  • Support for EVPN-virtual private wire service (VPWS) (PTX10001-36MR, PTX10004, PTX10008, and PTX10016)—We've extended support for EVPN-VPWS to the listed PTX Series routers. By default, control-word is enabled on these platforms. To disable the control word feature, use the set routing-instances routing-instance-name protocols evpn no-control-word command.

    [See Overview of VPWS with EVPN Signaling Mechanisms.]

  • Support for the gRPC Network Operations Interface (gNOI) CertificateManagement service (PTX10008 and PTX10016)—Starting in Release 22.2R1, Junos OS Evolved devices support gRPC Network Operations Interface services. You can execute supported CertificateManagement service remote procedure calls (RPCs) to manage certificates on the network device. Using gNOI operations enables you to use the same suite of microservices to efficiently manage large-scale multivendor networks.

    [See gNOI Certificate Management Service.]

  • Symmetric IRB with EVPN Type 2 routes (ACX7100, PTX10001-36MR, PTX10004, PTX10008, PTX10016, QFX5130-32CD, and QFX5700)—Starting in Junos OS Evolved Release 22.2R1, you can enable symmetric IRB EVPN Type 2 routing in an Ethernet VPN–Virtual Extensible LAN (EVPN-VXLAN) edge-routed bridging (ERB) overlay fabric. With the symmetric routing model, leaf devices can route and bridge traffic on both ingress and egress sides of a VXLAN tunnel. Leaf devices use a transit VXLAN network identifier (VNI) and Layer 3 (L3) interfaces on the associated VLAN to exchange traffic across the VXLAN tunnels.

    We support this feature with vlan-aware and vlan-based MAC-VRF instance service type configurations. To enable this feature, you must also configure EVPN Type 5 routing with L3 VRF instances to establish intersubnet reachability among the EVPN devices.

    [See Symmetric Integrated Routing and Bridging with EVPN Type 2 Routes in EVPN-VXLAN Fabrics and irb-symmetric-routing.]

  • TCP authentication option (TCP-AO) for resource public key infrastructure (RPKI) validation sessions (ACX7100-32C, PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, QFX5130-32CD, and QFX5220)—Starting in Junos OS Evolved Release 22.2R1, you can use the TCP authentication option to authenticate RPKI validation sessions for securing the Internet's routing infrastructure, such as the BGP. Using RPKI, legitimate holders of Internet number resources can control the operation of Internet routing protocols to prevent route hijacking and other attacks.

    To enable a TCP authentication option chain to authenticate an RPKI validation session, use the configured authentication-algorithm ao and authentication-key-chain keychain at the [edit routing-options validation group group_name session address] and [edit routing-options validation group group_name] hierarchy level.

    [See TCP Authentication Option (TCP-AO)]