Junos Node Slicing Upgrade

 

Junos Node Slicing upgrade involves upgrading Juniper Device Manager (JDM), guest network functions (GNFs), and the base system (BSYS).

Upgrading Junos Node Slicing

Junos Node Slicing comprises three types of software components:

  • Juniper Device Manager (JDM) package

  • Junos OS image for guest network function (GNFs)

  • Junos OS package for base system (BSYS)

You can upgrade each of these components independently, as long as they are within the allowed range of software versions (see Multi-Version Software Interoperability Overview for more details). You can also upgrade all of them together.

Note

Before starting the upgrade process, save the JDM, GNF VM, and BSYS configurations for reference.

Upgrading JDM

  1. Upgrade the JDM by performing the following tasks on both the servers:
    1. Copy the new JDM package (RPM or Ubuntu) to a directory on the host (for example, /var/tmp).

    2. Stop the JDM by using the following command:

      root@Linux server0# jdm stop
    3. Issue the upgrade command to upgrade the JDM package:

      If you are upgrading the JDM RHEL package, use the following command:

      root@Linux server0# rpm -U package_name.rpm --force

      If you are upgrading the JDM Ubuntu package, use the following command:

      root@Linux server0# dpkg -i deb package.deb
      Note

      A JDM upgrade does not affect any of the running GNFs.

      See also:

Upgrading GNF and BSYS

The GNF and BSYS packages can be upgraded in the same way as you would upgrade Junos OS on a standalone MX Series router.

Note

You can also overwrite an existing GNF image with a new one through JDM by using the JDM CLI command request virtual-network-functions vnf-name add-image new-image-name force. This can be useful in a rare situation where the GNF image does not boot. You can also use the force option to perform a cleanup if, for example, you abruptly stopped an earlier add-image process by pressing Ctrl-C (example: request virtual-network-functions vnf-name delete-image image-name force).

Unified ISSU Support

Junos Node Slicing also supports unified in-service software upgrade (ISSU), enabling you to upgrade between two different Junos OS versions with no disruption on the control plane and with minimal disruption of traffic. You can perform unified ISSU on BSYS and GNFs separately. Also, you can run unified ISSU on each GNF independently—without affecting other GNFs. See also Understanding the Unified ISSU Process.

Note

The multi-version software support restrictions (such as version deviation limits) are applicable to unified ISSU upgrade as well.

Managing Multi-Version Software Interoperability

Junos Node Slicing supports multi-version software interoperability. However, if there are any incompatibilities between software versions, alert messages appear during the software upgrade process or when a GNF or a FRU comes online. When minor incompatibilities occur, you can choose to accept them and proceed. In case of a major incompatibility, you need to either abort the process or use the force option to accept the incompatibility and proceed.

The following are sample messages that appear if incompatibilities are detected during software upgrade:

Sample alert message indicating a minor incompatibility:

user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4-20170703_dev_common.0.tgz

Sample alert message indicating a major incompatibility:

user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz

Sample output showing how to use the 'force' option to proceed with an upgrade:

user@router> request system software add /var/tmp/junos-install-mx-x86-64-17.4I20170713_0718.tgz force

Viewing Software Incompatibility Alarms

After a software update of a GNF or BSYS, if software incompatibilities between the GNF and the BSYS exist, they will be raised as a chassis alarm. You can view the incompatibility alarm information by using the show chassis alarms command. You can further view the details of the incompatibilities by using the show system anomalies command. For more details, see Viewing Incompatibilities Between Software Versions.

The alarms appear only on GNFs even if the upgrade is performed on the BSYS. The following types of alarm can occur:

  • System Incompatibility with BSYS—This is a major alarm. It appears when any incompatibilities between BSYS and GNF software versions cause the GNF to go offline.

  • Feature Incompatibility with BSYS—This is a minor alarm. It indicates a minor incompatibility between BSYS and GNF software versions. This does not cause the GNF to go offline.

Viewing Incompatibilities Between Software Versions

To view software incompatibilities from the BSYS, use the CLI as shown in the following example:

user@router> show system anomalies gnf-id 4 system

To view software incompatibilities from a GNF, use the CLI as shown in the following example:

user@router> show system anomalies system
Note
  • As shown in the CLI, remember to specify the GNF ID while viewing the incompatibilities from BSYS.

  • The preceding examples show system-level incompatibilities. Use the fru or config options to view FRU or feature-level incompatibilities.

Restarting External Servers

Server maintenance activities such as hardware or host OS upgrade and fault isolation might require you to restart the external servers used in Junos Node Slicing. Use the following procedure to restart the servers:

  1. Stop all the GNFs.

    If you are restarting both the servers, choose the all-servers option while stopping each GNF as shown in the following example:

    root@server1> request virtual-network-functions gnf_name stop all-servers

    If you are restarting a particular server, stop the GNFs on that server by specifying the server-id as shown in the following example:

    root@server1> request virtual-network-functions gnf_name stop server0
  2. Verify that the GNFs have been stopped.
    root@server1> show virtual-network-functions
    Note

    If you want to view the status of GNFs on both the servers, choose the all-servers option. Example: show virtual-network-functions all-servers).

  3. From the Linux host shell, stop the JDM by using the following command:
    [root@HostLinux ~]# jdm stop
  4. From the Linux host shell, verify that the JDM status shows as stopped.
    [root@HostLinux ~]# jdm status
  5. After rebooting, verify that the JDM status now shows as running.
    [root@HostLinux ~]# jdm status

After a server reboot, the JDM and the configured GNFs will automatically start running.

If you are replacing the servers, ensure that the operating server pair continues to have similar or identical hardware configuration. If the server pair were to become temporarily dissimilar during the replacement (this could be the case when replacing the servers sequentially), it is recommended that you disable GRES and NSR for this period, and re-enable them only when both the servers are similar once again.

Updating Host OS on the External Servers

Before updating the host OS on an external server, you must first stop the GNFs and JDM on that server as described in Restarting External Servers.

Following the host OS update, if you are using Intel X710 NICs, ensure that the version of the X710 NIC driver in use continues to be the latest version as described in Updating Intel X710 NIC Driver for x86 Servers .