Highlights

General

This release primarily focuses on upgrading key internal components. However, nearly all functionalities and new features introduced in Nozomi Networks Operating System (N2OS) v25.0 have been backported, ensuring that users with restrictive software adoption policies can still benefit from them. Since Vantage users are not usually subject to such restrictive software upgrade policies, all sensors whose N2OS version is managed by Vantage, will be updated to directly to N2OS v25.0.

Centralized Arc management in multi-level architectures

Users can now configure Arc sensors from Vantage and Central Management Console (CMC), even if they are nested multiple levels below in the sensor hierarchy. Configurations set at a higher-level sensor are automatically propagated to the appropriate child sensor, ensuring seamless updates for indirectly connected Arc sensors.

This enhancement streamlines Arc management by centralizing control in Vantage and CMC, eliminating the need for manual configuration at each level. It reduces administrative overhead, saves time, ensures consistency across deployments, and allows teams to manage larger, more complex environments with fewer resources.

Enforced upgrade path for reliable updates

Nozomi Networks on-premises operating system (OS) now enforces upgrade path compliance by blocking firmware upgrades that do not follow the required sequence. If a required prerequisite version is missing, the upgrade is prevented, reducing the risk of failed upgrades and potential resulting system instabilities.

For example, since only sensors with version N2OS v25.x firmware may upgrade to N2OS v26.x, the sensors will block upgrade attempts for sensors running N2OS v24.x. This ensures that all necessary upgrades are applied in the correct order.

This enhancement safeguards sensors from breaking due to improper firmware upgrades, ensuring critical components are upgraded in the correct order. By preventing unsupported upgrade paths, migration issues are minimized, down-time is avoided, and user's time is saved, all while ensuring smoother and more reliable upgrades.

Please note that there could be other reasons impeding an upgrade. Therefore, users facing sensors that do not allow an update should verify the reason by connecting to the sensor via secure shell (SSH) and verifying that the /data/upgrade-failed file indicates only an installation path violation. If that is the case, then the reason for the upgrade refusal has been confirmed to be an upgrade path violation. To properly upgrade the sensor, remove the incorrect update bundle file and proceed with the version upgrade following the officially documented mandatory installation path.

Deprecation of ESXi version lower than 8.0

Starting with N2OS v24.6.0, the lowest compatible version of ESXi is 8.0. This is due to N2OS' adoption of FreeBSD 14.x which is not listed on ESXi's vendor documentation as a supported and compatible version of FreeBSD for an ESXi version lower than 8.0. Nozomi Networks cannot support virtual deployments unless they use the correct ESXi and Nozomi Networks version combination as listed below. This is regardless of whether they are new deployments, or upgrades of existing deployments:

• N2OS v24.6 or higher, Host ESXi v8.0, and virtual hardware version 20, or higher
• N2OS v24.5.1 (released in 2024), Host ESXi v7.0, and virtual hardware version 17

Additional information

Official vendor support for ESXi 7 has been dropped and migration to ESXi 8 is required as of the end of 2024. We urge customers to prepare for implementing all required measures to run N2OS on ESXi 8.

Deprecation of /data UFS filesystem support

N2OS v24.6 is the last version to support the use of the UFS filesystem for /data. All future N2OS versions will only support the ZFS filesystem for /data. Therefore, upgrades attempts of sensors using the UFS filesystem for /data to N2OS v25.x will be blocked.

To facilitate N2OS upgrades, it is necessary to:

1. Upgrade the sensor to version N2OS v24.6.
2. Do a full backup.
3. Execute the n2os-datafactoryreset
4. Proceed with the restoration process.

Refer to this documentation for more information regarding the backup, restore, and n2os-datafactoryreset procedures. Ensure a backup is downloaded from the sensor and saved on safe storage.

For virtual machine sensors, the Add a secondary disk to a virtual machine procedure can be used to move /data from the UFS filesystem to the ZFS. Do a full backup from a shell console and ensure a backup is downloaded from the sensor and saved on safe storage. Make sure that the needed space is available on the destination disk. The procedure may take a long time depending on the virtual infrastructure hardware, its speed, and the size of the /data folder. Interrupting the procedure can cause damage to the virtual machine and data loss.

Customers should not do the procedures above on sensors that are not within the supported versions. In addition, you must always upgrade the sensors following the supported update path before carrying out these steps.