JTAC Recommended Junos Software Versions

SRX Series Services Gateways

Platform	JTAC Recommended Junos Software by Platform	Release Type	Last Updated
vSRX	Junos 15.1X49-D50	Standard	12 Aug 2016
SRX100B/H	Junos 12.1X46-D55	Standard	23 Aug 2016
SRX100H2	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX110H	Junos 12.1X46-D55	Standard	23 Aug 2016
SRX110H2	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX210B/H/BE/HE	Junos 12.1X46-D55	Standard	23 Aug 2016
SRX210HE2	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX220H	Junos 12.1X46-D55	Standard	23 Aug 2016
SRX220H2	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX240B/H/B2	Junos 12.1X46-D55	Standard	23 Aug 2016
SRX240H2	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX300 / SRX320 / SRX340 / SRX345	Junos 15.1X49-D50	Standard	12 July 2016
SRX550	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX550HM	Junos 15.1X49-D50	Standard	12 Aug 2016
SRX650	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX1400 (*3)	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX1500	Junos 15.1X49-D50	Standard	12 Aug 2016
SRX3400 / SRX3600 (*3)	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX5400 / SRX5600 / SRX5800 with RE-1800X4 and IOC3 or SCB3 (*2)	Junos 15.1X49-D50	Standard	12 July 2016
SRX5400 / SRX5600 / SRX5800 with RE-1800X4 (*2)	Junos 12.3X48-D35	Standard	4 Oct 2016
SRX5400 / SRX5600 / SRX5800 with SRX5K-RE-13-20 (*2)(*3)	Junos 12.3X48-D35 (*1)	Standard	4 Oct 2016

Notes:

1. KB29651 - Unable to upgrade from Junos OS 12.1X46 to subsequent releases of Junos OS on SRX5400/5600/5800 platforms due to "The /cf filesystem is low on free disk space" on SRX5k RE-13-20
2. KB30446 - SRX Junos SRX5K Hardware / Software compatibility matrix
3. TSB16905 - On SRX High-End platforms, when NAT is configured, ISSU upgrade from 12.1X46-D40 to any higher releases results in loss of security policies

Connecting and Configuring an EX Series Switch - CLI Procedure

Using the CLI, set the following parameter values in the console server or PC:

• Baud rate—9600
• Flow control—None
• Data—8
• Parity—None
• Stop bits—1
• DCD state—Disregard

1. To connect and configure the switch from the console by using the CLI:

Connect the console port to a laptop or PC by using the RJ-45 to DB-9 serial port adapter. An Ethernet cable that has an RJ-45 connecter at either end and an RJ-45 to DB-9 serial port adapter are supplied with the switch.

2. At the Junos OS shell prompt root%, type ezsetup.
3. Enter the hostname. This is optional.
4. Enter the root password you want to use for the device. Reenter the root password when prompted.
5. Enable services such as SSH and Telnet.

   Note: You will not be able to log in to the switch as the root user through Telnet. Root login is allowed only through SSH.

   • The default option for SSH is yes. Select this to enable SSH.
   • The default option for Telnet is no. Change this to yes to enable Telnet.
6. Use the Management Options page to select the management scenario:

   Note: On EX4500, EX6200, and EX8200 switches, only the out-of-band management option is available.

   • Configure in-band management. In in-band management, you configure a network interface or an uplink module (expansion module) interface as the management interface and connect it to the management device.
     In this scenario, you have the following two options:
     • Use the automatically created VLAN default for management—Select this option to configure all data interfaces as members of the default VLAN. Specify the management IP address and the default gateway.
     • Create a new VLAN for management—Select this option to create a management VLAN. Specify the VLAN name, VLAN ID, management IP address, and default gateway. Select the ports that must be part of this VLAN.
   • Configure out-of-band management—Configure the management port. In out-of-band management, you use a dedicated management channel (MGMT port) to connect to the management device. Specify the IP address and gateway of the management interface. Use this IP address to connect to the switch.
7. Specify the SNMP read community, location, and contact to configure SNMP parameters. These parameters are optional.
8. Specify the system date and time. Select the time zone from the list. These options are optional.
9. The configured parameters are displayed. Enter yes to commit the configuration. The configuration is committed as the active configuration for the switch.
10. (For EX4500 switches only) Enter the operational mode command request chassis pic-mode intraconnect to set the PIC mode to intraconnect.

You can now log in with the CLI or the J-Web interface to continue configuring the switch. If you use the J-Web interface to continue configuring the switch, the Web session is redirected to the new management IP address. If the connection cannot be made, the J-Web interface displays instructions for starting a J-Web session.

Juniper : The death of ScreenOS

The Juniper families of SRX services gateways are the replacement platforms for the SSG platforms, the ISG 1000 and ISG 2000 as well as the NS 5000 Series (NS-5200 and NS-5400). The SRX family include a set of branch platforms (SRX210, SRX240 and SRX650), and the high end platforms (SRX3000 and SRX5000).

The entire line of SRX platforms uses JUNOS, a very powerful networking platform that consolidates switching, routing, security and applications into a single OS. JUNOS is very different than ScreenOS and as such, will place a significant migration burden on Juniper, their customers and their partners.

Key points to consider:

The SRX Is not positioned as a firewall.

•      JUNOS is not a security OS and the SRX positioning reflects this based on the routing and switching emphasis which Juniper uses as a means to compete with Cisco. With the SRX, security is merely a service that is enabled along with switching. Juniper does not try to address the problem of the lack of innovation at the firewall which resulted in the loss of visibility and control over applications, users and content.

They cannot do what we do—even with multiple components.

•      Application visibility and control belongs in the firewall and the port based SRX platforms cannot deliver that functionality.

•      Juniper has taken the Cisco approach to say they can do what we do using multiple devices (SRX with IDP, UAC Controller, a UAC agent on every desktop and multiple management components). Even with this “everything-but- the-kitchen-sink” approach, they cannot address the visibility and control (applications, users and content) problem.

Stuck on old technology.

•      The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass firewalls.

•      Full IDP is supported, and can block a very limited set of, mostly bad applications like P2P and IM – currently at 126, an incremental improvement over the 118. The threat focused approach is inadequate in detecting and positively enabling applications. Applications are not threats. They should not be treated as such.

Faster at doing nothing.

•      Their literature claims impressive performance for port-based traffic classification (stateful inspection). But based on packets per second (PPS), a more accurate performance measurement, their performance is not all that great.

A management nightmare.

•      Heavy reliance on CLI for tuning and troubleshooting with no plans to enable management via a GUI.

•      Palo Alto Networks GUI and centralized management interfaces are identical, simplifying management. A full CLI complements the graphical interfaces and, more importantly, all commands can be accessed from any one of the three interfaces.

•      IDP is not part of the firewall policies, but rather part of the IDP policies, which means that port/protocol still determines what traffic the IDP feature sees giving applications an easy way to bypass the IDP controls.

Understanding Junos OS with Upgraded FreeBSD

Starting with Junos OS Release 15.1, certain hardware platforms run a Junos OS based on an upgraded FreeBSD kernel instead of older versions of FreeBSD. Basing Junos OS on the newer kernel provides Junos OS with sophisticated processing, efficiency, and security features which do not then have to be reproduced in Junos OS.

Junos OS with an upgraded FreeBSD kernel provides a clean-slate implementation of Junos OS on top of a pristine (minimally modified) and current version of the FreeBSD OS.

The platforms currently running Junos OS with upgraded FreeBSD are listed in Table 1.

Table 1: Upgraded FreeBSD Kernel Support by Hardware Platform

Platforms	CPU Type	Release Introduced
MX240, MX480, MX960, MX2010, MX2020	Intel	15.1
EX9200	Intel	15.1
QFX5200	Intel	15.1X53-D30

The major processing changes are as follows:

• Interactions between Junos OS and the upgraded FreeBSD kernel use well-established interfaces because Junos OS is now layered on a minimally modified and current version of FreeBSD.
• Symmetric multiprocessing (SMP) is enabled by default.
• FreeBSD provides a consistent runtime environment for all Junos OS platforms.

There are also major changes in file structures and software packages. These changes are as follows:

• New packages use XML description files instead of scripts.
• Hybrid packages are used to install legacy or replacement build images in the general form junos-upgrade-x.tgz, where x is a variable such as mx-x86-64-15.1-20150114 (the whole package name is junos-upgrade-mx-x86-64-15.1-20150114.tgz).
• Multiple package sets (a collection of installed packages) are stored on the router at the same time. Sets can be either active (the currently used set), pending (the set that should be used at the next reboot), or previous (a formerly active set). Non-recovery snapshots (but not recoverable image snapshots) are available for the package sets to preserve package content lists.

There is now a separate Operations, Administration, and Maintenance (OAM) volume (oam) distinct from the Junos OS volume (junos). This provides support for downgrades from replacement build images (that is, those using the upgraded FreeBSD kernel) to the legacy Junos OS with a different kernel. The OAM volume allows you to recover the Junos OS volume using recovery snapshots.

One major change is the distinction between recovery snapshots and non-recovery snapshots.

The major characteristics of the recovery snapshots are as follows:

• Recovery snapshots are full copies of the packages and configuration taken at the time the snapshot command is issued.
• Recovery snapshots reside on the OAM volume or USB medium.

The major characteristics of the non-recovery snapshots are as follows:

• Non-recovery snapshots are snapshots residing on the Junos OS volume that refer to the current running set of packages and a copy of the configuration at the time the snapshot command is issued.
• Non-recovery snapshots do not need to copy the whole Junos OS installation and so are very fast.
• Non-recovery snapshots can be requested as the boot image for the next reboot.

The upgraded FreeBSD kernel requires changes to several commands and statements and their related parameters. The new and changed actions are summarized in Table 2. For details on the changes, see the topics covering the specific command or statement.

Table 2: New and Changed Commands and Statements for Junos OS with Upgraded FreeBSD

Command or Statement	Release Introduced	Change
request system snapshot delete snapshot	15.1	New action
request system snapshot recovery	15.1	New action
request system snapshot load snapshot	15.1	New action
request system recover volume	15.1	New action: volume is either /junos-volume or /oam-volume
request system snapshot	15.1	Changed action
show system snapshot	15.1	Changed action
request system reboot media	15.1	Changed action with new media options

The new FreeBSD kernel also requires that several commands and statements are now deprecated. In some cases, these commands and statements generate an error, and, in other cases, the result is appropriate for the new kernel. The deprecated commands and statements are summarized in Table 3. For details, see the topics covering the specific command or statement.

Table 3: Deprecated Commands and Statements for Junos OS with Upgraded FreeBSD

Deprecated Command or Configuration Statement	Release Deprecated
Deprecated Command
request system partition abort	15.1
request system partition compact-flash	15.1
request system partition hard-disk	15.1
request system snapshot <config-partition>	15.1
request system snapshot <root-partition>	15.1
request system snapshot <slice>	15.1
request system software delete-backup	15.1
request system software rollback <force>	15.1
show system processes providers	15.1
show system snapshot <slice>	15.1
Deprecated Configuration Statement
set system mirror-flash-on-disk	15.1