Skip to content

Warning

License: Pro - Requires a Pro or Enterprise license.

Ping Gateway Probe

The Ping Gateway probe monitors network connectivity to the host's default gateway, providing essential metrics for detecting network routing issues, ISP quality problems, and local network connectivity.

Quick Start

Basic Configuration

# probes.d/10-ping-gateway.yaml — each file under probes.d/ is a YAML array of probes
- name: ping_gateway
  type: ping_gateway
  params: {}

The Ping Gateway probe reads no parameters. It detects the default gateway from the routing table and pings it every 30 seconds.

Supported Platforms

  • Windows: Windows Server 2012+ / Windows 10+
  • Linux: All modern distributions (Ubuntu, RHEL, CentOS, Debian, etc.)
  • macOS: macOS 10.13+

Platform-specific ping implementations are automatically selected based on the operating system.

Key Metrics Summary

Metric Description Unit Alert Threshold
averageLatency Average round-trip time to gateway ms > 50ms (warning), > 100ms (critical)
packetLoss Percentage of lost packets % > 1% (warning), > 5% (critical)

Configuration Parameters

This probe reads no parameters. It collects every 30 seconds, a cadence fixed in the code.

The probe runs every 30 seconds. That cadence is fixed in the code; there is no interval parameter, and one written under params: is ignored. Run one instance per host: a second instance pings the same gateway again.

How It Works

Gateway Auto-Detection

The probe reads the default route from the operating system's routing table:

  • Linux: the 0.0.0.0 route with a gateway flag in /proc/net/route
  • Windows: the 0.0.0.0 destination in route print 0.0.0.0
  • macOS: the gateway: line of route -n get default

Only IPv4 routes are considered. When no default route is found the collection fails with an error and no metric is emitted.

Ping Collection Process

The probe sends 10 ICMP echo requests to the target IP and collects:

  • Average latency: Mean round-trip time across all successful pings
  • Packet loss: Percentage of packets that did not receive a reply

Platform-Specific Implementations:

  • Windows: Uses ping -n 10 <ip> command
  • Linux: Uses ping -c 10 <ip> command
  • macOS: Uses ping -c 10 <ip> command

All implementations parse the native ping command output to extract metrics.

Monitoring Tool Integration

PRTG Network Monitor

Access gateway metrics in PRTG JSON format:

# All gateway metrics
curl http://localhost:8080/api/{agentkey}/prtg/metrics

# Configure PRTG HTTP Advanced Sensor:
# - URL: http://agent-host:8080/api/{agentkey}/prtg/metrics
# - Method: POST
# - Request body: {"probe": "ping_gateway"}

PRTG Channels Available: - Gateway Average Latency (ms) - Gateway Packet Loss (%)

Recommended Limits: 

{
  "Gateway Average Latency": {
    "LimitMaxWarning": 50,
    "LimitMaxError": 100,
    "LimitMode": 1
  },
  "Gateway Packet Loss": {
    "LimitMaxWarning": 1,
    "LimitMaxError": 5,
    "LimitMode": 1
  }
}

Nagios

Access gateway metrics in Nagios format:

# All gateway metrics with performance data
curl http://localhost:8080/api/{agentkey}/nagios/metrics?probe=ping_gateway

# Example output:
# OK - Gateway connectivity normal | averageLatency=15.3ms;50;100 packetLoss=0.0%;1;5

Nagios Performance Data: - averageLatency - Gateway latency with 50ms warning, 100ms critical - packetLoss - Packet loss with 1% warning, 5% critical

Service Check Configuration: 

define service {
    use                     generic-service
    host_name               monitored-server
    service_description     Gateway Connectivity
    check_command           check_http_json!8080!/api/{agentkey}/nagios/metrics?probe=ping_gateway
    check_interval          1
    retry_interval          1
    max_check_attempts      3
}

Web console

The Probes page of the console shows the probe's state and the time of its last run; the Sensor URLs tab of the HTTP output previews the latency and packet loss values as a poller sees them. Graphs and history belong to the poller or the OTLP backend.

Use Cases

Network Connectivity Monitoring

Monitor local network connectivity to detect: - Gateway failures: Complete loss of connectivity to the default gateway - Network path issues: Routing problems between host and gateway - Local switch problems: Layer 2 connectivity issues

Typical Alert Configuration: - Packet loss > 1%: Warning (investigate network) - Packet loss > 5%: Critical (network failure)

ISP Quality Monitoring

Track Internet Service Provider quality: - Latency increases: Detect congestion or routing changes - Packet loss patterns: Identify intermittent connectivity issues - Performance degradation: Monitor for ISP throttling or oversubscription

Use with WebApp Probe: Combine gateway ping with external website monitoring to isolate local vs. WAN issues.

Routing Issues Detection

Identify routing problems: - Gateway unreachable: Local network configuration issues - High latency: Network congestion or misconfigured routes - Intermittent connectivity: Faulty network equipment

Correlation with Other Metrics: - Compare with WebApp probe to distinguish local vs. remote issues - Check network interface metrics for errors/collisions - Review system logs for DHCP or routing updates

Network Troubleshooting

Diagnose network issues: - Baseline establishment: Normal latency and packet loss patterns - Change detection: Identify when network performance degrades - Isolation: Determine if issues are local (gateway) or remote (internet)

Troubleshooting Workflow: 1. Check gateway ping (this probe) - Is local network working? 2. Check external ping (webapp probe) - Is internet working? 3. Check interface metrics (network probe) - Are there errors? 4. Review system logs - Any configuration changes?

Troubleshooting

No Metrics Collected

Check probe status: 

# View agent logs with gateway probe debugging
senhub-agent run --filter probe.gateway

Verify probe is enabled: 

# Check configuration (multi-file layout)
grep -rA5 "name: ping_gateway" /etc/senhub-agent/probes.d/

Common Causes: - Firewall blocking ICMP echo requests - Network interface disabled or misconfigured - Gateway auto-detection failure (no active interfaces)

Gateway Detection Failed

Symptom: Error message "no default gateway found"

Solution:

Windows: 

# Verify network configuration
ipconfig /all

# Check routing table
route print

# Verify default gateway
netstat -rn | findstr "0.0.0.0"

Linux: 

# Check network interfaces
ip addr show

# Check routing table
ip route show

# Verify default gateway
ip route | grep default

macOS: 

# Check network interfaces
ifconfig

# Check routing table
netstat -rn | grep default

High Latency or Packet Loss

Symptom: Consistently high latency (>50ms) or packet loss (>1%)

Diagnosis Steps:

  1. Verify local network health: 

    # Check interface errors (Linux)
ip -s link

# Check interface errors (Windows)
netsh interface ipv4 show subinterfaces

  2. Test connectivity directly: 

    # Windows
ping -n 20 <gateway-ip>

# Linux/macOS
ping -c 20 <gateway-ip>

  3. Check for network congestion:

  4. Review bandwidth utilization
  5. Check for broadcast storms

  6. Verify switch/router performance

  7. Hardware issues:

  8. Loose or damaged cables
  9. Failing network interface card
  10. Overheating network equipment

Mitigation: - Replace faulty cables - Update network drivers - Restart network equipment - Check for firmware updates

Firewall Blocking ICMP

Symptom: 100% packet loss, but network appears to be working

Solution:

Windows Firewall: 

# Allow ICMP Echo Request (outbound)
netsh advfirewall firewall add rule name="ICMP Allow outgoing V4 echo request" protocol=icmpv4:8,any dir=out action=allow

# Allow ICMP Echo Reply (inbound)
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo reply" protocol=icmpv4:0,any dir=in action=allow

Linux iptables: 

# Allow ICMP Echo Request (outbound)
sudo iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

# Allow ICMP Echo Reply (inbound)
sudo iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT

Linux firewalld: 

# Allow ICMP permanently
sudo firewall-cmd --permanent --add-icmp-block-inversion
sudo firewall-cmd --reload

Permission Denied (Unix/Linux)

Symptom: Error message "permission denied" when executing ping

Solution:

Most modern systems allow unprivileged users to ping, but if you encounter permission issues:

# Option 1: Run agent as root
sudo senhub-agent run

# Option 2: Grant ping capabilities (Linux)
sudo setcap cap_net_raw+ep /usr/bin/ping

# Option 3: Add agent user to netdev group (Debian/Ubuntu)
sudo usermod -a -G netdev senhub-agent

Inconsistent Results

Symptom: Metrics vary significantly between collections

Explanation: Network conditions naturally fluctuate. Some variance is normal.

Acceptable Variance: - Latency: +/-5-10ms is typical - Packet loss: 0-1% is acceptable

Excessive Variance Indicators: - Latency swings > 50ms - Intermittent 100% packet loss - Packet loss > 5% sustained

Investigation: - Check for network congestion patterns - Review network equipment logs - Monitor bandwidth utilization - Verify QoS configurations

Performance Considerations

Collection Overhead

The Ping Gateway probe has minimal overhead: - Command execution: ~100-200ms per collection (10 pings) - Parsing overhead: < 10ms - Total collection time: ~200-300ms

Note: The ping command sends 10 ICMP packets with default timeout, which is generally sufficient for local gateway monitoring.

Network Impact

Network impact is negligible: - 10 ICMP packets per collection interval - Packet size: 64 bytes (default ping size) - Bandwidth: ~640 bytes every 30 seconds = ~170 bits/sec - Total overhead: < 0.001% on 10 Mbps link

Collection cadence

The probe runs every 30 seconds. That cadence is fixed in the code; there is no interval parameter, and one written under params: is ignored. Ten pings every 30 seconds is the fixed load on the gateway.

Advanced Configuration

Multiple Gateway Monitoring

The probe pings the default gateway only, and every instance on a host resolves the same gateway. Configure one instance per host; there is no parameter to point an instance at another gateway.

Integration with Other Probes

Comprehensive network monitoring setup:

# probes.d/10-ping-gateway.yaml
# Local network connectivity
- name: ping_gateway
  type: ping_gateway
  params: {}

# External connectivity and DNS, one ping_webapp instance per URL
- name: ping_webapp_google
  type: ping_webapp
  params:
    url: "https://www.google.com"

- name: ping_webapp_cloudflare
  type: ping_webapp
  params:
    url: "https://1.1.1.1"

# Interface metrics
- name: network
  type: network
  params:
    interval: 30

This combination provides: - Gateway probe: Local network health (Layer 3) - WebApp probe: Internet connectivity and latency - Network probe: Interface errors, bandwidth, packet statistics

Known Limitations

  1. IPv6 Support: The probe currently focuses on IPv4 connectivity.

  2. Manual Gateway Override: No option to specify a custom gateway IP. Auto-detection is the only supported mode.

  3. Jitter Metrics: The probe does not currently calculate jitter (latency variance).

Requirements

Windows

  • Windows Server 2012+ or Windows 10+
  • ping.exe command (built into Windows)
  • ICMP outbound/inbound allowed in firewall

Linux/Unix/macOS

  • ping command installed (pre-installed on most systems)
  • ICMP outbound/inbound allowed in firewall
  • Network interface with IPv4 address configured

Network

  • Local network access to default gateway
  • ICMP echo request/reply allowed (firewall/router)
  • HTTP strategy required for remote access to metrics

Metric reference

Every metric this probe can emit. Metric is the OpenTelemetry name the OTLP, Prometheus and Zabbix outputs derive theirs from. Name is what a Nagios check and the API metrics= filter match. PRTG channel is the label PRTG shows, placeholders filled from the series' tags.

Metric Name PRTG channel Unit Description
senhub.probe.icmp.duration_seconds averageLatency Gateway Average Latency ms Average round-trip time to the default network gateway
senhub.probe.icmp.packet_loss_ratio packetLoss Gateway Packet Loss % Percentage of ICMP packets lost to the default gateway