I've been working with zabbix for a few years in different infrastructures but I have to post on this forum for the first with a strange behaviour I can't really understand. So why not asking for some help.
I'm using a simple check to ping my hosts from my zabbix proxies and ensure they are up -> icmppingloss[{HOST.IP},5,500,,2000]
This works fine for 99% of my servers but I have some servers which are not in the same network of the proxies. We have some NAT rules through our firewalls and a VIP and this works fine with our items using snmp. Keep in mind I can't change the network configuration at the moment.
Icmppingloss always return 100 on those servers. Ping and fping both work manually from the proxy to those servers. I checked with tcpdumps that the ping was setup correctly and that I could see both icmp echo and reply from the proxy to the server. Makes sense because it works manually.
So I checked how zabbix is using fping to put myself in the same conditions. I understood that zabbix put the IP it wants to ping in a /tmp/zabbix_proxy_xxxxx.pinger file and run it like this -> /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/zabbix_proxy_28968.pinger;
So I made a file with one of my problematic @IP (/tmp/toto) and another one that works (/tmp/tata) and got those results :
# /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/toto
171.50.142.202 : [0], 84 bytes, 1.56 ms (1.56 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [1], 84 bytes, 0.49 ms (1.02 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [2], 84 bytes, 0.48 ms (0.84 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [3], 84 bytes, 2.13 ms (1.16 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [4], 84 bytes, 0.48 ms (1.02 avg, 0% loss) [<- 172.16.116.111]
# /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/tata
192.168.1.201 : [0], 84 bytes, 0.20 ms (0.20 avg, 0% loss)
192.168.1.201 : [1], 84 bytes, 0.23 ms (0.21 avg, 0% loss)
192.168.1.201 : [2], 84 bytes, 0.22 ms (0.21 avg, 0% loss)
192.168.1.201 : [3], 84 bytes, 0.23 ms (0.22 avg, 0% loss)
192.168.1.201 : [4], 84 bytes, 0.22 ms (0.22 avg, 0% loss)
I got a result without any losses but the output added "[<- 172.16.116.111]" that I think is the cause of my problem. Is there something I missed? A known bug? a workaround? Any help is welcome.
I'm using a simple check to ping my hosts from my zabbix proxies and ensure they are up -> icmppingloss[{HOST.IP},5,500,,2000]
This works fine for 99% of my servers but I have some servers which are not in the same network of the proxies. We have some NAT rules through our firewalls and a VIP and this works fine with our items using snmp. Keep in mind I can't change the network configuration at the moment.
Icmppingloss always return 100 on those servers. Ping and fping both work manually from the proxy to those servers. I checked with tcpdumps that the ping was setup correctly and that I could see both icmp echo and reply from the proxy to the server. Makes sense because it works manually.
So I checked how zabbix is using fping to put myself in the same conditions. I understood that zabbix put the IP it wants to ping in a /tmp/zabbix_proxy_xxxxx.pinger file and run it like this -> /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/zabbix_proxy_28968.pinger;
So I made a file with one of my problematic @IP (/tmp/toto) and another one that works (/tmp/tata) and got those results :
# /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/toto
171.50.142.202 : [0], 84 bytes, 1.56 ms (1.56 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [1], 84 bytes, 0.49 ms (1.02 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [2], 84 bytes, 0.48 ms (0.84 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [3], 84 bytes, 2.13 ms (1.16 avg, 0% loss) [<- 172.16.116.111]
171.50.142.202 : [4], 84 bytes, 0.48 ms (1.02 avg, 0% loss) [<- 172.16.116.111]
# /usr/bin/fping -C5 -p500 -t2000 2>&1 </tmp/tata
192.168.1.201 : [0], 84 bytes, 0.20 ms (0.20 avg, 0% loss)
192.168.1.201 : [1], 84 bytes, 0.23 ms (0.21 avg, 0% loss)
192.168.1.201 : [2], 84 bytes, 0.22 ms (0.21 avg, 0% loss)
192.168.1.201 : [3], 84 bytes, 0.23 ms (0.22 avg, 0% loss)
192.168.1.201 : [4], 84 bytes, 0.22 ms (0.22 avg, 0% loss)
I got a result without any losses but the output added "[<- 172.16.116.111]" that I think is the cause of my problem. Is there something I missed? A known bug? a workaround? Any help is welcome.