check_ping oddities

[Mascardo, Erwin]

>-----Original Message-----
>From: Dale Blount [mailto:nagios-list at dale.us] 
>Sent: Thursday, 29 September, 2005 16:51
>To: Mascardo, Erwin
>Cc: nagios-users at lists.sourceforge.net
>Subject: RE: [Nagios-users] check_ping oddities
>
>
>> >Hi,
>> >
>> >My check_ping is defined like this:
>> >
>> >define command{
>> >        command_name                    check_ping
>> >        command_line                    $USER1$/check_ping -H
>> >$HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 6 -t 20
>> >}
>> >
>> >Yet I get output at times like:
>> >
>> >PING WARNING - Packet loss = 71%, RTA = 89.44 ms
>> >(warn is 60%, crit is 80%, so WARNING is correct).
>> >
>> >and
>> >
>> >PING WARNING - Packet loss = 25%, RTA = 17.44 ms
>> >(warn is 20% and crit is 40%, so WARNING is correct).
>> >
>> >
>> >And now to the question.  How can 71% or 25% be a result 
>when 6 packets
>> >are sent?
>> >
>> >Thanks,
>> >
>> >Dale
>> 
>> I've seen this happen on some of our WAN hosts. Near as I can tell,
>> check_ping (we use check_icmp, but I saw it happen in the check_ping
>> days as well) bases its success rate on the number of 
>replies -- if you
>> use 5 packets as your standard, then it waits to hear the 
>response from
>> packet #4 before reporting its result. And it sends out 
>packets until it
>> gets that specified reply. (I know, I could read the source to get a
>> definitive answer...just feeling too lazy at the moment.)
>> 
>> In my situation, over an 800 ms WAN link, there was usually 
>time to send
>> 6 packets while waiting for the result on the 5th, so I'd get packet
>> losses of 16% when things were otherwise okay. What's puzzling me in
>> your situation is your latency -- what happened to me shouldn't be
>> happening to you with those kind of ping times.
>> Both of those links are small capacity and latency jumps with usage.
>
>Sometimes they loose 100% if they're full enough.  I'm not concerned
>with that now - I'm just curious why the math seems odd.  check_ping
>--help says:
>
>-p, --packets=INTEGER
>   number of ICMP ECHO packets to send (Default: 5)
>
>so it seems to me that if I change -p to 6, a 25% or 71% would never be
>possible unless it sends enough packets to get 6 back, then 
>divides 6 by
>that to get a percentage.  In that case, the usage text is wrong.

Right, that's what was happening with me, and seems to be happening with
you. In my case, I was getting 5 packets back, but 6 had been sent, so
5/6 resulted in 84% success or 16% loss. What's happening with you is
that you're getting 2 back for 7 sent (giving your 71% -- you have
"real" drops in there), or 6 back for 8 sent (getting the 25% result).

Looking at the source, there doesn't seem to be anything wrong with the
logic -- the loop which sends the packets runs for the number of times
specified on the command line, and the result of the check doesn't come
into play. Maybe I'm not reading it correctly, though.

On a different note,  you may want to make sure that your monitored
hosts aren't source-quenching your checks. We had that problem here when
we first switched to check_icmp.

--Erwin
############################################################

Intelsat is a global communications provider offering flexible and 
secure services to customers in over 220 countries and territories.  
Intelsat has maintained a leadership position for over 40 years by 
distributing video, voice, and data for television and content providers, 
government and military entities, major corporations, telecommunications carriers, 
and Internet service providers. Intelsat's reach, power and expanding solutions 
portfolio deliver information reliably and quickly to every corner of the globe.  

For more information, visit www.intelsat.com.

############################################################
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or 
distribution is prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and 
destroy all copies of the original message.  Any views 
expressed in this message are those of the individual 
sender, except where the sender specifically states them 
to be the views of Intelsat, Ltd. and its subsidiaries.
############################################################


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null