ICMP Monitoring

NetXMS uses ICMP (Internet Control Message Protocol) to check node reachability and measure network response times. ICMP ping is one of the most fundamental monitoring methods and is used both for status polling and as a data collection source.

How ICMP Monitoring Works

The NetXMS server performs ICMP echo requests (pings) to each managed node during status polls. The results are used to determine node reachability, measure round-trip time, and detect packet loss.

ICMP polling behavior is controlled per-node and through server-wide configuration parameters.

Server-Side ICMP Polling

By default, the NetXMS server sends ICMP pings from the server host. The following server configuration variables control ICMP behavior:

Variable Description

ICMP.CollectPollStatistics

Enable collection of ICMP statistics during status polls (default: yes)

ICMP.PingSize

Total ICMP packet size in bytes, including IP and ICMP headers (minimum: 28; default: 46, i.e. 18 bytes of payload)

ICMP.PingTimeout

Timeout for ICMP ping response in milliseconds (default: 1500)

ICMP.PollingInterval

Interval between ICMP polls in seconds (default: 60)

ICMP.StatisticPeriod

Number of polls used for ICMP statistics calculation (default: 60)

ICMP Metrics

When ICMP statistics collection is enabled, the following internal metrics are available for each node:

Metric Description

ICMP.ResponseTime.Last

Last ping response time in milliseconds

ICMP.ResponseTime.Average

Average ping response time over the statistics period

ICMP.ResponseTime.Min

Minimum ping response time over the statistics period

ICMP.ResponseTime.Max

Maximum ping response time over the statistics period

ICMP.PacketLoss

Packet loss percentage over the statistics period

ICMP.Jitter

Ping jitter (response time variation) over the statistics period

Each metric also accepts an optional argument specifying an ICMP collection target, e.g. ICMP.ResponseTime.Average(10.0.0.1), to read statistics for that target instead of the node’s primary IP address.

These metrics can be used in DCIs for trending, thresholds, and dashboards.

Agent-Side ICMP (Ping Subagent)

The ping.nsm subagent enables ICMP monitoring from the agent host. This is useful when you need to check reachability from a specific network location rather than from the server.

Configuration

Load the subagent and configure targets in the agent configuration file:

SubAgent = ping.nsm

[PING]
Timeout = 2000
DefaultPacketSize = 46
PacketRate = 4
Target = 10.0.0.1:gateway
Target = 8.8.8.8:dns
Target = 192.168.1.100:webserver

Configuration parameters:

Parameter Default Description

Timeout

3000

Response timeout in milliseconds

DefaultPacketSize

46

Total ICMP packet size in bytes, including IP and ICMP headers (minimum: 28)

DefaultDoNotFragmentFlag

off

Set Don’t Fragment flag on ICMP packets

PacketRate

4

Number of ICMP packets sent per minute (range: 1-6000)

AutoConfigureTargets

on

Automatically add targets from DCI requests

MaxTargetInactivityTime

86400

Remove inactive auto-configured targets after this many seconds

MovingAverageTimePeriod

3600

Time period in seconds for moving average calculation

ThreadPoolMinSize

1

Minimum number of threads in the poller thread pool

ThreadPoolMaxSize

1024

Maximum number of threads in the poller thread pool

Target

Target definition in format address[:name[:packet_size[:options]]]

Set the per-target options field to DF to enable the Don’t Fragment flag.

Agent Metrics

The ping subagent provides these metrics. Background poller metrics use the target name or IP address as the argument. The on-demand Icmp.Ping metric supports additional parameters for fine-grained control.

On-Demand Ping

Icmp.Ping(target[,timeout[,packetSize[,dontFragment[,retryCount]]]])
Argument Default Description

target

(required)

IP address or hostname to ping

timeout

Timeout config (3000)

Response timeout in milliseconds (clamped to 100-5000)

packetSize

DefaultPacketSize (46)

Total ICMP packet size in bytes, including IP and ICMP headers (minimum: 28)

dontFragment

DefaultDoNotFragmentFlag (0)

Non-zero to set the Don’t Fragment bit

retryCount

1

Number of ping attempts (minimum 1)

Returns the round-trip time in milliseconds on success, or 10000 on timeout/unreachable.

Background Poller Metrics

These metrics return values from the background ping poller, which continuously pings configured targets at the rate set by PacketRate.

Parameter Description

Icmp.AvgPingTime(target)

Average response time for the last minute

Icmp.LastPingTime(target)

Last ping response time

Icmp.MaxPingTime(target)

Maximum response time for the last minute

Icmp.MinPingTime(target)

Minimum response time for the last minute

Icmp.CumulativeMaxPingTime(target)

Cumulative maximum response time since agent start

Icmp.CumulativeMinPingTime(target)

Cumulative minimum response time since agent start

Icmp.MovingAvgPingTime(target)

Exponential moving average of response time

Icmp.PacketLoss(target)

Packet loss percentage (0-100)

Icmp.Jitter(target)

Average jitter in milliseconds for the last minute

Icmp.MovingAvgJitter(target)

Exponential moving average of jitter

Icmp.PingStdDev(target)

Standard deviation of response times for the last minute

All RTT/jitter values are in milliseconds. A value of 10000 indicates timeout or unreachable.

Lists

List Description

Icmp.Targets

Names of all configured and auto-registered ping targets

Icmp.ScanRange(startAddr,endAddr[,timeout[,includeRTT]])

Scan an IPv4 address range and return list of responding addresses. Default timeout: 1000 ms. If includeRTT is set, the response time is appended to each address in the output.

Icmp.Targets Table

The Icmp.Targets table provides comprehensive status of all ping targets:

Column Type Description

IP

STRING

Target IP address (key column)

LAST_RTT

UINT

Last response time (ms)

AVERAGE_RTT

UINT

Average response time (ms)

MIN_RTT

UINT

Minimum response time (ms)

MAX_RTT

UINT

Maximum response time (ms)

MOVING_AVERAGE_RTT

UINT

Moving average of response time (ms)

STD_DEV

UINT

Standard deviation of response time (ms)

JITTER

UINT

Average jitter (ms)

MOVING_AVERAGE_JITTER

UINT

Moving average of jitter (ms)

CMIN_RTT

UINT

Cumulative minimum response time (ms)

CMAX_RTT

UINT

Cumulative maximum response time (ms)

PACKET_LOSS

UINT

Packet loss percentage

PACKET_SIZE

UINT

Configured packet size (bytes)

NAME

STRING

Target name

DNS_NAME

STRING

Target DNS name

IS_AUTO

INT

1 if auto-registered from DCI request, 0 if from config

Dynamic Targets

Targets can also be added dynamically through DCIs. When you create a DCI using one of the background poller metrics (Icmp.AvgPingTime, Icmp.PacketLoss, etc.) with an address not in the configuration file, the agent adds it as a dynamic target (requires AutoConfigureTargets to be enabled). Icmp.Ping performs a one-shot ping and never registers targets. Auto-registered targets are removed after MaxTargetInactivityTime seconds of no DCI requests.

ICMP Status Determination

NetXMS uses ICMP results as part of node status determination:

  • If the node is reachable only via ICMP (no agent, no SNMP), status is determined by ping success/failure

  • If other protocols are available, ICMP acts as an additional check

To alert on packet loss or high response times, create a DCI on one of the ICMP metrics and configure a threshold on it.

Network Path Trace

NetXMS can display the network path between the server (or another managed node) and a target node. The trace is not an ICMP traceroute: no probe packets are sent. Instead, the server walks the routing tables of managed nodes hop by hop (up to 30 hops), so the result reflects routing information already known to the server and does not include per-hop response times.

To perform a network path trace, open the object context menu on a node and select Trace path with one of the options:

  • Route from NetXMS server — path from the management server to the node

  • Route from…​ — path from another selected node to this node

  • Route to…​ — path from this node to another selected node

  • L2 path from NetXMS server — layer 2 path from the management server to the node

  • L2 path from…​ — layer 2 path from another selected node to this node

  • L2 path to…​ — layer 2 path from this node to another selected node

The L2 path options show the switch-level path derived from collected topology information rather than routing tables.

Intermediate hops can only be shown for routers that are themselves managed nodes with readable routing tables.