Network Management

VNQM: IP SLA DNS Target 1.0.0.1 Displays as 0.0.0.0

When monitoring Cisco Nexus IP SLA DNS operations in VNQM 2024.2, an operation configured with DNS server 1.0.0.1 on the device is displayed in VNQM as probing 0.0.0.0. Other DNS targets (for example 8.8.4.4) on the same device display correctly. A separate UI issue causes IP SLA operation names containing -> to render as the HTML entity -> in the wizard and graphs. Investigation determined that the incorrect DNS IP is caused by a Cisco NX‑OS firmware defect, while the HTML entity display is a VNQM UI bug.

First published date

8/3/2026 8:35 PM

Last published date

8/3/2026 8:54 PM

Overview

  • Product: SolarWinds VNQM

  • Version: 2024.2 (SolarWinds Observability Self‑Hosted Enterprise)

  • Vendor device: Cisco Nexus switch (NX‑OS)

  • Feature: IP SLA DNS operations monitored in VNQM

 

ROOT CAUSE

 

  • The incorrect DNS IP (0.0.0.0) shown in VNQM for DNS target 1.0.0.1 is caused by a Cisco NX‑OS firmware issue in how the device exposes the DNS server IP in the CISCO‑RTTMON‑MIB.

    • Instead of returning a 4‑byte hex string for the IP address, the device returns only a single byte for 1.0.0.1.

    • VNQM relies on the SNMP data to render the IP address; because the SNMP payload from the device is malformed, VNQM displays an incorrect value.

  • The separate issue where operation names containing -> appear as -> is a VNQM UI HTML encoding issue where the operation name is HTML‑encoded twice.

 

https://bst.cisco.com/quickview/bug/CSCwv67387

Product section

VoIP & Network Quality Manager

Cause

  • In VNQM IP SLA operation details, the DNS server for the affected operation appears as 0.0.0.0 instead of the configured 1.0.0.1.

  • Other DNS IPs (for example, 8.8.4.4) on the same Nexus device display correctly.

  • IP SLA operation names containing -> are rendered with the encoded string -> in VNQM UI pages (wizard result screen and graphs).




You add existing IP SLA DNS operations on a Nexus switch into VNQM using:

  • Network Service Assurance Management → Manage Service Assurance Operations → Add new operations

  • Option: Monitor existing operations → Automatically discover existing operations

Two DNS operations exist on the same Nexus device:

  • Operation 11: DNS to 8.8.4.4 (working)

  • Operation 12: DNS to 1.0.0.1 (problem)

Observed behavior in VNQM:

  • For operation 11, VNQM correctly displays the DNS server as 8.8.4.4.

  • For operation 12, VNQM displays the DNS server as 0.0.0.0, even though the device is configured with 1.0.0.1.

Additional UI symptom:

  • IP SLA operation names that contain -> (for example, DNS Google -> 8.8.4.4) show up in the VNQM wizard and graphs as the literal string -> instead of ->.

Resolution

Troubleshooting

  1. Validate device configuration

    On the Nexus device, run for both operations:

    Example (summarized):

    • Operation 11 (working)

      • Type: dns

      • Target: google.com

      • Name Server: 8.8.4.4

    • Operation 12 (issue)

      • Type: dns

      • Target: cloudflare.com

      • Name Server: 1.0.0.1

    Result: Device CLI shows the correct Name Server values (including 1.0.0.1) and operations are Active with valid statistics.

  2. Confirm SLA is functioning on the device

     show ip sla statistics <op_id>

    • RTT and statistics are valid.

    • No failures are reported.

    Conclusion: the IP SLA operations themselves are healthy on the Nexus; this is not a configuration failure.

  3. Compare VNQM display for working vs non‑working DNS IP

    • Operation with DNS 8.8.4.4 displays correctly in VNQM.

    • Operation with DNS 1.0.0.1 displays as 0.0.0.0 in VNQM.

    Since both operations are on the same device with the same operation type, this points away from device configuration and toward how data is exposed/parsed.

  4. Collect and review SNMP walk of CISCO‑RTTMON‑MIB

    From the device, collect an SNMP walk (for example, indices 11 and 12 for the affected operations). Engineering analysis of the customer walk showed:

    • Target (string) OID returns correct hostnames:

      • ...1.11 = STRING: "google.com"

      • ...1.12 = STRING: "cloudflare.com"

    • Name Server (IP) OID for the working operation returns a valid 4‑byte hex string (example for 8.8.4.4):

      • ...1.12.11 = HEX-STRING: 08 08 04 04

    • Name Server (IP) OID for the problematic operation returns only a single byte instead of 4 (example for 1.0.0.1):

      • ...1.12.12 = HEX-STRING: 01

    This is invalid encoding for an IPv4 address and explains why VNQM cannot display 1.0.0.1 correctly; the device is not sending a 4‑byte IP in the MIB.

  5. Vendor confirmation

    Cisco supported reproduced the issue and created bug ID CSCwv67387 for this NX‑OS issue (observed at least on versions 9.3(12) and 10.4(3)). The behavior was confirmed to be a device‑side firmware defect trimming leading zeros from the IP representation exposed via SNMP.

 

Resolution / Workarounds

A. Incorrect DNS IP (1.0.0.1 shown as 0.0.0.0)

Because the defect is on the device side, the effective resolutions are on the Nexus:

  1. Upgrade Nexus firmware

    • Work with Cisco TAC and reference bug CSCwv67387.

    • Upgrade the Nexus switch to an NX‑OS release where the bug is fixed.

    • After upgrade, re‑validate by performing a fresh SNMP walk of the IP SLA MIB and confirming the DNS server IP is returned as a 4‑byte value.

  2. Avoid problematic DNS IPs on affected versions (workaround)

    • While the device is still on an affected NX‑OS version, configure DNS targets that do not trigger the trimming/encoding defect.

    • For example, use 8.8.4.4 or 1.1.1.1 rather than 1.0.0.1.

    • Once the device exposes a valid 4‑byte IP via SNMP, VNQM will display the DNS server address correctly without any SolarWinds‑side changes.