NVIDIA NetQ 4.9 Release Notes

Download 4.9 Release Notes xls    Download all 4.9 release notes as .xls

4.9.0 Release Notes

Open Issues in 4.9.0

Issue IDDescriptionAffectsFixed
When you upgrade NetQ cluster deployments with DPUs in the device inventory, the DPUs might not be visible in the NetQ UI after the upgrade. To work around this issue, restart the DTS container on the DPUs in your network.4.9.0
When you upgrade NetQ cluster deployments, the configured LCM credential profile assigned to switches in the inventory is reset to the default access profile. To work around this issue, reconfigure the correct access profile on switches before managing them with LCM after the upgrade.4.9.0
When you attempt to delete a scheduled trace using the NetQ UI, the trace record is not deleted.4.7.0-4.9.0
After you upgrade NetQ, devices that were in a rotten state before the upgrade might not appear in the UI or CLI after the upgrade. To work around this issue, decommission rotten devices before performing the upgrade.4.9.0
When you perform a switch discovery by specifying an IP range, an error message is displayed if switches included in the range have different credentials. To work around this issue, batch switches based on their credentials and run a switch discovery for each batch.4.9.0
When you perform a NetQ upgrade, the upgrade might fail with the following error message:
Command ‘[‘kubectl’, ‘version –client’]’ returned non-zero exit status 1.
To work around this issue, run the netq bootstrap reset keep-db command and then reinstall NetQ using the netq install command for your deployment.
When you perform a netq bootstrap reset on a NetQ cluster VM and perform a fresh install with the netq install command, the install might fail with the following error:
 master-node-installer: Running sanity check on cluster_vip: Virtual IP is already used
To work around this issue, run the netq install command again.
When you upgrade NetQ from a version prior to 4.9.0, What Just Happened data that was collected before the upgrade is no longer present.4.9.0
In a NetQ cluster environment, if your master node goes offline and is restored, subsequent NetQ validations for MLAG and EVPN might unexpectedly indicate failures. To work around this issue, either restart NetQ agents on devices in the inventory or wait up to 24 hours for the issue to clear.4.9.0
When you install a NetQ cluster deployment on a subnet with other NetQ clusters or other devices using VRRP, there might be connectivity loss to the cluster virtual IP (VIP). The VIP is established using the VRRP protocol, and during cluster installation a virtual router ID (VRID) is selected. If another device on the subnet running VRRP selects the same VRID, connectivity issues may occur. To work around this issue, avoid multiple VRRP speakers on the subnet, or ensure the VRID used on all VRRP devices is unique. To validate the VRID used by NetQ, check the assigned virtual_router_id value in /mnt/keepalived/keepalived.conf.4.9.0
When you upgrade a switch running Cumulus Linux using NetQ LCM, any configuration files in /etc/cumulus/switchd.d for adaptive routing or other features are not restored after the upgrade. To work around this issue, manually back up these files and restore them after the upgrade.4.9.0
After you upgrade NetQ, data from snapshots taken prior to the NetQ upgrade will contain unreliable data and should not be compared to any snapshots taken after the upgrade. In cluster deployments, snapshots from prior NetQ versions will not be visible in the UI.4.9.0
When you reconfigure a VNI to map to a different VRF or remove and recreate a VNI in the same VRF, NetQ EVPN validations might incorrectly indicate a failure for the VRF consistency test.4.9.0
When there is a NetQ interface validation failure for admin state mismatch, the validation failure might clear unexpectedly while one side of the link is still administratively down.4.9.0
When you reboot the master node of a NetQ cluster deployment, NIC telemetry is no longer collected. To recover from this issue, restart the Prometheus pod with the following commands:
1. Retrieve the Prometheus pod name with the kubectl get pods | grep netq-prom command
2. Restart the pod by deleting the pod name with the kubectl delete pod command
cumulus@netq-server:~$ kubectl get pods | grep netq-prom
netq-prom-adapter-ffd9b874d-hxhbz 2/2 Running 0 3h50m
cumulus@netq-server:~$ kubectl delete pod netq-prom-adapter-ffd9b874d-hxhbz
When you export events from NetQ to a CSV file, the timestamp of the exported events does not match the timestamp reported in the NetQ UI based on the user profile’s time zone setting.4.9.0
When you export digital optics table data from NetQ, some fields might be visible in the UI that are not exported to CSV or JSON files.4.9.0
When you run a NetQ trace and specify MAC addresses for the source and destination, NetQ displays the message “No valid path to destination” and does not display trace data.4.9.0
When you upgrade a Cumulus Linux switch configured for TACACS authentication using NetQ LCM, the switch’s TACACS configuration is not restored after upgrade.4.8.0-4.9.0
After you decommission a switch, the switch’s interfaces are still displayed in the NetQ UI in the Interfaces view.4.9.0
After you upgrade NetQ and try to decommission a switch, the decommission might fail with the message “Timeout encountered while processing.”4.8.0-4.9.0
The legacy topology diagram might categorize devices into tiers incorrectly. To work around this issue, use the updated topology diagram by selecting Topology Beta in the latest version of the NetQ UI.4.7.0-4.9.0
LCM operations using in-band management are unsupported on switches that use eth0 connected to an out-of-band network. To work around this issue, configure NetQ to use out-of-band management in the mgmt VRF on Cumulus Linux switches when interface eth0 is in use.4.8.0-4.9.0
When you upgrade a Cumulus Linux switch using NetQ LCM, NetQ presents a warning indicating that there are unsaved NVUE configuration changes when NVUE is not in use and no NVUE configuration is present on the switch. You can safely ignore this warning.4.9.0
When you upgrade an on-premises NetQ deployment, the upgrade might fail with the following message:
master-node-installer: Upgrading NetQ Appliance with tarball : /mnt/installables/NetQ-4.9.0.tgz
master-node-installer: Migrating H2 db list index out of range.
To work around this issue, re-run the netq upgrade command.

Fixed Issues in 4.9.0

Issue IDDescriptionAffects
After performing a new NetQ cluster installation, some MLAG and EVPN NetQ validations might incorrectly report errors. To work around this issue, run the netq check mlag legacy and netq check evpn legacy commands instead of running a default streaming check.4.8.0
When you upgrade a Cumulus Linux switch running the nslcd service with NetQ LCM, the nslcd service fails to start after the upgrade. To work around this issue, manually back up your nslcd configuration and restore it after the upgrade.4.8.0
NetQ does not display queue histogram data for switches running Cumulus Linux 5.8.0 and NetQ agent version 4.8.0. To work around this issue, upgrade the NetQ agent package to
The opta-check command does not properly validate if the required 16 CPU cores are present on the system for NetQ. The command only presents an error if there are fewer than 8 CPU cores detected.4.2.0-4.8.0
After upgrading a NetQ VM with LDAP authentication configured, adding a new LDAP user to NetQ fails with the error message “LDAP not enabled.”4.8.0
When you use the NetQ agent on a Cumulus Linux switch to export gNMI data and there is a period of inactivity in the gNMI stream, the NetQ agent service might stop. To recover from this issue, restart the service with the netq config restart agent command.4.7.0-4.8.0
The medium Validation Summary card might incorrectly display a failure or lack of data for the latest time interval. To work around this issue, expand the card to the largest view for an accurate representation of validation results.4.8.0
The OPTA-on-switch service does not send agent data when the NetQ CLI is not configured. To work around this issue, configure the NetQ CLI on the switch.4.8.0
When you perform an LCM upgrade of Cumulus Linux on a switch using the netq lcm upgrade cl-image CLI command, an error message of NetQ cloud token invalid is displayed though the upgrade completes successfully. This issue is not encountered when using the NetQ LCM UI to perform the upgrade.4.8.0
The topology graph might show unexpected connections when devices in the topology do not have LLDP adjacencies.4.8.0
After you upgrade your on-premises NetQ VM from version 4.7.0 to 4.8.0, NIC telemetry using the Prometheus adapter is not collected. To work around this issue, run the following commands on your NetQ VM:
sudo kubectl set image deployment/netq-prom-adapter netq-prom-adapter=docker-registry:5000/netq-prom-adapter:4.8.0
sudo kubectl set image deployment/netq-prom-adapter prometheus=docker-registry:5000/prometheus-v2.41.0:4.8.0
NetQ cloud deployments might unexpectedly display validation results for checks that did not run on any nodes.4.6.0-4.8.0
EVPN and RoCE validation cards in the NetQ UI might not display data when Cumulus Linux switches are configured with high VNI scale.4.6.0-4.8.0