Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Upgrade Routing Director

The upgrade functionality provided by Deployment Shell enables you to upgrade your Routing Director installation and all the applications running on it to the latest release.

You can upgrade to the latest Juniper Routing Director Release 2.8.0 from the following releases.

The upgrade paths to release 2.8.0 from your existing older release are listed below.

  • 2.7.0 → 2.8.0

  • 2.6.0 → 2.8.0

  • 2.5.0 → 2.7.0 → 2.8.0

  • 2.4.1 → 2.7.0 → 2.8.0

  • 2.4.0 → 2.4.1 or 2.5.0 or 2.6.0 → 2.7.0 → 2.8.0

  • 2.3.0 → 2.4.1 or 2.5.0 → 2.7.0 → 2.8.0

  • 2.2.0 → 2.4.1 → 2.7.0 → 2.8.0

  • 2.1.0 → 2.2.0 → 2.4.1 → 2.7.0 → 2.8.0

Here → indicates a direct upgrade.

The upgrade process is automated by a set of Deployment Shell commands and carries out the required system checks, retrieves the upgrade package, and executes the upgrade process on the cluster nodes. You can upgrade using a file that is either downloaded locally on your primary node or downloaded directly from a Web page.

During an upgrade, it is important that no change activities including onboarding of devices, provisioning of services or changing other configurations are done in the system. The upgrade will automatically reboot all components and there will be short unavailability during that time. The upgrade process does not affect the traffic through the network and once the upgrade is complete, the devices and services are not reconfigured.

Note:

We recommend that you back up your configuration before upgrading. For information on back up, see the Backup Routing Director Configuration instructions in the Installation and Upgrade Guide of the release corresponding to your existing release.

You can upgrade to the latest release using the upgrade_routing-director-release-build-ID.img disk image file.

Note: Upgrading using the .img file is possible starting only from release 2.5.0. For releases earlier than release 2.5.0, use the upgrade_routing-director-release-build-ID.tgz compressed archive file to upgrade to a later release.

Perform the following steps to upgrade to Routing Director Release 2.8.0:

  1. Upgrade Prerequisites—Ensure that all upgrade prerequisites are met.

  2. Upgrade the Routing Director Deployment Cluster—Upgrade the cluster using either Upgrade using the local filename Option or Upgrade using the remote url Option.

  3. Upgrade Deployment Shell and the OVA System Files—Upgrade Deployment Shell and the OVA system files on all the cluster nodes.

  4. Post Cluster Upgrade Tasks—Perform all the post cluster upgrade tasks to complete the upgrade process.

Upgrade Prerequisites

Before you upgrade the Routing Director deployment cluster, ensure the following.

  • Deployment Shell is accessible and operational.

  • The VM disk size is increased to match the recommended system requirements. Perform the steps described in Increase VM Disk Size.

  • (Optional) Check the current build and OVA version of your existing release from Deployment Shell using the show deployment version command.

  • The cluster nodes have the following free disk space available:

    • The primary node from which the cluster was deployed must have 15% of the total disk space + two times the upgrade file size free.

    • The remaining primary nodes must have 15% of the total disk space + the same amount space as the upgrade file size free.

    • The worker node must have 15% of the total disk space free.

    To determine the primary and worker nodes as well as the installer node from which the cluster was installed, perform the following steps:

    1. Log in to any of the cluster nodes.

    2. Type exit to exit to the Linux root shell from the Deployment Shell.

    3. Use the kubectl get nodes -o wide command to determine the primary and worker nodes of the cluster.

    4. Use the cat /root/epic/host.main command to determine the installer primary node.

Upgrade the Routing Director Deployment Cluster

Perform the following steps if you want to upgrade to the latest release 2.8.0 from a supported older release.

You can upgrade your installation and all the applications running on it using any one of the local filename or remote url options:

Upgrade using the local filename Option

Use this option for air-gapped environments where your Routing Director installation does not have access to the Internet. However, you need to be able to copy the upgrade and upgrade signature files to your primary node.

If you are downloading the upgrade file locally, note that the file is deleted if the cluster upgrade is successful.

To upgrade to release 2.8.0, perform the following steps.

  1. Log in as root user to the primary node from which the existing cluster was installed. You are logged in to Deployment Shell.

  2. Type exit to exit from Deployment Shell to the Linux root shell.

  3. Copy the upgrade_routing-director-release-build-ID.img file to the /root/epic/temp location on the node.

  4. (Optional) If you want to validate the signature of the upgrade file, copy the corresponding upgrade_routing-director-release-build-ID.img.psig signature filesignature file to the same /root/epic/temp folder.

  5. (Optional) Use the gpg --verify img-psig-file img-file command to validate the digital signature of the upgrade file. For example:

    Here primary1 is the installer primary node. Validation takes a couple of minutes to complete.

  6. Type cli to enter Deployment Shell.

  7. Use the following command to upgrade the Routing Director deployment cluster:

    request deployment cluster upgrade local filename upgrade_routing-director-release-build-ID.img

    For example:

    Here primary1 is the installer primary node. The upgrade command checks the health of the cluster before upgrading. If the cluster health check returns a GREEN status, the cluster is upgraded requiring no further input. If the cluster health check returns a RED status, the cluster is not upgraded. If the cluster health check returns an AMBER status, you are prompted to choose to continue or stop the upgrade.

    Additional upgrade command options:

    You can also use any one or more of the following command options along with the upgrade command while upgrading:

    1. no-confirm—Usage example:

      Use the no-confirm option to ignore the AMBER status and continue with the upgrade without being prompted. However, the no-confirm option does not ignore a RED status.

    2. skip-health-check—Usage example:

      Use the skip-health-check option to skip the pre-upgrade cluster health check performed automatically. However, you must ensure that the cluster is in good health before performing the upgrade.

    3. detach-process—Usage example:

      As the upgrade process takes over an hour to complete, you can let the upgrade run in the background and free up the CLI screen for any other tasks. The command runs the initial health checks and then proceeds with the upgrade. Once the upgrade process starts, the process is detached and moved into the background and you are returned to the command prompt. The upgrade output is logged in the /epic/temp/upgrade.log file. To monitor the status of the upgrade process and print the output onscreen, use the monitor start /epic/temp/upgrade.log command. When the upgrade process completes, a success message similar to the following is displayed on all the cluster nodes:

      If you get disconnected from the VM during the upgrade process, you can periodically check the upgrade log file for status on the upgrade.

    4. input—Usage example:

      Use the input option to pass additional Ansible input parameters to the upgrade command. For example, if you want to enable verbose logging during upgrade, use the -v option.

      request deployment cluster upgrade local filename upgrade_routing-director-release-build-ID.img input "-v"

    Your Routing Director installation and all the applications running on it are upgraded.

    Note that, the upgrade process takes over an hour to complete. If you get disconnected from the VM during the upgrade process, you can periodically check the upgrade log file until you see an output similar to this:

  8. Upgrade Deployment Shell and the OVA system files.

    Go to Upgrade Deployment Shell and the OVA System Files.

Upgrade using the remote url Option

Use this option if your Routing Director installation has access to the Internet and the upgrade file is in a remote location.

To upgrade release 2.8.0, perform the following steps.

  1. Log in as root user to the primary node from which your existing cluster was installed. You are logged in to Deployment Shell.

  2. Use the following command to upgrade the Routing Director deployment cluster:

    request deployment cluster upgrade remote url "https://juniper.software.download.site/upgrade_routing-director-release-build-ID.img?query_string"

    For example:

    Here primary1 is the installer primary node. The upgrade command checks the health of the cluster before upgrading. If the cluster health check returns a GREEN status, the cluster is upgraded requiring no further input. If the cluster health check returns a RED status, the cluster is not upgraded. If the cluster health check returns an AMBER status, you are prompted to choose to continue or stop the upgrade.

    Additional upgrade command options:

    You can also use any one or more of the following command options along with the upgrade command while upgrading:

    1. no-confirm—Usage example:

      Use the no-confirm option to ignore the AMBER status and continue with the upgrade without being prompted. However, the no-confirm option does not ignore a RED status.

    2. skip-health-check—Usage example:

      Use the skip-health-check option to skip the pre-upgrade cluster health check performed automatically. However, you must ensure that the cluster is in good health before performing the upgrade.

    3. detach-process—Usage example:

      As the upgrade process takes over an hour to complete, you can let the upgrade run in the background and free up the CLI screen for any other tasks. The command runs the initial health checks and then proceeds with the upgrade. Once the upgrade process starts, the process is detached and moved into the background and you are returned to the command prompt. The upgrade output is logged in the /epic/temp/upgrade.log file. To monitor the status of the upgrade process and print the output onscreen, use the monitor start /epic/temp/upgrade.log command. When the upgrade process completes, a success message similar to the following is displayed on all the cluster nodes:

    4. input—Usage example:

      Use the input option to pass additional Ansible input parameters to the upgrade command. For example, if you want to enable verbose logging while upgrading, use the -v option.

      request deployment cluster upgrade remote url "https://juniper.software.download.site/upgrade_routing-director-release-build-ID.img?query_string" input "-v"

    Your Routing Director installation and all the applications running on it are upgraded.

    Note that, the upgrade process takes a little over an hour to complete. If you get disconnected from the VM during the upgrade process, you can periodically check the upgrade log file until you see an output similar to this:

  3. Upgrade Deployment Shell and the OVA system files.

    Go to Upgrade Deployment Shell and the OVA System Files.

Upgrade Deployment Shell and the OVA System Files

When your Routing Director installation and all the applications running on it are successfully upgraded, you must upgrade Deployment Shell and the OVA system files.

  1. Type exit to exit from the installer primary node Deployment Shell to the Linux root shell.

  2. Execute the Deployment Shell upgrade script.

    The Deployment Shell and the OVA system files are upgraded.

  3. (Optional) Check the build and OVA version of your upgraded cluster from Deployment Shell.

Important:

Ensure that the upgraded cluster is healthy and operational. Execute the request deployment health-check command before you proceed.

The Overall Cluster Status must be GREEN.

Proceed to perform the post cluster upgrade tasks. See Post Cluster Upgrade Tasks.

Related Documentation