New and Changed Features
This section describes the new features and
enhancements to existing features in the Junos OS main release and
the maintenance releases for the SRX Series devices.
Release 17.3R2 New and Changed Features
There are no new features in Junos OS Release 17.3R2 for the SRX Series devices.
Release 17.3R1 New and Changed Features
Junos OS Release 17.3R1 supports the following Juniper Networks security platforms: vSRX, SRX300/320, SRX340/345, SRX550HM, SRX1500, SRX4100/4200, SRX5400, SRX5600, and SRX5800. Most security features in this release were previously delivered in Junos OS for SRX Series “X” releases from 12.1X44 through 15.1X49-D75. Security features delivered in Junos OS for SRX Series “X” releases after 15.1X49-D75 are not available in 17.3R1.
New features for security platforms in Junos OS Release 17.3R1 include:
Flow and Processing
TCP out-of-state packet drop logging (SRX Series)—Starting in Junos OS Release 17.3R1, SRX Series devices support logging of unsynchronized TCP out-of-state packets that are dropped by the flow module.
Within any packet-switched network, when demand exceeds available capacity, the packets are queued up to hold the excess packets until the queue fills, and then the packets are dropped. When TCP operates across such a network, it takes any corrective actions to maintain error-free end-to-end communications.
This feature enables packet recovery by logging the out-of-sync packets for error-free communication, and avoids database servers going out of sync.
TCP packet drop logging occurs when:
TCP packets that trigger session creation are not synchronized.
TCP three-way handshake in flow fails.
TCP sequence check in flow fails.
TCP SYN packets are received in TCP FIN state.
The unsynchronized TCP out-of-state packet drop log is a packet-based log, not a session-based log.
TCP packets that are dropped by TCP-proxy and IDP are not logged.
IPS signature package update (SRX Series and vSRX instances)—Starting with Junos OS Release 17.3, when you upgrade from Junos OS Release 12.3X48 or 15.1X49 to Junos OS Release 17.3 or downgrade from Junos OS Release 17.3 to Junos OS Release 12.3X48 or 15.1X49, you must update the IPS signature package to avoid any IDP configuration commit failures. Update the IPS signature package by:
Downloading the IPS signature package.
Installing the IPS signature package update when the download completes.
When you upgrade from Junos OS Release 15.1X49 to Junos OS Release 17.3, the following warning message is displayed:
WARNING: A full install of the security package is required after reboot. WARNING: Please perform a full update of the security package using WARNING: "request security idp security-package download full-update" WARNING: followed by WARNING: "request security idp security-package install"
Interfaces and Chassis
Promiscuous mode support (SRX5400, SRX5600, SRX5800)—Promiscuous mode function is supported on the SRX5000 line MPC (SRX5K-MPC) on 1-Gigabit, 10-Gigabit, 40-Gigabit, and 100-Gigabit Ethernet interfaces on the MICs.
By default, an interface enables MAC filtering. You can configure promiscuous mode on the interface to disable MAC filtering. When you delete the promiscuous mode configuration, the interface will perform MAC filtering again. You can change the MAC address of the interface even when the interface is operating in promiscuous mode. When the interface is operating in normal mode again, the MAC filtering function on MPC uses the new MAC address to filter packets.
Junos OS XML API and Scripting
Support for Python language for commit, event, op, and SNMP scripts (SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX instances)—Starting in Junos OS Release 17.3R1, you can author commit, event, op, and SNMP scripts in Python on devices that include the Python extensions package in the software image. Creating automation scripts in Python enables you to take advantage of Python features and libraries as well as leverage Junos PyEZ APIs supported in Junos PyEZ Release 1.3.1 and earlier releases to perform operational and configuration tasks on devices running Junos OS. To enable execution of Python automation scripts, which must be owned by either root or a user in the Junos OS super-user login class, configure the language python statement at the [edit system scripts] hierarchy level, and configure the filename for the Python script under the hierarchy level appropriate to that script type. Supported Python versions include Python 2.7.
Layer 2 Features
LACP support in Layer 2 transparent mode (SRX5400, SRX5600, and SRX5800)—Starting with Junos OS Release 17.3R1, LACP is supported in Layer 2 transparent mode in addition to existing support in Layer 3 mode.
When the SRX Series device uses LACP to bundle the member links, it creates high-speed connections, also known as fat pipe, with peer systems. Bandwidth can be increased by adding member links. Increased bandwidth is especially important for redundant Ethernet (reth) and aggregated Ethernet (ae) interfaces. LACP also provides automatic determination, configuration, and monitoring member links.
LACP is compatible with other peers that run the 802.3ad LACP protocol. It automatically binds member links without manually configuring the LAG, thereby avoiding errors.
Tentative sessions are created for all interfaces in a particular VLAN. If there is plenty of one-way traffic, numerous tentative sessions are created. When sessions reach the maximum limit, vector fails and packet loss might be seen.
Support for adding non-native YANG modules to the Junos OS schema (SRX345, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX instances)—Starting in Junos OS Release 17.3R1, you can load custom YANG models on devices running Junos OS to add data models that are not natively supported by Junos OS but can be supported by translation. Doing this enables you to extend the configuration hierarchies and operational commands with data models that are customized for your operations. The ability to add data models to a device is also beneficial when you want to create device-agnostic and vendor-neutral data models that enable the same configuration or RPC to be used on different devices from one or more vendors. You can load custom YANG modules by using the request system yang add operational command.
Maximum number of security policies increased (SRX5400, SRX5600, and SRX5800)—Starting in Junos OS Release 17.3R1, the maximum number of security policies for SRX5400, SRX5600, and SRX5800 devices has increased from 80,000 to 100,000.
Software Installation and Upgrade
Support for FreeBSD version 10 for Junos OS (SRX5800, SRX5600, SRX5400)—Starting with Junos OS Release 17.3R1, on the SRX5000 line of devices, FreeBSD version 10 is the underlying operating system for Junos OS. Junos OS with upgraded FreeBSD is based on an upgraded FreeBSD kernel instead of older versions of FreeBSD. The newer FreeBSD kernel base provides Junos OS with sophisticated processing, efficiency, and security.
On SRX5000 line of devices, use no-validate flag at the request system software add <filename> no-validate command to upgrade or downgrade between Junos OS Release 17.3 and the previous releases.
Along with the upgraded FreeBSD, the System Snapshot feature has been enhanced on the SRX5000 line of devices. For more details, see Junos OS with Upgraded FreeBSD
User Interface and Configuration
Support for configuring the ephemeral database using the NETCONF and Junos XML protocols (SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX instances)—Starting in Junos OS Release 17.3R1, NETCONF and Junos XML protocol client applications can configure the ephemeral configuration database, which is an alternate configuration database that enables multiple clients to simultaneously load and commit configuration changes on a device running Junos OS and with significantly greater throughput than when committing data to the candidate configuration database. Junos OS provides a default instance and up to eight user-defined instances of the ephemeral configuration database. The device’s active configuration is a merged view of the committed configuration database and the configuration data in all instances of the ephemeral configuration database. Ephemeral configuration data is volatile and is deleted upon rebooting the device.