Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Migration, Upgrade, and Downgrade Instructions

 

This section contains the procedure to upgrade Junos OS, and the upgrade and downgrade policies for Junos OS. Upgrading or downgrading Junos OS can take several hours, depending on the size and configuration of the network.

Note

Upgrading to Junos OS Release 12.1X47-D10 or later is not supported on the J Series devices or on the versions of the SRX100 and SRX200 lines with less than 2GB memory. If you attempt to upgrade one of these devices to Junos OS 12.1X47-D10 or later, installation will be aborted with the following error message:

ERROR: Unsupported platform <platform-name >for 12.1X47 and higher

For more information, refer to the Knowledge Base article at https://kb.juniper.net/TSB16632.

Installation and Upgrade

On SRX5000 line of devices with SRX5K RE-13-20 (the first generation Routing Engine), a software upgrade to Junos OS Release 12.3X48-D80 and higher releases might fail the pre-check due to insufficient space available on the compact flash. As a workaround, downgrade to Junos OS Release 12.3X48-D10 first and then upgrade to the target release or fresh install the target release using the USB install-media. For more information, see TSB17655.

Migrating Group VPN Servers and Members

Junos OS Release 12.3X48-D30 allows Group VPN members on SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 devices (also referred to as Group VPNv1 members) to interoperate with Group VPNv2 servers. This section describes the procedure for migrating Group VPNv1 members from interoperating with a Group VPNv1 server to interoperating with a Group VPNv2 server.

Note

This section assumes that you have a working network of a Group VPNv1 server and Group VPNv1 members.

Migration Scenarios and Considerations

There are three scenarios for migrating Group VPNv1 members to interoperate with a Group VPNv2 server. Table 1 describes considerations for each of these scenarios.

Table 1: Considerations for Group VPN Migration Scenarios

Considerations

Migration Scenario 1

Migration Scenario 2

Migration Scenario 3

 

The Group VPNv1 and Group VPNv2 servers have different IKE gateway addresses. The same group ID is used.

The Group VPNv1 and Group VPNv2 servers have the same IKE gateway address. The same group ID is used.

The Group VPNv1 and Group VPNv2 servers have different IKE gateway addresses and use different group IDs.

Impact on traffic during migration:

There is traffic loss until all members move to the Group VPNv2 server.

There is no traffic loss.

There is no traffic loss.

clear security group-vpn member ike security-association operational command performed on each member during migration:

Not required.

Required.

Not required.

Configuration change needed on Group VPNv1 members during migration to Group VPNv2 server:

Minimal configuration change.

Minimal configuration change.

More substantial configuration change, including new group ID.

Configuration change needed on Group VPNv1 members during rollback from Group VPNv2 server to Group VPNv1 server.

Required.

Not required.

Not required.

The steps for migrating Group VPNv1 members for each scenario is described in the following sections.

Migration Scenario 1

In this scenario, the Group VPNv1 server and Group VPNv2 server use different IKE gateway addresses. The same group ID is configured on the Group VPNv1 and Group VPNv2 servers.

  1. Verify that all Group VPNv1 members support the Junos OS 12.3X48 releases.
  2. Upgrade all Group VPNv1 members to run Junos OS Release 12.3X48-D30 or a later 12.3X48 maintenance release.
  3. Configure the Group VPNv2 server with the Group VPNv1 configuration, including the same group ID, with the following exceptions:
    • The IKE authentication algorithm configured must be sha-256.

    • The IPsec authentication algorithm configured must be hmac-sha-256-128.

    • At the [edit security group-vpn server group group-name] hierarchy level, do not configure anti-replay-time-window and server-member-communication.

  4. On each Group VPNv1 member, configure a new IKE proposal that uses the sha-256 authentication algorithm instead of MD5 or SHA1. Bind this IKE proposal to the current IKE policy and commit this change.Note

    IKE proposals are configured with the same Diffie Hellman (DH) group when aggressive mode exchange is used. Group VPNv1 supports DH groups 1, 2, 5, and 14, while Group VPNv2 supports DH groups 14 and 24.

  5. On each Group VPNv1 member, change the IKE gateway address from the Group VPNv1 server’s address to the Group VPNv2 server’s address. When this configuration change is committed, the device reinitiates a new session with the Group VPNv2 server and also receives new TEK keys. This means that the device is not able to communicate securely with another member until the member has migrated to the Group VPNv2 server and received new TEK keys.

To roll back to the Group VPNv1 server:

  • On each Group VPNv1 member, change the IKE gateway address from the Group VPNv2 server’s address to the Group VPNv1 server’s address. When this configuration change is committed, the device reinitiates a new session with the Group VPNv1 server and also receives new TEK keys. This mean that the device is not able to communicate securely with another member until the member has migrated to the Group VPNv1 server and received new TEK keys.

Migration Scenario 2

In this scenario, the Group VPNv1 and Group VPNv2 servers use the same IKE gateway address.

  1. Verify that all Group VPNv1 members support the Junos OS 12.3X48 releases.
  2. Upgrade all Group VPNv1 members to run Junos OS Release 12.3X48-D30 or a later 12.3X48 maintenance release.
  3. Configure the Group VPNv2 server with the Group VPNv1 configuration, including the same group ID, with the following exceptions:
    • The IKE authentication algorithm configured must be sha-256.

    • The IPsec authentication algorithm configured must be hmac-sha-256-128.

    • At the [edit security group-vpn server group group-name] hierarchy level, do not configure anti-replay-time-window and server-member-communication.

  4. On the Group VPNv2 server, bring down the server’s interface before connecting the Group VPNv2 server to the same network segment as the Group VPNv1 server. Only one server can be active at a time.
  5. On the Group VPNv1 server, disable antireplay and heartbeat in the server configuration. Group VPNv1 and Group VPNv2 use different methods of antireplay, and heartbeats are not supported on Group VPNv2 servers.
  6. On the Group VPNv1 server, change the TEK lifetime for all groups to a higher value to avoid rekeys on Group VPNv1 members while the Group VPNv2 server is being activated. To do this, use the set security group-vpn server ipsec proposal proposal-name lifetime-seconds command. The recommended value is based on how much time it takes to activate the Group VPNv2 server and to clear the IKE SA on all Group VPNv1 members.
  7. On each Group VPNv1 member, configure a new IKE proposal that uses the sha-256 authentication algorithm instead of MD5 or SHA1. Add this IKE proposal to the current IKE policy and commit this change.Note

    IKE proposals are configured with the same Diffie Hellman (DH) group when aggressive mode exchange is used. Group VPNv1 supports DH groups 1, 2, 5, and 14, while Group VPNv2 supports DH groups 14 and 24.

  8. On the Group VPNv1 server, bring down the server’s interface to the network.
  9. On the Group VPNv2 server, bring up the server’s interface to the network.
  10. On each Group VPNv1 member, clear the existing IKE SA so that a new IKE SA is used for the next groupkey-pull with the Group VPNv2 server. To do this, issue the clear security group-vpn member ike security-associations command on the member.

To roll back to the Group VPNv1 server:

  1. Bring down the Group VPNv2 server’s interface, then bring up the Group VPNv1 server’s interface.
  2. On each Group VPNv1 member, clear the existing IKE SA so that a new IKE SA is used for the next groupkey-pull with the Group VPNv1 server. To do this, issue the clear security group-vpn member ike security-associations command on the member.

Migration Scenario 3

In this scenario, the Group VPNv1 server and Group VPNv2 server use different IKE gateway addresses. A different group ID is configured on the Group VPNv1 and Group VPNv2 servers.

  1. Verify that all Group VPNv1 members support the Junos OS 12.3X48 releases.
  2. Upgrade all Group VPNv1 members to run Junos OS 12.3X48-D30 or a later 12.3X48 maintenance release.
  3. Configure the Group VPNv2 server with the Group VPNv1 configuration, with the following exceptions:
    • The IKE authentication algorithm configured must be sha-256.

    • The IPsec authentication algorithm configured must be hmac-sha-256-128.

    • At the [edit security group-vpn server group group-name] hierarchy level, do not configure anti-replay-time-window and server-member-communication.

    • The group ID should be your preferred value.

  4. On each Group VPNv1 member, configure a new IKE, IPsec group, and scope policy that matches the configuration on the Group VPNv2 server. When these changes are committed, the Group VPN v1 member will connect to the Group VPNv2 server and download new group policies and TEK keys from the Group VPNv2 server.

    Upon expiration of the hard lifetime, the TEK keys downloaded from the Group VPNv1 server are deleted. Subsequent traffic uses the TEK keys downloaded from the Group VPNv2 server.

    Note

    The new scope policy that works with the Group VPNv2 server must remain below the scope policy that works with the Group VPNv1 server.

  5. On the Group VPNv1 server, disable the interface that connects to the Group VPNv1 members.

To roll back to the Group VPNv1 server:

  • First disable the interface on the Group VPNv2 server that connects to the Group VPNv1 members. Then enable the interface on the Group VPNv1 server that connects to the Group VPNv1 members.

Upgrading an AppSecure Device

Use the no-validate Option for AppSecure Devices.

For devices implementing AppSecure services, use the no-validate option when upgrading from Junos OS Release 11.2 or earlier to Junos OS 11.4R1 or later. The application signature package used with AppSecure services in previous releases has been moved from the configuration file to a signature database. This change in location can trigger an error during the validation step and interrupt the Junos OS upgrade. The no-validate option bypasses this step.

Upgrade and Downgrade Support Policy for Junos OS Releases and Extended End-Of-Life Releases

Support for upgrades and downgrades that span more than three Junos OS releases at a time is not provided, except for releases that are designated as Extended End-of-Life (EEOL) releases. EEOL releases provide direct upgrade and downgrade paths—you can upgrade directly from one EEOL release to the next EEOL release even though EEOL releases generally occur in increments beyond three releases.

You can upgrade or downgrade to the EEOL release that occurs directly before or after the currently installed EEOL release, or to two EEOL releases before or after. For example, Junos OS Releases 12.3X48, 15.1X49, 17.3 and 17.4 are EEOL releases. For example, you can upgrade from Junos OS Release 15.1X49 to Release 17.3 or from Junos OS Release 15.1X49 to Release 17.4. However, you cannot upgrade directly from a non-EEOL release that is more than three releases ahead or behind.

You cannot upgrade directly from a non-EEOL release to a release that is more than three releases ahead or behind. To upgrade or downgrade from a non-EEOL release to a release more than three releases before or after, first upgrade to the next EEOL release and then upgrade or downgrade from that EEOL release to your target release.

For more information about EEOL releases and to review a list of EEOL releases, see https://www.juniper.net/support/eol/junos.html.

For information about software installation and upgrade, see the Installation and Upgrade Guide for Security Devices.

For information about ISSU, see the Chassis Cluster User Guide for Security Devices.