2

I'm attempting to utilize the flow probe argus to determine "node liveliness"/reachability.

I am currently working on handling ICMP status, but would like to derive a method to determine if a ping "would be expected" to timeout.

This question isn't relevant to argus necessarily:

What are the circumstances where a node that pings another node will receive no data back? Is it only when a client "timeout" would be expected to occur?

I am aware that ICMP messages will be sent without an ICMP message coming in to a node, if there are a variety of problems reaching the node.

[Update]

By "no data back", I mean 0 bytes returned, not just ICMP bytes. No bytes at all. And please discount the idea of throttling or firewall policies changing, as this would cause a timeout, and be a good "bad response" that I'm trying to detect.

Consider the following:

ra -S 127.0.0.1:561 -s ltime saddr daddr dport sport sbytes dbytes flgs state - icmp (man page)

              LastTime            SrcAddr            DstAddr  Dport  Sport     SrcBytes     DstBytes      Flgs State

2014-01-02 16:56:17.563848      192.168.1.31       192.168.2.22.0x21f9 0x0008           98            0  e          ECO
2014-01-02 16:56:18.624553      192.168.1.31      192.168.2.252.0x21e6 0x0008           98           98  e          ECO
2014-01-02 16:56:18.724784      192.168.1.31        192.168.2.1.0x21eb 0x0008           98           98  e          ECO
2014-01-02 16:56:18.482095      192.168.1.31       192.168.2.10.0x21ef 0x0008           98            0  e          ECO

192.168.1.31 sent a ping with check_ping.c, a nagios plugin. check-ping is used to send a single ICMP ECHO packet.

192.168.2.22 and 192.168.2.10 replied with 0 bytes. This should never happen, and usually doesn't.

check-ping is used to send a single ICMP ECHO packet.

In order to check for timeouts/unreachability of nodes, I am verifying that checking dbytes for 0 length is my best condition.

2
  • "ping" (ICMP echo) returns whatever was in the request. If the request was zero length, logically, the reply would be too.
    – Ricky
    Jan 2, 2014 at 22:32
  • Thanks Ricky. I updated the question with more detail; but importantly what I see as "0 bytes" really means absolutely no bytes returned: no ICMP response, no frame, no nothing. 0 bytes. This seems like it would generally be seen by ping as a situation that would cause a "timeout," but I can't determine this without some input. So, I'm saying, the request isn't zero length, and 0 bytes are returned; so is this condition ever possible in "a non-timeout causing situation"? Thanks.
    – brandeded
    Jan 3, 2014 at 14:29

1 Answer 1

4

If you send a echo request and get nothing back, there are three possible reasons:

  1. Your echo request didn't reach the target, because of a network failure, congestion, filtering or some combination.
  2. The request reached the target, but the target couldn't respond because of a failure or misconfiguration of the target itself.
  3. The echo reply didn't get back to you due to a network failure, congestion or filtering.

To answer your question more directly, it is up to you, the sender, to decide what to call this condition. You can call it a 'timeout,' 'polling failure,' 'Device down' or something else. If you're looking for a diagnosis, you can't tell from just a lack of one ping response where the problem lies. You will need more information.

3
  • Thanks Ron. Judging by your background, I'm guessing you have some experience with argus. This is generally what Carter also stated. However, considering the fact that icinga didn't alert (and would have with a single ping "timeout"), it is a mystery. Also, as stated in Carter's reply, the flgs field would reflect a status of such badness in the ICMP reply, which it only state e(Ethernet encapsulated flow), not I, U, R, or T (ra man). This all means: other than a "timeout," what can cause a 0 byte response to an ECHO?
    – brandeded
    Jan 4, 2014 at 19:21
  • I've actually never used Argus. But since Cater seems to be the guy who wrote it, he probably knows best. You said in your original post that 192.168.0.22 replied with 0 bytes. Is that the same thing as "didn't reply?" One possibility (I don't know your network) is that you are not capturing all the traffic, so Nagios heard the reply, but you didn't capture it.
    – Ron Trunk
    Jan 4, 2014 at 22:26
  • Thanks Ron. Sorry for the assumption. Yes, I'll have to go more thorough into the records on Monday and follow up on the thread. The probe sits in a place where all packets between the two hosts would be mirrored (and the throughput (pps) is such that it wouldn't've been dropped). I'll accept your answer as it is correct 99.9% of the time!
    – brandeded
    Jan 5, 2014 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.