[Nagiosplug-devel] [ nagiosplug-Bugs-3552828 ] Define source ip for check_ping.

SourceForge.net noreply at sourceforge.net
Fri Apr 26 00:32:32 CEST 2013


Bugs item #3552828, was opened at 2012-07-31 15:53
Message generated for change (Comment added) made by laurentt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cálestyo (calestyo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Define source ip for check_ping.

Initial Comment:
Hi.

This is from the old / soon to be disabled again Nagios Plugins bug tracker that used to be at Nagios itself.
I've just copied this bug over. I'm not the original reporter and have no idea about the thoughts about this bug.

This used to be: http://tracker.nagios.org/view.php?id=268
--------------------------------------------------------------------------------
bva:
--------------------------------------------------------------------------------
There are thousand of inet aliases on same interface on Nagios host. And some of switches which I need to check, accepts ICMP only from certain internal addresses, but default route policy forward packets through wrong gateway. I couldn't change routing and settings on switches.

The solution [for me] is to specify the source address for check_ping.

Used nagios-plugins-1.4.15

[nagios]> ./check_ping -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1
PING CRITICAL - Packet loss = 100%|rta=5000.000000ms;3000.000000;5000.000000;0.000000 pl=100%;80;100;0
[nagios]>
[nagios]> route get 192.168.17.114
   route to: 192.168.17.114
destination: 192.168.17.112
       mask: 255.255.255.252
    gateway: cat1
  interface: vlan1
      flags: <UP,GATEWAY,DONE,PROTO1>
 recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
       0 0 0 0 0 0 1500 0
[nagios]>
[nagios]> ./check_ping2 -S 192.168.150.3 -H 192.168.17.114 -w 3000.0,80% -c 5000.0,100% -p 1
PING OK - Packet loss = 0%, RTA = 3.67 ms|rta=3.668000ms;3000.000000;5000.000000;0.000000 pl=0%;80;100;0

----------------------------------------------------------------------

Comment By: laurent (laurentt)
Date: 2013-04-25 15:32

Message:
you might as well want to check  ID: 3575281

----------------------------------------------------------------------

Comment By: laurent (laurentt)
Date: 2013-04-25 15:14

Message:
Hi,

I also think the source address option to check_ping and check_fping would
make sense.
btw, there is a a source selection option in fping

Here my setup:
I have a nagios server with several network interfaces as well.
I do not run nagios as root.
I want nagios to initiate checks from an interface that is not the default
interface (default route doesn't go through this it)
It's kind of easy, I use iptables and the owner module + policy routing
based on fwmark. It works for udp and tcp.
When it's about check_ping or check_fping, they both exec a setuid binary.
In the end the icmp check is initiated by root and is not matched by the
iptables+policy routing.

The patch isn't intrusive, you might not like it as it is but it definitely
adds an useful feature. nothing dubious about it imho.

I'm about to implement it and deploy it anyway, Thanks Cálestyo !


----------------------------------------------------------------------

Comment By: J. Bern (j-bern)
Date: 2012-08-01 09:38

Message:
This approach uses a dubitable feature of the underlying "ping" command
(which is absent from, e.g., fping) to work around the lack of access to
the routing config (or, for that matter, iptables SNAT) to solve the
*actual* problem. As soon as the switches need to be monitored, say, via
SNMP, it'll reappear with a vengeance.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3552828&group_id=29880




More information about the Devel mailing list