Network Management

Juniper RPM operations are not discovered in VNQM

When monitoring Juniper MX/EX/SRX devices in VNQM 2025.4 and earlier, the Manage Network Service Assurance Operations discovery wizard returns an empty operations list even though RPM probes are configured and producing results on the device.

First published date

6/17/2026 10:08 PM

Last published date

6/17/2026 10:14 PM

Overview

Environment

  • SolarWinds Platform 2025.4.x and earlier

  • VoIP and Network Quality Manager (VNQM) 2025.4 and earlier

  • Juniper devices: MX, EX, SRX series (any JUNOS version)

  • Discovery initiated through: Settings > All Settings > VoIP & Network Quality (VNQM) Settings > Manage Network Service Assurance Operations > Add new operations > Monitor existing operations > Automatically discover

Description

When attempting to discover Juniper RPM operations in VNQM, the wizard reaches the Choose Operations to Monitor step and displays an empty list. The RPM probe is confirmed working on the Juniper device using:

show services rpm probe-results owner <owner-name> test <test-name>

A manual SNMP walk from the Orion polling engine (using the same credentials configured on the node) returns RPM data from the Juniper enterprise MIB sub-tree (1.3.6.1.4.1.2636.3.7.1.3 — jnxPingResultsTable), so SNMP connectivity and credentials are not the issue.

The IpSlaM job log (typically IpSlaM.Job_[<JobID>].log on the polling engine) records the actual failure:

INFO  RpmConfigDiscoveryJob - Juniper RPM Started polling configs
ERROR RpmConfigDiscoveryJob - Error during Juniper RPM configurations polling for Node: <NodeID>
SolarWinds.Orion.IpSla.Jobs.Snmp.SnmpException: ERROR_TIMEOUT
   at SolarWinds.Orion.IpSla.Jobs.Snmp.SnmpManager.CheckSnmpError(...)
   at SolarWinds.Orion.IpSla.Jobs.Snmp.SnmpHelper.<ProcessSubtreeRequest>...
   at SolarWinds.Orion.IpSla.Jobs.RPM.RpmConfigDiscoveryJob.<PollColumnsSubTreesAsync>...

The job runs for approximately 47 seconds on each attempt before failing.

Product section

VoIP & Network Quality Manager

Cause

The SolarWinds Platform (NPM and VNQM) sends SNMP GetBulk requests with large sets of OIDs grouped into a single packet during the Juniper RPM operation discovery job. Juniper MX/EX/SRX devices cannot handle oversized varbind lists in a single GetBulk request:

  • With ≤27 varbinds, the device responds correctly.

  • With ≥28 varbinds, the device drops the request entirely and does not respond.

The discovery job RpmConfigDiscoveryJob.PollColumnsSubTreesAsync builds GetBulk requests that exceed this device-side limit, so the poller receives no response, retries, exhausts retries, and finally returns ERROR_TIMEOUT.

A manual SNMP walk works correctly because snmpwalk issues sequential GetNext requests, one OID at a time, and never trips the device's varbind limit.

This behavior is resolved in SolarWinds Platform 2026.1 (Radium), which introduces a configurable polling batch size for Juniper nodes.

Resolution

Diagnosis steps

Before applying the fix, verify the failure matches this pattern. The issue is confirmed if all of the following are true:

  1. Probe is healthy on the Juniper device:

     show services rpm probe-results owner <owner-name> test <test-name>

    Output shows probes sent/received with non-zero results.

  2. Node is correctly classified in Orion (Node Details > Vendor = Juniper Networks, Inc., MachineType reflects the Juniper model).

  3. A full SNMP walk of the Juniper device from the Orion polling engine (using the same SNMP credentials configured on the node) returns data from 1.3.6.1.4.1.2636.3.7.1.3 (jnxPingResultsTable).

  4. The discovery wizard returns an empty operations list.

  5. The IpSlaM job log (<SolarWinds>\Logs\Orion\IPSLAM\Jobs\IpSlaM.Job_[<JobID>].log on the polling engine assigned to the Juniper node) contains the RpmConfigDiscoveryJob.PollColumnsSubTreesAsync SnmpException: ERROR_TIMEOUT entry.

  6. Per-node SNMP Timeout and Retries are at default values (2,500 ms / 2 retries) and the polling engine, IpSla BusinessLayer plugin, and SWIS are healthy during the discovery attempts.

Fix

Upgrade SolarWinds Platform to 2026.1 (Radium) or later. The upgrade introduces a configurable polling batch size for Juniper nodes that prevents oversized GetBulk requests.

After the upgrade:

  • A new row is added to the VoipConfig table: Name = JuniperOperationPollingBatchSize, DefaultValue = 50.

  • Re-run the VNQM discovery for the Juniper node. The operations list should now populate.

If the Juniper device still times out at the default batch size of 50 (some firmware versions enforce a stricter varbind limit), lower the value by updating the VoipConfig row directly in the database:

SELECT * FROM VoipConfig WHERE [Name] = 'JuniperOperationPollingBatchSize';

UPDATE VoipConfig SET [Value] = '15' WHERE [Name] = 'JuniperOperationPollingBatchSize';

A value of 15 has been validated as a safe fallback for Juniper devices that drop oversized GetBulk requests. After updating the value, restart the SolarWinds Information Service and the SolarWinds VNQM Service on the polling engine, then re-run the discovery.

To revert to the default, set Value back to NULL — the DefaultValue of 50 will be used.

Verification

After re-running the discovery, confirm:

  • The Choose Operations to Monitor wizard step lists the RPM operations with Owner (probe name) and Test Name populated.

  • The IpSlaM job log no longer shows ERROR_TIMEOUT in RpmConfigDiscoveryJob.PollColumnsSubTreesAsync.

  • The operations appear in the VoipOperationInstances database table for the source node.

Additional Information