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)

  • [edit class-of-service traffic-control-profiles] should be ordered-by system as per customers—Starting with Junos OS Release 21.2, Junos OS displays class of service configuration in alphabetical order regardless of configuration order.
  • 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.

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.]

Platform and Infrastructure

  • SSH session connection limit and rate limit per connection (PTX Series and QFX Series)—We have introduced SSH <connection-limit> and <rate-limit> options at the <edit system services ssh> hierarchy levels to enable SSH connection limit and rate limit per connection. The default connection limit value is 75 connections and there is no default value associated with rate limit.
  • Support only for manual channelization on QSFP-100G-SR4-T2 optics (QFX5120-48T and QFX5120-32C)—We recommend that you use the active optical cable (AOC) for auto-channelization. The QSFP-100G-SR4-T2 cables do not support auto-channelization. To use the QSFP-100G-SR4-T2 optics with an external breakout cable, you must configure the channelization manually by running the <channel-speed> statement at the edit chassis fpc slot-number pic pic-number (port port-number | port-range port-range-low port-range-high) hierarchy level.

Layer 2 Ethernet Services

  • Link selection support for DHCP (QFX Series)—We've introduced 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. Earlier to this release, the DHCP relay drops packets during the renewal DHCP process as the DHCP Server uses the leaf's address as a destination to acknowledge DHCP renewal message.

    [See relay-option-82.]

Network Management and Monitoring

  • 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.]