Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Migration, Upgrade, and Downgrade Instructions

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

Basic Procedure for Upgrading to Release 14.2

In order to upgrade to Junos OS 10.0 or later, you must be running Junos OS 9.0S2, 9.1S1, 9.2R4, 9.3R3, 9.4R3, 9.5R1, or later minor versions, or you must specify the no-validate option on the request system software install command.

When upgrading or downgrading Junos OS, always use the jinstall package. Use other packages (such as the jbundle package) only when so instructed by a Juniper Networks support representative. For information about the contents of the jinstall package and details of the installation process, see the Installation and Upgrade Guide.

Note: With Junos OS Release 9.0 and later, the compact flash disk memory requirement for Junos OS is 1 GB. For M7i and M10i routers with only 256 MB memory, see the Customer Support Center JTAC Technical Bulletin PSN-2007-10-001 at https://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2007-10-001
&actionBtn=Search

Note: Before upgrading, back up the file system and the currently active Junos OS configuration so that you can recover to a known, stable environment in case the upgrade is unsuccessful. Issue the following command:

user@host> request system snapshot

The installation process rebuilds the file system and completely reinstalls Junos OS. Configuration information from the previous software installation is retained, but the contents of log files might be erased. Stored files on the routing platform, such as configuration templates and shell scripts (the only exceptions are the juniper.conf and ssh files) might be removed. To preserve the stored files, copy them to another system before upgrading or downgrading the routing platform. For more information, see the Junos OS Administration Library for Routing Devices.

The download and installation process for Junos OS Release 14.2 is different from previous Junos OS releases.

  1. Using a Web browser, navigate to the All Junos Platforms software download URL on the Juniper Networks webpage:

    http://www.juniper.net/support/downloads/

  2. Select the name of the Junos platform for the software that you want to download.
  3. Select the release number (the number of the software version that you want to download) from the Release drop-down list to the right of the Download Software page.
  4. Select the Software tab.
  5. In the Install Package section of the Software tab, select the software package for the release.
  6. Log in to the Juniper Networks authentication system using the username (generally your e-mail address) and password supplied by Juniper Networks representatives.
  7. Review and accept the End User License Agreement.
  8. Download the software to a local host.
  9. Copy the software to the routing platform or to your internal software distribution site.
  10. Install the new jinstall package on the routing platform.

    Note: We recommend that you upgrade all software packages out of band using the console because in-band connections are lost during the upgrade process.

    Customers in the United States and Canada, use the following command:

    user@host> request system software add validate reboot source/jinstall-14.2R8.5-domestic-signed.tgz

    All other customers, use the following command:

    user@host> request system software add validate reboot source/jinstall-14.2R8.5-export-signed.tgz

    Replace source with one of the following values:

    • /pathname—For a software package that is installed from a local directory on the router.
    • For software packages that are downloaded and installed from a remote location:

      • ftp://hostname/pathname
      • http://hostname/pathname
      • scp://hostname/pathname (available only for Canada and U.S. version)

    The validate option validates the software package against the current configuration as a prerequisite to adding the software package to ensure that the router reboots successfully. This is the default behavior when the software package being added is a different release.

    Adding the reboot command reboots the router after the upgrade is validated and installed. When the reboot is complete, the router displays the login prompt. The loading process can take 5 to 10 minutes.

    Rebooting occurs only if the upgrade is successful.

Note: After you install a Junos OS Release 14.2 jinstall package, you cannot issue the request system software rollback command to return to the previously installed software. Instead you must issue the request system software add validate command and specify the jinstall package that corresponds to the previously installed software.

Upgrade and Downgrade Support Policy for Junos OS 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 11.4, 12.3, and 13.3 are EEOL releases. You can upgrade from Junos OS Release 11.4 to Release 12.3 or even from Junos OS Release 11.4 to Release 13.3. However, you cannot upgrade directly from a non-EEOL release that is more than three releases ahead or behind. For example, you cannot directly upgrade from Junos OS Release 12.1 (a non-EEOL release) to Junos OS Release 13.3 or directly downgrade from Junos OS Release 13.3 to Junos OS Release 12.1.

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 on EEOL releases and to review a list of EEOL releases, see http://www.juniper.net/support/eol/junos.html

Upgrading a Router with Redundant Routing Engines

If the router has two Routing Engines, perform a Junos OS installation on each Routing Engine separately to avoid disrupting network operation as follows:

  1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine and save the configuration change to both Routing Engines.
  2. Install the new Junos OS release on the backup Routing Engine while keeping the currently running software version on the master Routing Engine.
  3. After making sure that the new software version is running correctly on the backup Routing Engine, switch over to the backup Routing Engine to activate the new software.
  4. Install the new software on the original master Routing Engine that is now active as the backup Routing Engine.

For the detailed procedure, see the Installation and Upgrade Guide.

Upgrading Juniper Network Routers Running Draft-Rosen Multicast VPN to Junos OS Release 10.1

In releases prior to Junos OS Release 10.1, the draft-rosen multicast VPN feature implements the unicast lo0.x address configured within that instance as the source address used to establish PIM neighbors and create the multicast tunnel. In this mode, the multicast VPN loopback address is used for reverse path forwarding (RPF) route resolution to create the reverse path tree (RPT), or multicast tunnel. The multicast VPN loopback address is also used as the source address in outgoing PIM control messages.

In Junos OS Release 10.1 and later, you can use the router’s main instance loopback (lo0.0) address (rather than the multicast VPN loopback address) to establish the PIM state for the multicast VPN. We strongly recommend that you perform the following procedure when upgrading to Junos OS Release 10.1 if your draft-rosen multicast VPN network includes both Juniper Network routers and other vendors’ routers functioning as provider edge (PE) routers. Doing so preserves multicast VPN connectivity throughout the upgrade process.

Because Junos OS Release 10.1 supports using the router’s main instance loopback (lo0.0) address, it is no longer necessary for the multicast VPN loopback address to match the main instance loopback adddress lo0.0 to maintain interoperability.

Note: You might want to maintain a multicast VPN instance lo0.x address to use for protocol peering (such as IBGP sessions), or as a stable router identifier, or to support the PIM bootstrap server function within the VPN instance.

Complete the following steps when upgrading routers in your draft-rosen multicast VPN network to Junos OS Release 10.1 if you want to configure the routers’s main instance loopback address for draft-rosen multicast VPN:

  1. Upgrade all M7i and M10i routers to Junos OS Release 10.1 before you configure the loopback address for draft-rosen Multicast VPN.

    Note: Do not configure the new feature until all the M7i and M10i routers in the network have been upgraded to Junos OS Release 10.1.

  2. After you have upgraded all routers, configure each router’s main instance loopback address as the source address for multicast interfaces. Include the default-vpn-source interface-name loopback-interface-name] statement at the [edit protocols pim] hierarchy level.
  3. After you have configured the router’s main loopback address on each PE router, delete the multicast VPN loopback address (lo0.x) from all routers.

    We also recommend that you remove the multicast VPN loopback address from all PE routers from other vendors. In Junos OS releases prior to 10.1, to ensure interoperability with other vendors’ routers in a draft-rosen multicast VPN network, you had to perform additional configuration. Remove that configuration from both the Juniper Networks routers and the other vendors’ routers. This configuration should be on Juniper Networks routers and on the other vendors’ routers where you configured the lo0.mvpn address in each VRF instance as the same address as the main loopback (lo0.0) address.

    This configuration is not required when you upgrade to Junos OS Release 10.1 and use the main loopback address as the source address for multicast interfaces.

    Note: To maintain a loopback address for a specific instance, configure a loopback address value that does not match the main instance address (lo0.0).

For more information about configuring the draft-rosen Multicast VPN feature, see the Multicast Protocols Feature Guide for Routing Devices.

Upgrading the Software for a Routing Matrix

A routing matrix can be either a TX Matrix router as the switch-card chassis (SCC) or a TX Matrix Plus router as the switch-fabric chassis (SFC). By default, when you upgrade software for a TX Matrix router or a TX Matrix Plus router, the new image is loaded onto the TX Matrix or TX Matrix Plus router (specified in the Junos OS CLI by using the scc or sfc option) and distributed to all line-card chassis (LCCs) in the routing matrix (specified in the Junos OS CLI by using the lcc option). To avoid network disruption during the upgrade, ensure the following conditions before beginning the upgrade process:

  • A minimum of free disk space and DRAM on each Routing Engine. The software upgrade will fail on any Routing Engine without the required amount of free disk space and DRAM. To determine the amount of disk space currently available on all Routing Engines of the routing matrix, use the CLI show system storage command. To determine the amount of DRAM currently available on all the Routing Engines in the routing matrix, use the CLI show chassis routing-engine command.
  • The master Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC) and all LCCs connected to the SCC or SFC are all re0 or are all re1.
  • The backup Routing Engines of the TX Matrix or TX Matrix Plus router (SCC or SFC) and all LCCs connected to the SCC or SFC are all re1 or are all re0.
  • All master Routing Engines in all routers run the same version of software. This is necessary for the routing matrix to operate.
  • All master and backup Routing Engines run the same version of software before beginning the upgrade procedure. Different versions of the Junos OS can have incompatible message formats especially if you turn on GRES. Because the steps in the process include changing mastership, running the same version of software is recommended.
  • For a routing matrix with a TX Matrix router, the same Routing Engine model is used within a TX Matrix router (SCC) and within a T640 router (LCC) of a routing matrix. For example, a routing matrix with an SCC using two RE-A-2000s and an LCC using two RE-1600s is supported. However, an SCC or an LCC with two different Routing Engine models is not supported. We suggest that all Routing Engines be the same model throughout all routers in the routing matrix. To determine the Routing Engine type, use the CLI show chassis hardware | match routing command.
  • For a routing matrix with a TX Matrix Plus router, the SFC contains two model RE-DUO-C2600-16G Routing Engines, and each LCC contains two model RE-DUO-C1800-8G or RE-DUO-C1800-16G Routing Engines.

Best Practice: Make sure that all master Routing Engines are re0 and all backup Routing Engines are re1 (or vice versa). For the purposes of this document, the master Routing Engine is re0 and the backup Routing Engine is re1.

To upgrade the software for a routing matrix, perform the following steps:

  1. Disable graceful Routing Engine switchover (GRES) on the master Routing Engine (re0) and save the configuration change to both Routing Engines.
  2. Install the new Junos OS release on the backup Routing Engine (re1) while keeping the currently running software version on the master Routing Engine (re0).
  3. Load the new Junos OS on the backup Routing Engine. After making sure that the new software version is running correctly on the backup Routing Engine (re1), switch mastership back to the original master Routing Engine (re0) to activate the new software.
  4. Install the new software on the new backup Routing Engine (re0).

For the detailed procedure, see the Routing Matrix with a TX Matrix Router Deployment Guide PDF Document or the Routing Matrix with a TX Matrix Plus Router Deployment Guide PDF Document.

Upgrading Using Unified ISSU

Unified in-service software upgrade (ISSU) enables you to upgrade between two different Junos OS releases with no disruption on the control plane and with minimal disruption of traffic. Unified in-service software upgrade is only supported by dual Routing Engine platforms. In addition, graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) must be enabled. For additional information about using unified in-service software upgrade, see the High Availability Feature Guide for Routing Devices.

For information on ISSU support across platforms and Junos OS releases, see the In-Service Software Upgrade (ISSU) Web application.

Upgrading from Junos OS Release 9.2 or Earlier on a Router Enabled for Both PIM and NSR

Junos OS Release 9.3 introduced NSR support for PIM for IPv4 traffic. However, the following PIM features are not currently supported with NSR. The commit operation fails if the configuration includes both NSR and one or more of these features:

  • Anycast RP
  • Draft-Rosen multicast VPNs (MVPNs)
  • Local RP
  • Next-generation MVPNs with PIM provider tunnels
  • PIM join load balancing

Junos OS Release 9.3 introduced a new configuration statement that disables NSR for PIM only, so that you can activate incompatible PIM features and continue to use NSR for the other protocols on the router: the nonstop-routing disable statement at the [edit protocols pim] hierarchy level. (Note that this statement disables NSR for all PIM features, not only incompatible features.)

If neither NSR nor PIM is enabled on the router to be upgraded or if one of the unsupported PIM features is enabled but NSR is not enabled, no additional steps are necessary and you can use the standard upgrade procedure described in other sections of these instructions. If NSR is enabled and no NSR-incompatible PIM features are enabled, use the standard reboot or ISSU procedures described in the other sections of these instructions.

Because the nonstop-routing disable statement was not available in Junos OS Release 9.2 and earlier, if both NSR and an incompatible PIM feature are enabled on a router to be upgraded from Junos OS Release 9.2 or earlier to a later release, you must disable PIM before the upgrade and reenable it after the router is running the upgraded Junos OS and you have entered the nonstop-routing disable statement. If your router is running Junos OS Release 9.3 or later, you can upgrade to a later release without disabling NSR or PIM–simply use the standard reboot or ISSU procedures described in the other sections of these instructions.

To disable and reenable PIM:

  1. On the router running Junos OS Release 9.2 or earlier, enter configuration mode and disable PIM:
    [edit]
    user@host# deactivate protocols pim

    user@host# commit
  2. Upgrade to Junos OS Release 9.3 or later software using the instructions appropriate for the router type. You can either use the standard procedure with reboot or use ISSU.
  3. After the router reboots and is running the upgraded Junos OS, enter configuration mode, disable PIM NSR with the nonstop-routing disable statement, and then reenable PIM:
    [edit]
    user@host# set protocols pim nonstop-routing disable

    user@host# activate protocols pim

    user@host# commit

Downgrading from Release 14.2

To downgrade from Release 14.2 to another supported release, follow the procedure for upgrading, but replace the 14.2 jinstall package with one that corresponds to the appropriate release.

Note: You cannot downgrade more than three releases. For example, if your routing platform is running Junos OS Release 11.4, you can downgrade the software to Release 10.4 directly, but not to Release 10.3 or earlier; as a workaround, you can first downgrade to Release 10.4 and then downgrade to Release 10.3.

For more information, see the Installation and Upgrade Guide.

Changes Planned for Future Releases

  • Support for securing PCEP sessions using MD5 authentication (M Series, MX Series, and T Series)—Starting with Junos OS Release 14.2R4-S7, 15.1F6, 16.1, and later releases, you can secure a Path Computation Element Protocol (PCEP) session using TCP-MD5 authentication as per RFC 5440.

    MD5 authentication protects the communication between a Path Computation Element (PCE) and a Path Computation Client (PCC) over a PCEP session, which might be subject to an attack, and can disrupt network services.

    To enable the MD5 security mechanism for a PCEP session, it is recommended that you define and bind the MD5 authentication key at the [edit protocols pcep pce pce-id] hierarchy level for a PCEP session. You can, however, also use a predefined keychain from the [edit security authentication-key-chains key-chain] hierarchy level to secure a PCEP session. In this case, you should bind the predefined keychain into the PCEP session at the [edit protocols pcep pce pce-id] hierarchy level.

    You can view the authentication keychain used by a PCEP session by executing the show path-computation-client status and show protocols pcep commands.

    [See Support of Path Computation Element Protocol for RSVP-TE Overview.]

  • Introduction of the all keyword to prevent accidental execution of certain clear commands—The all keyword is introduced in Junos OS Release 14.2 (as an optional keyword) and is planned to be introduced in Junos OS Release 15.2 (as a mandatory keyword) for certain clear commands that are used for clearing protocol and neighbor sessions. This makes users explicitly select the all keyword to clear all protocol or session information. Thus, it prevents accidental clearing or resetting of protocols or neighbor sessions, which might disrupt network operations.

    The all keyword is planned to be introduced for the following clear commands:

    • clear arp
    • clear bgp neighbor
    • clear bfd adaptation
    • clear bfd session
    • clear igmp membership
    • clear isis adjacency
    • clear isis database
    • clear ldp neighbor
    • clear ldp session
    • clear mld membership
    • clear mpls lsp
    • clear msdp cache
    • clear multicast forwarding-cache
    • clear (ospf | ospf3) database
    • clear (ospf | ospf3) neighbor
    • clear pim join
    • clear pim join-distribution
    • clear pim register
    • clear rsvp sessions

    In Junos OS Release 14.2 and Release 15.1—The all keyword is optional. When you type any of these clear commands followed by the ? in the CLI, the all keyword is listed as an option after the <[Enter]> keyword. You can execute the clear command directly or with the all keyword to clear all information. For example, when you type clear mpls lsp ?, the following possible completions are displayed:

    user@host> clear mpls lsp ?
    Possible completions:  
    <[Enter]>            Execute this command
    all                  Reset 'all' the nontransit or egress LSPs
                         originating on this router       <<<<<<<<<<<<
    autobandwidth        Clear LSP autobandwidth counters
    logical-system       Name of logical system, or 'all'
    name                 Regular expression for LSP names to match
    optimize             Perform nonpreemptive optimization computation now
    ...
    

    Both clear mpls lsp or clear mpls lsp all will function identically in these releases.

    In Junos OS Release 15.2 and later—The all keyword is mandatory. When you type a clear command followed by the ? in the CLI, the <[Enter]> option to execute the command directly (without specifying any options) is not available.

    For example, when you type clear mpls lsp ?, you see all listed as an option but not <[Enter]> to execute the command directly. You have to type clear mpls lsp all and then press <[Enter]> if you want to clear information about all the nontransit or egress LSPs originating on the router.

    user@host> clear mpls lsp ?
    Possible completions:  
    all                  Reset 'all' the nontransit or egress LSPs
                         originating on this router       <<<<<<<<<<<<
    autobandwidth        Clear LSP autobandwidth counters
    logical-system       Name of logical system, or 'all'
    name                 Regular expression for LSP names to match
    optimize             Perform nonpreemptive optimization computation now
    ...
    

Modified: 2017-12-12