[ZBXNEXT-8042]  Add ability to set custom fping interval manually for icmp checks Created: 2022 Oct 12  Updated: 2024 Jun 17

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Server (S)
Affects Version/s: 6.2.3
Fix Version/s: None

Type: Change Request Priority: Trivial
Reporter: Stuart McGraw Assignee: Zabbix Support Team
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Zabbix-6.2.3, Ubuntu-22.04, fping-5.1



 Description   

Steps to reproduce:

  • Create a "Simple check" item with a icmppingsec key.
  • Set the sever DebugLevel to 4
  • Observe the fping command generated by Zabbix.
  • Observe the recorded ping times.
  • Repeat with a version of Zabbix (eg 3.4) that does not use a "-i0" option with fping.

Result:

The fping commands generated by Zabbix-6.2 include a "-i0" option.  The documentation for simple-check/icmppingsec acknowledges  this: "Zabbix tries to detect the minimal value in milliseconds that fping allows to use with -i by trying 3 values: 0, 1 and 10. The value that first succeeds is then used for subsequent ICMP checks."

However at my site, although the  i0 option "works", it results in ping times that are much slower than a larger -i value (eg, fping's default value of 10.)  Zabbix-3.4 did not use the i option.  Consequently I am seeing ping times much greater and with much larger variance then previously. 

Running both Zabbbix 3.4 and Zabbix 6.2 for an hour, each with an identical set of 7 icmpingsec items (update interval=15s) gives the following results for one of the addresses:

Ping response times in mS:

1 hour Min Avg Max
Zabbix-6.2 2.7 13.7 72.4
Zabbix-3.4 2.9 3.7 15.4

I can reproduce similar results running fping by hand, with and without a "-i0" option.

I do not understand why this is happening (the internal workings of fping or the upstream network characteristics that may be contributing) but since it is happening, I believe Zabbix needs to provide some means for the user to control at least the minimal value used with the -i option given to fping.



 Comments   
Comment by Edgar Akhmetshin [ 2022 Oct 13 ]

Hello

If different versions of the fping works differently with -i0 option - this questions should be re-addressed to the upstream developer of the fping product.

We are using fping version which is installed in the system and rely on the functionality of the fping version.

Also in our environment we can not reproduce the issue with RHEL8 or RHEL9 and fping supplied by RHEL.

Regards,
Edgar

Comment by Stuart McGraw [ 2022 Oct 13 ]

Thank you for your attention to this problem.  I apologize if I was not clear.

This is NOT an fping version issue (or an fping issue at all).  I see the exactly the same effect whether running ubuntu-18.04/fping-4.0 or ubuntu-22.04/fping-5.1: when run with the i0 option the ping response times are 4-5 times longer than without it.  This is, I believe, due to the responses of the upstream routers when presented with multiple icmp packets sent closely together (as happens with i0).  The difference is apparent in Zabbix because Zabbix-3.4 calls fping without the i0 option and Zabbix-6.2 calls it with the i0 option.  That you can't reproduce it there is likely due to network hardware, upstream network traffic load and topology differences.{}

Below are sample results from running the two different versions of fping used by the two different versions of Zabbix I have here with ip address obfuscated for privacy.  The ip addresses are roughly in order of network hops from me with my router being 1.1.1.1.  The ip address I have been concentrating on  is 2.2.2.2 (one hop upstream from my router and marked bold below ).  I do not know if the address order is relevant but it doesn't matter because Zabbix seems to call fping with the addresses in a different arbitrary order on each update.   Also, I have run these fping tests multiple times; the results below are typical, not one-offs.  The longer response times with i0 are clearly visible.

I hope this clarifies why (at least some) Zabbix users need some control over the i option Zabbix uses with fping.

 

 

fping-4.0 (used by Zabbix-3.4 on Ubuntu-18.04 box) without and with i0
$ fping -qc3 5.5.5.5  3.3.3.3  7.7.7.7  4.4.4.4  1.1.1.1  6.6.6.6  2.2.2.2
5.5.5.5 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 16.0/17.0/18.8
3.3.3.3 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 8.91/9.85/10.9
7.7.7.7 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 41.2/41.7/42.3
4.4.4.4 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 9.59/9.98/10.4
1.1.1.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.47/0.63/0.71
6.6.6.6 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 15.2/17.2/19.2
2.2.2.2 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 3.15/5.09/8.64 

 

$ fping -i0 -qc3  5.5.5.5  3.3.3.3  7.7.7.7  4.4.4.4  1.1.1.1  6.6.6.6  2.2.2.2
5.5.5.5 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 17.2/21.1/25.7
3.3.3.3 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 11.8/21.7/31.8
7.7.7.7 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 51.5/58.6/71.2
4.4.4.4 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 20.3/28.0/38.5
1.1.1.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.83/0.87/0.92
6.6.6.6 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 25.6/32.9/46.1
2.2.2.2 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 10.6/17.5/31.3

 

 

fping-5.0 (used by Zabbix-6.2 on Ubuntu-22.04 box) without and with i0
$ fping -qc3 5.5.5.5  3.3.3.3  7.7.7.7  4.4.4.4  1.1.1.1  6.6.6.6  2.2.2.2
5.5.5.5 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 20.4/25.0/33.6
3.3.3.3 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 13.9/17.4/22.7
7.7.7.7 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 43.3/48.2/51.8
4.4.4.4 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 15.8/20.0/22.8
1.1.1.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.341/0.370/0.405
6.6.6.6 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 17.3/20.1/23.4
2.2.2.2 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 3.99/7.66/11.5

 

$ fping -i0 -qc3 5.5.5.5  3.3.3.3  7.7.7.7  4.4.4.4  1.1.1.1  6.6.6.6  2.2.2.2
5.5.5.5 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 20.4/22.4/24.8
3.3.3.3 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 17.0/19.9/23.0
7.7.7.7 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 58.5/67.5/73.1
4.4.4.4 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 26.8/41.6/56.6
1.1.1.1 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 0.546/0.585/0.609
6.6.6.6 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 34.6/60.9/90.5
2.2.2.2 : xmt/rcv/%loss = 3/3/0%, min/avg/max = 16.6/38.4/71.3
Comment by Edgar Akhmetshin [ 2022 Oct 14 ]

 I see the exactly the same effect whether running ubuntu-18.04/fping-4.0 or ubuntu-22.04/fping-5.1: when run with the i0 option the ping response times are 4-5 times longer than without it. 

Moving to the ZBXNEXT queue: add ability to set custom fping interval manually for icmp checks.

Comment by inyoungmin [ 2022 Dec 09 ]

I'm having the same problem too.
I hope it can be improved quickly.

Actually icmpping often fails by fping -i0 option in zabbix.

Comment by Gavrila Mihai [ 2024 Jun 15 ]

Hello. Do you have a resolution to this behavior? I have the same problem. Thanks!

Comment by Stuart McGraw [ 2024 Jun 17 ]

Don't know if this will help anyone but as a workaround until Zabbix can fix this, I wrote a simple program (I used C but I'm sure the same thing could be done with a bash script or any other language) that strips out or replaces any -i option in the arguments it receives, and then calls the system fping with the adjusted arguments.  In the zabbix_server.conf file, FpingLocation is set to point to my program rather than the system fping.

Generated at Sat Jun 28 07:55:54 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.