[prev in list] [next in list] [prev in thread] [next in thread]
List: netsaint-users
Subject: Re: [netsaint] Problems with NetSaint 0.5b3
From: Karl DeBisschop <kdebisschop () infoplease ! com>
Date: 2000-03-22 15:46:14
[Download RAW message or body]
Tad Johnson wrote:
> >
> > Well that will not matter as NetSaint still shows the external
> > system down. Exactly what parameters need to have the -p 1 at the
> > end. I modified the POP, HTTP and NNTP and inserted the 20 60 500.0
> > 1000.0 at the end all that gave me was invalid augments. The problem
> > is that eventually NetSaint says that the external host is down when
> > it is not.
> >
>
Each of the plugins will work from the command line, and will give you a
summary of the proper arguments. That is your best and most reliable
means of being sure your configuration is correct. This is because the
pluginsand server can be upgraded independently. You may have 0.0.4
srver, but if you plugins are recent the syntax for check_ping is
check_ping $HOST 20 60 500.0 1000.0 -p 1
All the recent plugins use -p 1 at the end of the command, but older
plugins omit the '-p'
The -p 1 for check_ping means send one packet - this make check_host alive
much more efficient, because if one packect comes back, which it usually
will, you just continue right on - rather than waiting a full second for
each packet when you're only trying to find if it's up. For network
performance, obviously, you will send more packets.
>
> check_ping $HOST 20 60 500.0 1000.0
>
> means give me a warning at 20% packet loss, and a critical
> at 60% packet loss, a warning at 500ms, and a critical at 1000ms.
> This works fine under 0.0.4. I would go back to 0.0.4. 0.0.5 was a
> nightmare for me under FreeBSD, and two of the CCIE's at our
> mae-west pop confirm the same for them.
>
> Tad
0.0.5 was not great, but it was as stable as 0.0.4 for me. I'm looking
forward to 0.0.6, but I don't know that I can second this recommendation.
> >
> > I can not use the check-ping command to see if the host is alive
> > since it is configured not to respond to pings. I have therefore used
> > the check-dummy command with a parameter of 1 which should always
> > indicate that the host is up. Yet over time NetSaint eventually tells
> > me otherwise and never recovers.
It is a little redundant, but probably the best you can do if you do not
reply to pings is use the check_tcp plugin for check_host_alive with one
of the open ports (pop, http, which ever). It should be better than
check_dummy, I would think. Probably pick your most reliable service and
use that port. Or use check_udp if you have an open UDP port. Bottom
line is that check_host_alive is needed by netsaint logic, and is only as
reliable as the service you use to make that determination.
For your case, it might even be worth setting up an inet service on some
obsure port to just allow connects, and after a second or two then
diconnect if the session is still hanging around. Make it with no shell or
anything - just open the port and do nothing -- that might work with
check_tcp, it would be obscure and could be very secure if only know hosts
were allowed to connect anyway, and would do nothing else so could
presumedly be very reliable. Just a thought.
--
Karl DeBisschop
617.542.6500x2332 (Fax: 617.956.2696)
Information Please / Family Education Network
http://www.infoplease.com - your source for FREE online reference
[Attachment #3 (text/html)]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tad Johnson wrote:
<blockquote TYPE=CITE>>
<br>> Well that will not matter as NetSaint still shows
the external
<br>> system down. Exactly what parameters need to have the -p 1 at the
<br>> end. I modified the POP, HTTP and NNTP and inserted the 20 60 500.0
<br>> 1000.0 at the end all that gave me was invalid augments. The problem
<br>> is that eventually NetSaint says that the external host is down when
<br>> it is not.
<br>>
<br> </blockquote>
Each of the plugins will work from the command line, and will give you
a summary of the proper arguments. That is your best and most reliable
means of being sure your configuration is correct. This is because
the pluginsand server can be upgraded independently. You may have
0.0.4 srver, but if you plugins are recent the syntax for check_ping is
<p>check_ping $HOST 20 60 500.0 1000.0 -p 1
<p>All the recent plugins use -p 1 at the end of the command, but older
plugins omit the '-p'
<p>The -p 1 for check_ping means send one packet - this make check_host
alive much more efficient, because if one packect comes back, which it
usually will, you just continue right on - rather than waiting a full second
for each packet when you're only trying to find if it's up. For network
performance, obviously, you will send more packets.
<br>
<blockquote TYPE=CITE>
<br>check_ping $HOST 20 60 500.0 1000.0
<p>means give me a warning at 20% packet loss, and a critical
<br>at 60% packet loss, a warning at 500ms, and a critical at 1000ms.
<br>This works fine under 0.0.4. I would go back to 0.0.4. 0.0.5 was a
<br>nightmare for me under FreeBSD, and two of the CCIE's at our
<br>mae-west pop confirm the same for them.
<p>Tad</blockquote>
0.0.5 was not great, but it was as stable as 0.0.4 for me. I'm looking
forward to 0.0.6, but I don't know that I can second this recommendation.
<blockquote TYPE=CITE>>
<br>> I can not use the check-ping command to see if the host is alive
<br>> since it is configured not to respond to pings. I have therefore
used
<br>> the check-dummy command with a parameter of 1 which should always
<br>> indicate that the host is up. Yet over time NetSaint eventually tells
<br>> me otherwise and never recovers.</blockquote>
It is a little redundant, but probably the best you can do if you do not
reply to pings is use the check_tcp plugin for check_host_alive with one
of the open ports (pop, http, which ever). It should be better than
check_dummy, I would think. Probably pick your most reliable service
and use that port. Or use check_udp if you have an open UDP port.
Bottom line is that check_host_alive is needed by netsaint logic, and is
only as reliable as the service you use to make that determination.
<p>For your case, it might even be worth setting up an inet service on
some obsure port to just allow connects, and after a second or two then
diconnect if the session is still hanging around. Make it with no shell
or anything - just open the port and do nothing -- that might work with
check_tcp, it would be obscure and could be very secure if only know hosts
were allowed to connect anyway, and would do nothing else so could presumedly
be very reliable. Just a thought.
<pre>--
Karl DeBisschop <kdebisschop@alert.infoplease.com>
617.542.6500x2332 (Fax: 617.956.2696)
Information Please / Family Education Network
<A HREF="http://www.infoplease.com">http://www.infoplease.com</A> - your source \
for FREE online reference</pre> </html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic