Warning about "PING WARNING - DUPLICATES FOUND! " when use hostalive check

Here we use “hostalive” to check one managed physical centos 7.9 server, with single network connection. But it reports warning about "PING WARNING - DUPLICATES FOUND! " ramdomly. And we use arp-check in that host’s subnet and doesn’t find any duplicate ip with different mac address. So is it a false positive report? How can we see detail from icinga2 side only aim to this check item? If it’s a false positive report, how to supress it?

Before you ask a question, you can check the troubleshooting documentation first, maybe you can find an answer here.

Please describe your problem as detailed as possible and don’t forget to use a meaningful title :slight_smile:
We also have a markdown formatting guide to help you make your topics more readable!

Give as much information as you can, e.g.

  • Version used (icinga2 --version)
    icinga2 - The Icinga 2 network monitoring daemon (version: 2.12.3)
  • Operating System and version
    CentOS Linux release 7.9.2009 (Core)
  • Enabled features (icinga2 feature list)
    Enabled features: api checker command debuglog ido-mysql influxdb mainlog notification
  • Icinga Web 2 version and modules (System - About)
    Loaded modules
Name Version
businessprocess 2.2.0
ipl v0.5.0
leszke 1.0.0
monitoring 2.8.2
setup 2.8.2
  • Config validation (icinga2 daemon -C)
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 NotificationComponent.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 209 Hosts.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 6 NotificationCommands.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 2 FileLoggers.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 33 Comments.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 8 Notifications.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 IcingaApplication.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 3 HostGroups.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 395 Dependencies.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 CheckerComponent.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 7 Zones.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 5 Endpoints.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 ExternalCommandListener.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 IdoMysqlConnection.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 4 ApiUsers.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1 ApiListener.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 262 CheckCommands.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 3 InfluxdbWriters.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 3 TimePeriods.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 2 UserGroups.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 24 Users.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 1234 Services.
    [2025-04-16 09:24:07 +0200] information/ConfigItem: Instantiated 283 ServiceGroups.
    [2025-04-16 09:24:07 +0200] information/ScriptGlobal: Dumping variables to file ‘/var/cache/icinga2/icinga2.vars’
    [2025-04-16 09:24:07 +0200] information/cli: Finished validating the configuration file(s).
  • If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes
    Only one icinga2 master and one icinga2 satellite server are deployed.

hostalive is basically a reference to check_ping

there is a debug mode on check_ping
you can clone the ping command and change the command to:

PluginDir + /check_ping -v -v -v -4

CMD: /bin/ping -4 -n -U -w 10 -c 5 192.168.0.1

Output: PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 
Output: From 192.168.0.1 icmp_seq=1 Destination Host Unreachable 
CRITICAL - Host Unreachable (10.156.101.61)

and you can always switch to check_icmp which sends raw packages and is not using the systems ping binary.

1 Like

When you switch to check_icmp, you will also register a huge decrease in the runtime of your host alive checks :smiley:

deploy check_icmp and check_ping loop in the icinga2 satellite server from command line with -v -v -v -v.See one duplicate record from icinga2 web site in the last 6 hours, but from command line, the output shows no packat loss and duplicate related information at the same timestamp. So is it an icinga2 bug?

check_ping is a plugin independent from icinga2.
without the verbose output of check_ping with the duplicate warning, I can’t say much…

please post the output of check_ping witht he warning

Yes. Check_ping gives limit output. And Check_icmp gives detail. The question is when I compare the duplicate ip found warning from icinga2 web about the timestamp with output from Check_ping and Check_icmp command lines, I didn’t find anything valuable from the commend lines output. Below is the example from command lines:

Check_ping:
Thu Apr 17 20:58:41 EDT 2025
CMD: /usr/bin/ping -n -U -w 10 -c 5 10.192.229.101
Output: PING 10.192.229.101 (10.192.229.101) 56(84) bytes of data.
Output: 64 bytes from 10.192.229.101: icmp_seq=1 ttl=63 time=0.195 ms
Output: 64 bytes from 10.192.229.101: icmp_seq=2 ttl=63 time=0.217 ms
Output: 64 bytes from 10.192.229.101: icmp_seq=3 ttl=63 time=0.362 ms
Output: 64 bytes from 10.192.229.101: icmp_seq=4 ttl=63 time=0.231 ms
Output: 64 bytes from 10.192.229.101: icmp_seq=5 ttl=63 time=0.269 ms
Output:
Output: — 10.192.229.101 ping statistics —
Output: 5 packets transmitted, 5 received, 0% packet loss, time 4000ms
Output: rtt min/avg/max/mdev = 0.195/0.254/0.362/0.062 ms
PING OK - Packet loss = 0%, RTA = 0.25 ms|rta=0.254000ms;100.000000;200.000000;0.000000 pl=0%;5;15;0
100.000000:5% 200.000000:15%

Check_icmp:
Sending ICMPv4 echo-request of len 24, id 31536, seq 2, cksum 0x5828 to host 10.192.229.101
received 96 bytes from 10.192.229.101
ICMP echo-reply of len 24, id 31536, seq 2, cksum 0x5830
0.105 ms rtt from 10.192.229.101, outgoing ttl: 64, incoming ttl: 63, max: 0.208, min: 0.105
Sending ICMPv4 echo-request of len 24, id 31536, seq 3, cksum 0x56BC to host 10.192.229.101
received 96 bytes from 10.192.229.101
ICMP echo-reply of len 24, id 31536, seq 3, cksum 0x56C4
0.097 ms rtt from 10.192.229.101, outgoing ttl: 64, incoming ttl: 63, max: 0.208, min: 0.097
Sending ICMPv4 echo-request of len 24, id 31536, seq 4, cksum 0x5558 to host 10.192.229.101
received 96 bytes from 10.192.229.101
ICMP echo-reply of len 24, id 31536, seq 4, cksum 0x5560
0.098 ms rtt from 10.192.229.101, outgoing ttl: 64, incoming ttl: 63, max: 0.208, min: 0.097
finish(0) called
icmp_sent: 5 icmp_recv: 5 icmp_lost: 0
targets: 1 targets_alive: 1
OK -
10.192.229.101 rta 0.123ms lost 0%|
rta=0.123ms;100.000;200.000;0; pl=0%;5;15;0;100 rtmax=0.208ms;;;; rtmin=0.097ms;;;;
targets: 1, targets_alive: 1, hosts_ok: 1, hosts_warn: 0, min_hosts_alive: -1

Now you have to wait for the WARNING duplicate output. since the output you posted is from a PING OK

This means that ping(8) received more than one reply for a ICMP packet. And it might be anything from configuration problem to a failing network device.

You may try and leave ping running for an extended preriod of time and check for words “dup” or ”duplicate” in the output, although that’s unlikely to provide any insights.