Network Management

VNQM IP SLA Operations Go UNKNOWN Instead of Unreachable When Parent Node Goes Down

When a parent router node goes Down during a full connectivity loss, VNQM IP SLA operations configured as children in a group-based dependency go to UNKNOWN instead of Unreachable. This occurs because VNQM sets the operations to UNKNOWN when the SNMP poll times out, and the dependency engine does not evaluate UNKNOWN-status children for Unreachable marking. This article explains the root cause and provides two workaround options to suppress IP SLA alerts when the parent node is Down.

First published date

6/23/2026 10:43 PM

Last published date

6/23/2026 11:30 PM

Overview

Environment

  • SolarWinds Platform 2024.2 and later

  • VoIP and Network Quality Manager (VNQM)

Symptoms

  • VNQM IP SLA operations are configured as members of a group that is the child in a node dependency (parent = router node, child = group of IP SLA operations).

  • When only ICMP is blocked between the polling engine and the router, the dependency works correctly. The IP SLA operations transition to DOWN and the dependency engine marks them as Unreachable.

  • When all IP is blocked (full outage), the IP SLA operations go to UNKNOWN instead of DOWN or Unreachable. The dependency does not take effect, and IP SLA alerts fire even though the parent router is Down.

  • The Status Message on the affected operations shows: "Poll timed out. Device may be down, busy, or the SNMP credentials are invalid."

Product section

VoIP & Network Quality Manager

Cause

Two behaviors contribute to this issue:

1. VNQM sets IP SLA operations to UNKNOWN on SNMP timeout

When all IP connectivity to the router is lost, VNQM cannot reach the router via SNMP to poll the IP SLA operation data. The SNMP poll times out and VNQM returns empty results. Because no data was retrieved, VNQM sets the IP SLA operations to UNKNOWN (VoipOperationStatusID = 0) instead of DOWN.

When only ICMP is blocked, SNMP remains available. VNQM can still poll the IP SLA operation data on the router, the probes report actual failure metrics, and the operations transition to DOWN. The dependency engine then correctly marks them as Unreachable.

2. The dependency engine does not evaluate UNKNOWN children for Unreachable

The dependency engine evaluates children for Unreachable marking only when they are in a DOWN state. Since the IP SLA operations are UNKNOWN, the dependency engine does not process them through the dependency chain. Even after the parent node transitions to DOWN, the UNKNOWN children are not re-evaluated and are never marked as Unreachable.

Additionally, VNQM SNMP polling detects the failure faster than ICMP node status polling because the VNQM polling frequency (typically 10 seconds) is shorter than the node status polling interval (default 120 seconds plus fast-poll retries before declaring Down). The IP SLAs go UNKNOWN before the parent node transitions to DOWN. At the time of the status change, the dependency engine has no Down parent to evaluate against.

Resolution

The dependency does not handle this scenario as expected. The workaround is to configure the IP SLA alert with a parent node status condition so it only fires when the parent router is Up. This can be done using either a Custom SQL alert or the standard alert wizard. Both options use a single alert that covers all routers — no per-node alert configuration is required.

Option 1: Custom SQL Alert

If the existing IP SLA alert uses a Custom SQL trigger with object type "IP SLA QoS," add the Nodes table and a node status condition to the existing SQL.

Example — original SQL:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT VoIPOperationCurrentStats.OperationName, VoIPOperationCurrentStats.VoipOperationInstanceID FROM VoIPOperationCurrentStats , NodesCustomProperties NCP WHERE SourceNodeID = NCP.NodeID AND NCP.AlertOnCall = 1 AND OperationName LIKE '%Primary%' AND VoipOperationStatusID <> 1 /*UP*/ AND VoipOperationStatusID <> 3 /*WARNING*/ AND VoipOperationStatusID <> 12 /*UNREACHABLE*/

Example — modified SQL:

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

SELECT VoIPOperationCurrentStats.OperationName, VoIPOperationCurrentStats.VoipOperationInstanceID FROM VoIPOperationCurrentStats , NodesCustomProperties NCP , Nodes N WHERE SourceNodeID = NCP.NodeID AND SourceNodeID = N.NodeID AND NCP.AlertOnCall = 1 AND OperationName LIKE '%Primary%' AND VoipOperationStatusID <> 1 /*UP*/ AND VoipOperationStatusID <> 3 /*WARNING*/ AND VoipOperationStatusID <> 12 /*UNREACHABLE*/ AND VoipOperationStatusID <> 0 /*UNKNOWN*/ AND N.Status <> 2 /*Node is not DOWN*/

The additions are:

  • , Nodes N in the FROM clause adds the Nodes table using the same implicit JOIN pattern

  • AND SourceNodeID = N.NodeID links each IP SLA operation to its parent router node

  • AND VoipOperationStatusID <> 0 excludes UNKNOWN status, which is the status VNQM sets when the SNMP poll times out during a full outage

  • AND N.Status <> 2 excludes IP SLAs whose parent router node is DOWN

The SourceNodeID = N.NodeID join dynamically evaluates the parent node status for each IP SLA operation at alert evaluation time. A single alert covers all routers.

Option 2: Standard Alert Wizard

Use the out-of-the-box alert "Alert me when an IP SLA operation fails" as a starting point:

  1. Navigate to Alerts & Activity > Alerts in the SolarWinds web console

  2. Locate the out-of-the-box alert Alert me when an IP SLA operation fails

  3. Click Duplicate & Edit to create a customizable copy

  4. On the Properties page, rename the alert (e.g., "IP SLA Down - Parent Up Only")

  5. On the Trigger Condition page, configure the following condition groups:

    • Condition Group 1 (ALL of the following): - Node Status is not equal to Down - Node Status is not equal to Unreachable

      • Condition Group 2 (ANY of the following):

        • Operation Status is equal to Down

        • Operation Status is equal to Warning

        • Operation Status is equal to Critical

  6. On the Scope of Alert page, scope the alert to the relevant IP SLA operations or group

  7. On the Reset Condition page, set the reset to trigger when Operation Status is equal to Up

  8. Configure Trigger Actions and Reset Actions as needed (email, log to event, etc.)

  9. Click Submit to save the alert

The "Node Status is not equal to Down" condition applies dynamically to the parent node of each IP SLA operation at evaluation time. A single alert covers all routers.

Expected Outcome

With either option configured:

  • Parent router is Down, IP SLAs go UNKNOWN — the alert does not fire

  • Parent router is Down, IP SLAs go DOWN — the alert does not fire

  • Parent router is Up, IP SLA goes DOWN/Warning/Critical — the alert fires as expected

This achieves the same alert suppression during a full outage that the dependency was intended to provide.