Junos Node Slicing Upgrade

Upgrading JDM for External Server Model

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:

      content_copy zoom_out_map

      root@Linux server0# jdm stop
      Stopping JDM

   3. Issue the upgrade command to upgrade the JDM package:

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

      content_copy zoom_out_map

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

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

      content_copy zoom_out_map

      root@Linux server0# dpkg -i package.deb

      Note:

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

      • Before upgrading JDM, ensure that both JDM deployments are in sync. This means:

        • Junos running on a given GNF should support the same SMBIOS version across both the servers.

        • Before upgrade, ensure that all GNFs exist on both the servers.

      • After upgrading both the JDM servers, you must run commit synchronize before configuring any new GNF. If you do not run commit synchronize and create new GNFs on server1, you will not be able to do commit synchronize later from server0 to server1.

      • You must upgrade both the JDMs.

      See also:

      • Installing JDM RPM Package on x86 Servers Running RHEL (External Server Model)

      • Installing JDM Ubuntu Package on x86 Servers Running Ubuntu 20.04 (External Server Model)

Upgrading JDM to Support Podman-based Deployment (23.2R1)

Starting in Junos OS Release 23.2R1, the external server-based Junos node slicing supports deployment of Juniper Device Manager (JDM) using the Pod Manager tool (podman). Only the servers running Red Hat® Enterprise Linux® (RHEL) 9 or later versions support podman.

In Junos releases prior to 23.2R1, the external server-based Junos node slicing supported RHEL 7.3, which provided libvirt’s lxc driver (libvirt-lxc) to deploy JDMs.

To upgrade your libvirt-lxc-based JDM to a podman-based version, follow the steps below on both the servers:

1. Check if the random MAC prefixes generated by the JDM on both the servers are the same.

   content_copy zoom_out_map

   user@jdm> show system random-mac-prefix all-servers

2. Back up your JDM configuration to /host/tmp/ folder.

   content_copy zoom_out_map

   user@jdm> request system save state path /host/tmp/jdm-backup.tgz
   Backup Done at:[/host/tmp/jdm-backup.tgz]

   This step backs up the JDM configuration and the random-mac-prefix value. The MAC prefix forms part of MAC addresses associated with unlicensed guest network function (GNF).

3. Uninstall the JDM on each server. For more information, see Managing Junos Node Slicing.

4. Upgrade the host OS to RHEL 9.

5. Install the podman-based JDM. This is a regular installation process. To install JDM, use the steps provided in Installing JDM RPM Package on x86 Servers Running RHEL (External Server Model).

6. Restore the JDM backup.

   content_copy zoom_out_map

   user@jdm> request system restore state path /host/tmp/jdm-backup.tgz
   Backup Restored from:[/host/tmp/jdm-backup.tgz]

7. After performing the above steps on both the servers, verify if the random MAC prefixes generated by the JDM on both the servers are the same.

   content_copy zoom_out_map

   user@jdm> show system random-mac-prefix all-servers

Upgrading JDM for In-Chassis Model

1. Upgrade the JDM by performing the following tasks on the BSYS instance of both the routing engines:

   1. Copy the new JDM RPM package to a directory (for example, /var/tmp).

   2. Stop the JDM by running the following command:

      content_copy zoom_out_map

      root@router> request vmhost jdm stop

   3. Install the JDM RPM package for in-chassis Junos node slicing, by using the command shown in the following example:

      content_copy zoom_out_map

      root@router> request vmhost jdm add jns-jdm-vmhost-18.3-20180930.0.x86_64.rpm

      Note:

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

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.

Ensure that all GNFs are online when you perform an upgrade. This is because both GNF and BSYS upgrade processes trigger multiversion checks (covered later in this guide), and all GNFs are required to be online during the multiversion check phase, failing which the upgrade will be terminated. In case a GNF remains shut down, you must deactivate its configuration from BSYS CLI, which will result in skipping multiversion checks for that particular GNF.

Upgrading JDM to Support WRL 9 based VM Host - In-Chassis Model

If the Routing Engine is to run Junos OS 19.3R1 or later, you must upgrade JDM to 19.3R1 or later.

Use the following steps to upgrade the JDM.

1. At each of the GNFs, assign primary role to the backup GNFs running on Routing Engine1 (re1).

   content_copy zoom_out_map

   root@router> request chassis routing-engine master switch no-confirm

2. On re0, first stop the GNFs from the JDM, and then stop the JDM itself from BSYS.

   content_copy zoom_out_map

   root@jdm> request virtual-network-functions stop gnf-name
   root@router> request vmhost jdm stop

3. Ensure that re0 VM Host version is Junos OS 19.3R1 or later. To check the VM Host version, use the Junos CLI command show vmhost version.

   You can use the following Junos CLIs to upgrade VM Host software:

   content_copy zoom_out_map

   root@router> request vmhost software add package-name
   root@router> request vmhost reboot

   For more information, see Installing, Upgrading, Backing Up, and Recovery of VM Host.

4. When re0 is back up after the reboot, copy the new JDM RPM package (19.3R1 or later) to a directory (for example, /var/tmp).

5. Install the new JDM RPM package on re0 and then start the JDM.

   content_copy zoom_out_map

   root@router> request vmhost jdm add package-name
   root@router> request vmhost jdm start

   The GNFs on re0 automatically start after this step.

6. Repeat the steps 1 to 5 on Routing Engine 1 (r1).

7. Run the request server authenticate-peer-server command at the JDM on both the Routing Engines.

   content_copy zoom_out_map

   user@jdm> request server authenticate-peer-server

8. Configure set system commit synchronize and then apply commit on re0 JDM.

   content_copy zoom_out_map

   user@jdm# set system commit synchronize
   user@jdm# commit synchronize

Steps to Apply Host OS Security Updates

Applying security updates to host OS will likely require you to reboot the external x86 servers. See the Updating Host OS on the External Servers topic.

It is also possible that a host OS security update will bring in a new kernel version. Updating the host OS kernel could also overwrite the Intel i40e driver to bring in a version of it that does not meet the i40e driver minimum version requirements. If so, you must update the i40e driver to meet the minimum requirements. For more details, see Updating Intel X710 NIC Driver for x86 Servers.

Before rebooting the external x86 servers, you must stop all GNF VMs and JDM on that server. Since we have two external x86 servers, the host OS Security Updates can be done without disrupting GNF forwarding, by updating one server at a time. A GRES/NSR Primary Routing Engine switch-over is required to move the Primary Routing Engine away from the affected server.

We start with the default behavior of Routing Engine 1 (re1) as the Backup Routing Engine for each GNF where re1 for each GNF is running on the external x86 server1.

1. Back up all configurations.

2. Gather view of host OS kernel and package versions on the external x86 servers before the host OS security update. Also confirm i40e driver and Intel X710 firmware meet minimum requirements (version: 2.4.10 and version: 18.5.17).

   content_copy zoom_out_map

   user@server# cat /etc/redhat-release
   user@server# uname -r
   user@server# uname -a
   user@server# rpm -q kernel
   user@server# ethtool -i p3p1

3. Ensure that RedHat Subscription Manager is set to RHEL 7.3 and the EUS Repository is enabled.

   content_copy zoom_out_map

   [user@server ~]# subscription-manager version
   [user@server ~]# subscription-manager repos --list | grep rhel-7-server-eus-rpms

4. Ensure all GNFs are using Primary RE on server0. The backup Routing Engine is re1 on server1. First perform host OS security updates on the server that contains the backup Routing Engines.

   content_copy zoom_out_map

   user@router> show chassis routing-engine

   Run this command on all the GNFs to confirm that all the GNFs have their primary Routing Engine on server0.

5. Stop all GNF VMs in JDM cli via request stop on server1 only. server1 contains the backup Routing Engines for all the GNFs. Do not use the all-servers option. Example:

   content_copy zoom_out_map

   user@jdm> request virtual-network-functions gnf-a stop server 1
   user@jdm> request virtual-network-functions gnf-b stop server 1

6. Stop JDM on the affected server from the host OS.

   content_copy zoom_out_map

   user@server# jdm status
   user@server# jdm stop

7. Do the yum security update and reboot the server.

   content_copy zoom_out_map

   user@server# yum -y update -security
   root@server# shutdown -r now

8. Reload or compile the i40e Driver. See the Intel support page for instructions on updating the driver.

   At this point, the host OS security update to server1 is done. Note that the GNF VMs start up on server reboot.

9. After the security updates are completed, the server rebooted and the GNFs are back up, repeat on the other server.