Scope of this document

This document describes the list of operations to perform to upgrade Juniper JunOS devices from release 11.4Rx.x and 12.1Xxx to version 12.1X46-D40.2.

Limitations of version

IKEv2 on SRX Series devices in JunOS 12.1X46 does not support policy-based VPNs or VPN monitoring.

Requirements

Juniper firewall device must be managed by NSM[1] 2012.2r6 or above with schema update 324.

The devices to upgrade must have an operational OOBM console access.

Availability of version

Upgrade is available since September 14th, 2014

Warning – Interruption of service

A reboot of the appliance is required to complete the upgrade. Even for firewalls running in cluster environment, a downtime period (from 5 to 10 minutes) is expected.

The OS upgrade phase is the longest part. It could be divided in 2 steps:

•   The download and the installation of the OS on the second partition:
  • Duration: the download time depends on the management link bandwidth and corresponds to the time to download a file of 150Mo (265Mo for High-End). The installation takes about 5 minutes.
  • Impact: it has no impact on production (except the bandwidth usage for inband management), device continue to run on previous OS release
•   The reboot of the device:
  • Duration: This phase will take about 5 to 10 minutes
  • Impact: it will provoke a service interruption. The new OS will be used when the device has restarted.

Configuration synchronization

As configuration may differ between NSM and the device, due to NSM upgrade, commands set via CLI, or due to the OS upgrade itself, it’s important to check several times if configuration is still synchronized. You can do it once in advance during preparation, once before doing the OS upgrade (§ 4) and once before applying configuration changes (§ 6.1).

For that, connect on NSM sub-domain where device is defined and run a configuration comparison between NSM and the device:

• Go to menu “Device > Configuration > Summarize Delta Config”
  
• You shouldn’t have any differences:
  

If there are some differences, you’ll have to modify your configuration in order to get no difference. Else, you could lose some part of your configuration during next import or update.

OS upgrade

• Connect on the device through console port
• Go to CLI mode
• Request the cleanup of system log files and some other temporary files:

root@hostname> request system storage cleanup
List of files to delete:
         Size Date         Name
...
Delete these files ? [yes,no] (no) yes (or no: cf. warning below)

Basically, the list of files to delete contains rotated log files (from /cf/var/log), the content of  /cf/var/crash/ repository and  /cf/var/tmp repository. Except if you need to keep some “crash” files or old log files for debugging purpose, it’s safe to delete them. In the same manner, you can delete /cf/var/tmp content except if you have stored a specific file in this repository and you want to keep it.

WARNING: If you see that this command want to suppress some files that you want to keep:   

• answer “no”
• move these files to SVG DIV repository or to another local repository (/cf/var/home/cosadmin by example)
• launch the command again

• Verify the disk space usage and be sure that the availability on /cf/var is enough to contain the firmware. See the required disk space for the firmware on table of JunOS files

  root@hostname> show system storage
  Filesystem                   Size       Used       Avail      Capacity   
  Mounted on/dev/bo0s3f        342M       150M       165M       48%  /cf/var

If you do not have enough space, you can clear unused logs such as debug log with the command:

clear log log_file_name
List of log files can be seen with this command:
show log ?
Important log files that should not be deleted are: chassisd, default-log-messages, jsrpd, messages

root@hostname> start shell

• Prepare the secondary partition:

  root@hostname> request system snapshot slice alternate

• Install the firmware:

  > request system software add unlink no-validate no-copy /var/tmp/<JunOS_filename>

• Before rebooting the device, you can check configuration synchronization (refer to § 3)
• Reboot the device:

  root@hostname>
  request system rebootReboot the system ? [yes,no] (no) yes

• When the reboot is completed, check the version on primary partition:

  root@hostname> show system snapshot media internal

• (SSH section) On HE Series the keys need to be in this directory /cf/etc/ssh

  root@hostname% ls -l /cf/etc/ssh/

• (SSH section) On Branch Series the keys need to be in this directory /var/db/ssh

  root@hostname% ls -l /etc/ssh

• (SSH section) If for some reason the directory /var/db/ssh (on Branch Series) doesn’t exist you need to recreate one

  mkdir /var/db/ssh

• (SSH section) To recreate the keys you need to run these commands

  root@hostname% ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

• (SSH section) Finally reboot the device and check if the SSH access is come back
• Copy the OS from the primary partition to the backup:

  root@hostname> request system snapshot slice alternate

• Then, check the partitions. You should have 12.1X46-D40.2-domestic on both partitions

  root@hostname> show system snapshot media internal

• Once it is done, check the new version:

  root@hostname> show version

NSM settings

NSM connectivity

Once OS is upgraded, you can check connection status between Juniper firewall device and NSM device server.

• Go to NSM sub-domain where device is defined
• Go to “Configure > Device Manager > Devices”
• Put the mouse on firewall object (or virtual chassis cluster object) to display the status blue box
  

The connection state must be “Up” and Configuration State must be “OS Version Adjustment Needed“ or “Managed, Device Changed”

Before going forward, double check to see if upgrade seems ok (customer flows, admin flows…) as rollback procedure is easier from this point than later.

OS version adjustment

Now, before to import new firewall configuration on NSM server, JunOS release defined for security device object must be changed. To do it:

• Go to NSM sub-domain where device is defined
• Go to “Configure > Device Manager > Devices”
• Right click on firewall object (or virtual chassis cluster object) and choose “Adjust OS Version”
  
• Click on Next to continue
  
• Once running OS version detected, click on Finish.
  
• Now, NSM will update firewall object version.
• Once this is done, click Close.
  
• In “Configure > Device Manager > Devices”, put the mouse on firewall object (or virtual chassis cluster object) to display the status blue box
• Now the Running OS Version must be: “12.1X46-D40.2”
• And the Configuration State: “Managed, In Sync” it could be also “Managed, Device Changed”
  
• Validate that flows are working

Thank you to Shaimaa El Shihaby for her contributions to this article.