Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

What’s Changed in Release 21.2R1

Class of Service (CoS)

  • Starting with Junos OS Release 21.2, Junos OS displays class of service configuration in alphabetical order regardless of configuration order.

EVPN

  • Support for displaying SVLBNH information—You can now view shared VXLAN load balancing next hop (SVLBNH) information when you display the VXLAN tunnel endpoint information for a specified ESI and routing instance by using show ethernet-switching vxlan-tunnel-end-point esi esi-identifier esi-identifier instance instance svlbnh command.

  • Log messages are removed (MX Series)—When PTP aggregate Ethernet primary is configured, and PTP Aggregate Ethernet secondary is not configured, the log message Profiles are being modified is removed.

General Routing

  • Commit checks against incorrect configuration of SLC values (MX2020 and MX2010)—We have introduced commit checks against incorrect configuration of sub line cards (SLCs). While configuring SLCs, if you specify any incorrect values (for example, unsupported Packet Forwarding Engine ranges, CPU cores, or DRAM values), the configuration commit fails with an appropriate message to indicate the error.

    [See Configuring Sub Line Cards and Assigning Them to GNFs.]

  • Enhancement to the show chassis pic command—You can now view additional information about the optics when you run the show chassis pic command. The output now displays the following additional field: MSA Version: Multi-source Agreements (MSA) version that the specified optics is compliant to. Values supported are: SFP+/SFP28—SFF-8472 (versions 9.3 - 12.3), QSFP+/QSFP28—SFF 8363 (versions 1.3 - 2.10), and QSFP-DD—CMIS 3.0, 4.0, 5.0. Previously, the show chassis pic command did not display this additional field.

    [See show chassis pic.]

  • Enhanced response to URR query or remove request (MX Series)—When the control plane function sends a URR query or remove request, the Junos Multi-Access User Plane now sends the usage report in the modify response.

  • VLAN isolation disabled by default (MX480, MX960, MX2008, MX2010, and MX2020)—For Junos node slicing, the internal control plane no longer isolates GNFs from each other by default. The internal network has sufficient bandwidth to accommodate GNFs without needing to isolate GNFs from each other. However, if you want to isolate the internal traffic of each GNF from all others, you must configure the set chassis network-slices vlan-isolation CLI configuration statement (which is applicable for all uses except with sub line cards) on all the Routing Engines of the BSYS and GNFs and then reboot the chassis. If you want to configure the sub line card feature, you must ensure that VLAN isolation is disabled. We have deprecated the configuration statement no-vlan-isolation.

    [See vlan-isolation.]

  • ISSU is not supported—Unified in-service software upgrade (ISSU) is not supported when clock synchronization is configured for Precision Time Protocol (PTP) and Synchronous Ethernet.

High Availability

  • Inline Mode for IPv6 Link local BFD sessions (MX240, MX480, and MX960)—Starting in Junos OS 21.2R1, if an IPv6 link-local BFD session is set up, the transmission and reception entries are distributed and by default operates in inline mode. Prior to Junos OS 21.2R1 release, the transmission and reception were handled by the Routing Engine.

Interfaces and Chassis

  • Blocking duplicate IP detection in the same routing instance (ACX Series, EX Series, MX Series, NFX Series, PTX Series, QFX Series, and SRX Series)—Junos will no longer accept duplicate IPs between different logical interfaces in the same routing instance. Refer to the table mentioned in the topic inet (interfaces). When you try to configure same IP on two logical interfaces inside same routing instance, the commit will be blocked with the error displayed as shown below:

    [See inet(interfaces).]

Junos XML API and Scripting

  • Changes to how command-line arguments are passed to Python op scripts (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX, and vSRX)—When the device passes command-line arguments to a Python op script, it prefixes a hyphen (-) to single-character argument names, and it prefixes two hyphens (--) to multi-character argument names. The prefix enables you to use standard command-line parsing libraries to handle the arguments. In earlier releases, the device prefixes a single hyphen (-) to all argument names.

    [See Declaring and Using Command-Line Arguments in Op Scripts.]

  • Refreshing scripts from an HTTPS server requires a certificate (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX, and vSRX)—When you refresh a local commit, event, op, SNMP, or Juniper Extension Toolkit (JET) script from an HTTPS server, you must specify the certificate (Root CA or self-signed) that the device uses to validate the server's certificate, thus ensuring that the server is authentic. In earlier releases, when you refresh scripts from an HTTPS server, the device does not perform certificate validation.

    When you refresh a script using the request system scripts refresh-from operational mode command, include the cert-file option and specify the certificate path. Before you refresh a script using the set refresh or set refresh-from configuration mode command, first configure the cert-file statement under the hierarchy level where you configure the script. The certificate must be in Privacy-Enhanced Mail (PEM) format.

    [See request system scripts refresh-from and cert-file (Scripts).]

Layer 2 Ethernet Services

  • Active leasequery-based bulk leasequery (MX Series)—The overrides always-write-option-82 and relay-option-82 circuit-id configurations at the [edit forwarding-options dhcp-relay] hierarchy level are not mandatory for active leasequery-based bulk leasequery. For earlier releases, the overrides always-write-option-82 and circuit-id configurations are mandatory for active leasequery-based bulk leasequery. For regular bulk leasequery between relay and server without any active leasequery, the overrides always-write-option-82 configurations are mandatory.

    [See bulk-leasequery (DHCP Relay Agent).]

Layer 2 Features

  • Link selection support for DHCP—We have introduced the link-selection statement at the [edit forwarding-options dhcp-relay relay-option-82] hierarchy level, which allows DHCP relay to add suboption 5 to option 82. Suboption 5 allows DHCP proxy clients and relay agents to request an IP address for a specific subnet from a specific IP address range and scope.

    Prior to this release, the DHCP relay dropped packets during the renewal DHCP process and the DHCP server used the leaf's address as a destination to acknowledge the DHCP renewal message.

    [See relay-option-82.]

Network Management and Monitoring

  • Chef and Puppet support removed (EX Series except EX4400, MX Series, PTX Series, and QFX Series)—Starting in Junos OS Release 21.2R1, Junos OS products that were previously running on FreeBSD 11.x based Junos OS are migrated to FreeBSD 12.x based Junos OS. FreeBSD 12.x based Junos OS does not support installing existing Chef or Puppet packages.

  • Changes to how command-line arguments are passed to Python action scripts (ACX Series, EX Series, MX Series, PTX Series, QFX Series, SRX Series, vMX, and vSRX)—When a custom YANG RPC invokes a Python action script and passes command-line arguments to the script, the device prefixes a hyphen (-) to single-character argument names, and it prefixes two hyphens (--) to multi-character argument names. The prefix enables you to use standard command-line parsing libraries to handle the arguments. In earlier releases, the device passes the unmodified argument names to the script.

    [See Creating Action Scripts for YANG RPCs on Devices Running Junos OS and Displaying Valid Command Option and Configuration Statement Values in the CLI for Custom YANG Modules.]

  • Changes to <commit> RPC responses in RFC-compliant NETCONF sessions (ACX Series, EX Series, MX Series, PTX Series, QFX Series, and SRX Series)—When you configure the rfc-compliant statement at the [edit system services netconf] hierarchy level, the NETCONF server's response for <commit> operations includes the following changes:

    • If a successful <commit> operation returns a response with one or more warnings, the warnings are redirected to the system log file, in addition to being omitted from the response.
    • The NETCONF server response emits the <source-daemon> element as a child of the <error-info> element instead of the <rpc-error> element.
    • If you also configure the flatten-commit-results statement at the [edit system services netconf] hierarchy level, the NETCONF server suppresses any <commit-results> XML subtree in the response and only emits an <ok/> or <rpc-error> element.

    [See Configuring RFC-Compliant NETCONF Sessions.]

  • Changes in contextEngineID for SNMPv3 INFORMS (PTX Series, QFX Series, ACX Series, EX Series, MX Series, and SRX Series)—Now the contextEngineID of SNMPv3 INFORMS is set to the local engine-id of Junos devices. In earlier releases, the contextEngineID of SNMPv3 INFORMS was set to remote engine-id.

    [See SNMP MIBs and Traps Supported by Junos OS.]

  • Change in OID ifHighSpeed—Now, the object identifier (OID) ifHighSpeed displays the negotiated speed once negotiation is completed. If the speed is not negotiated, ifHighSpeed displays the actual maximum speed of the interface. In earlier releases, ifHighSpeed always displayed the actual speed of the interface.

    [See SNMP MIBs and Traps Supported by Junos OS.]

Software Defined Networking (SDN)

  • VLAN isolation disabled by default (MX480, MX960, MX2008, MX2010, and MX2020)—For Junos node slicing, the internal control plane no longer isolates GNFs from each other by default. The internal network has sufficient bandwidth to accommodate GNFs without needing to isolate GNFs from each other. However, if you want to isolate the internal traffic of each GNF from all others, you must configure the set chassis network-slices vlan-isolation CLI configuration statement (which is applicable for all uses except with sub line cards) on all the Routing Engines of the BSYS and GNFs and then reboot the chassis. If you want to configure the sub line card feature, you must ensure that VLAN isolation is disabled.

    We have deprecated the configuration statement no-vlan-isolation.

    [See vlan-isolation.]

VPNs

View the traffic selector type for an IPsec tunnel (SRX Series and MX Series)—You can run the show security ipsec security-associations detail command to display the traffic selector type for a VPN. The command displays proxy-id or traffic-selector as a value for the TS Type output field based on your configuration.

[See show security ipsec security-associations.]