SNMP Configuration

NetXMS supports SNMP versions 1, 2c, and 3 for monitoring network devices, servers, and other equipment that provides SNMP interfaces. This section covers protocol-level SNMP configuration. For creating SNMP-based data collection items, see SNMP Data Collection.

Network Device Drivers

Various network devices may require special handling to retrieve information correctly. NetXMS addresses this through network device drivers (NDDs), which provide vendor-specific interface enumeration, topology discovery, configuration backup, and more. Most drivers work over SNMP; some also use SSH.

Drivers are auto-detected during configuration polling based on the device’s SNMP sysObjectID. You can also name a fallback driver for devices that auto-detection does not match, or blacklist problematic ones.

See Network Device Drivers Reference for the complete driver list, auto-detection details, and driver capabilities.

SNMP Settings on a Node

SNMP capability is detected automatically during the configuration poll — when a device responds to SNMP requests with one of the configured credentials, the server marks the node as SNMP-capable and starts using SNMP for it.

SNMP communication settings are configured on the node’s dedicated SNMP property page:

  1. Right-click the node and select Properties

  2. Go to the SNMP page

  3. Configure the SNMP version, community string or user name, UDP port, authentication and privacy methods, proxy, and codepage

The SNMP page also contains the Prevent automatic SNMP configuration changes option and a separate credential block for SNMP trap reception (Use separate credentials for SNMP trap reception, see SNMP Traps).

A node can also have additional SNMP agents, configured on a separate page (see Additional SNMP Agents).

To prevent the server from using SNMP on a particular node, enable Disable usage of SNMP for all polls on the node’s Polling property page.

NetXMS uses SNMP for:

  • Status polling — checking device reachability and operational state

  • Configuration polling — discovering interfaces, hardware, and software inventory

  • Data collection — gathering performance metrics and operational counters

  • Topology discovery — building network maps from LLDP, CDP, and other protocols

ifTable vs ifXTable

There are two SNMP subtrees that provide information about network interfaces: the original ifTable (.1.3.6.1.2.1.2.2) and the newer ifXTable (.1.3.6.1.2.1.31.1.1). The ifXTable provides additional fields such as 64-bit counters (ifHCInOctets, ifHCOutOctets), interface alias (ifAlias), and high-speed interface speed (ifHighSpeed).

By default, NetXMS uses ifXTable when available. However, some devices have buggy ifXTable implementations that return incorrect data. In such cases, you can disable ifXTable usage.

Per-Node Setting

In the node properties, go to the Polling page and set the Use ifXTable option:

  • Default — use the global server setting

  • Enable — take interface names from ifName (ifXTable) for this node

  • Disable — take interface names from ifDescr (ifTable) for this node

This option only controls the source of interface names. The device driver still uses additional data from ifXTable (such as ifAlias and ifHighSpeed) regardless of this setting.

Global Setting

Variable Default Description

Objects.Interfaces.UseIfXTable

true

Globally controls whether interface names are taken from ifName (ifXTable) or ifDescr (ifTable) during configuration polls

During configuration polling, NetXMS performs a test walk on the ifXTable OID; the result only sets the informational capability flag shown in the node’s Capabilities view and does not affect interface enumeration.

SNMP Versions

NetXMS supports three SNMP versions:

Version Description

v1

Original SNMP version. Uses community string for authentication. Uses 32-bit counters and has no GetBulk operation.

v2c

Community-based SNMP with 64-bit counter support. Recommended for most environments.

v3

Adds authentication and encryption. Required when security policies mandate encrypted management traffic.
Use SNMP v2c unless security requirements mandate v3. SNMP v2c supports 64-bit counters without the complexity of v3 configuration. NetXMS uses GETNEXT requests for SNMP walks.

The minimum accepted SNMP version can be enforced globally with the SNMP.MinVersion server configuration variable; when raised, lower versions (v1, v2c) are no longer used. The global setting can be overridden per node with the SysConfig:SNMP.MinVersion custom attribute.

Community Strings

For SNMP v1 and v2c, authentication uses a community string (default: public for read access).

NetXMS supports multiple community strings that are tried during configuration polling to automatically determine which string works for a given device.

Configure community strings in two ways:

  • Per-node — in node properties on the SNMP page, set the community string for a specific device

  • Global list — configure a list of community strings that NetXMS tries during network discovery and initial configuration polling

Global SNMP Community Strings

To configure the global list:

  1. Go to Configuration > Network credentials

  2. Expand the SNMP community strings section

  3. Add community strings in priority order

  4. NetXMS tries each string during configuration polling until one succeeds

The Network Credentials view also contains collapsible sections for SNMPv3 USM credentials, agent shared secrets, SSH credentials, and per-protocol port lists.

The global list is used during network discovery when a new SNMP device is found and during reconfiguration polls if the current community string fails.

SNMP v3 Configuration

SNMPv3 uses the User-based Security Model (USM) for authentication and privacy.

Security Levels

Level Description

noAuthNoPriv

No authentication, no encryption. Equivalent to SNMP v1/v2c security.

authNoPriv

Authentication (username + password) but no encryption. Verifies message sender identity.

authPriv

Both authentication and encryption. Full security for sensitive environments.

Security Settings

Setting Description

Security Name

USM user name configured on the target device

Auth Method

Authentication protocol: MD5, SHA1, SHA224, SHA256, SHA384, SHA512

Auth Password

Authentication passphrase

Privacy Method

Encryption protocol: DES, AES-128, AES-192, AES-256

Privacy Password

Privacy passphrase

Global SNMP v3 Credentials

Similar to community strings, you can configure a global list of SNMPv3 credentials:

  1. Go to Configuration > Network credentials

  2. Expand the SNMPv3 USM credentials section

  3. Add credential sets in priority order

  4. During polling, NetXMS tries each credential set until authentication succeeds

SNMP Port

The default SNMP port is UDP 161. To use a non-standard port on a specific node, configure it in the node properties on the SNMP page.

Some devices use alternative ports for SNMP access (e.g., virtual device instances on different ports).

During configuration polls and network discovery, the server also tries the ports from the SNMP port list configured under Configuration > Network credentials (the list can be configured per zone), not only the port set on the node.

Additional SNMP Agents

A node has one primary SNMP agent, configured on the SNMP property page and used for all polls. Some devices run more than one SNMP engine: a vendor agent next to the operating system agent, a management module answering on a different port or address, or an agent that serves different data per context or community. To collect data from such an engine, add it to the node as an additional SNMP agent.

Additional agents are configured on the node’s Communication > SNMP Agents property page. Each agent has a name, unique on the node (letter case is ignored), and its own address, UDP port, SNMP version, credentials, and context. An empty address means the node’s primary IP address. See SNMP Agents for the dialog fields.

The server uses an additional agent only where it is selected by name:

Status, configuration, and topology polls use only the primary agent, so an additional agent does not change the node’s SNMP capability, interfaces, or status. A DCI that uses an additional agent is collected even if the node is not SNMP-capable or its primary agent is unreachable, unless DataCollection.Scheduler.RequireConnectivity (or the node’s SysConfig:DataCollection.Scheduler.RequireConnectivity attribute) is enabled: the scheduler then skips all SNMP DCIs of such a node. It is not collected if the node is unmanaged or has Disable usage of SNMP for all polls set. While the node is unreachable, single-value DCIs are not collected and instance discovery does not run; table DCIs still query the additional agent unless DataCollection.Scheduler.RequireConnectivity is enabled.

Requests to an additional agent go through the same SNMP proxy as requests to the primary agent (the node’s SNMP proxy or the zone proxy) and use the node’s SNMP codepage. An agent is not used if its version is lower than the minimum SNMP version in effect for the node (SNMP.MinVersion or the node’s SysConfig:SNMP.MinVersion attribute), or if its UDP port is on the node’s port stop list. For SNMPv1/v2c, the agent’s context is sent in the community@context form, as for the primary agent (see SNMP Context).

SNMP Context

An SNMP context can be set on an individual DCI. For SNMPv3, the context is sent as the context name in the request; for v1 and v2c, it is appended to the community string in the community@context form.

SNMP Proxy

When the NetXMS server cannot reach an SNMP device directly (e.g., the device is on a remote network behind NAT), you can route SNMP requests through a NetXMS agent acting as an SNMP proxy.

  1. On the target node’s properties, go to the SNMP page

  2. Set the proxy to a NetXMS agent that has network access to the device

  3. The server sends SNMP requests to the proxy agent, which forwards them to the device and returns the responses

The proxy agent must have the following in its configuration file:

EnableSNMPProxy = yes

SNMP proxy is useful for:

  • Monitoring devices in remote networks connected via VPN

  • Reaching devices behind NAT

  • Reducing WAN bandwidth by aggregating SNMP requests at the remote site

See Agent Proxies for proxy architecture details.

SNMP Timeouts and Retries

SNMP communication uses UDP, which is inherently unreliable. Timeout and retry behavior is controlled globally by server configuration variables:

Variable Default Description

SNMP.RequestTimeout

1500

SNMP request timeout in milliseconds

SNMP.RetryCount

3

Number of retries

Changes to these variables take effect after a server restart.

Increase the timeout for devices on high-latency links or devices with slow SNMP agent implementations.

Zone SNMP Configuration

In multi-zone deployments, SNMP credentials can be configured per zone: each zone object has its own SNMP Credentials property page with community strings, USM credentials, and port lists used for nodes in that zone.

Communication with devices in a zone goes through the zone’s proxy nodes, configured in the proxy node list on the zone’s Communications property page. This proxy list is generic — the same proxies are used for all communication with the zone, not only SNMP.

See Zones and Subnets for zone configuration details.