(Nagios-Ping)

[Paulus, Jake]

This can't be a layer 3 issue. ICMP doesn't support retries so nothing
in the middle should try to resend or duplicate the packet. Only layer 1
(a hub) or layer two (a host sending the same packet from two different
MAC addresses) will do this. Though if you have any redundant in-line
transparent proxies in the path - I might label them as suspect as
well.... 

The only way a hub should be able to do it is if a hub connects two
switches together and a switch loop exists at that spot. Both switches
that receive the frame would carry it on to its destination. I want to
say that if you have a switching loop you'd notice it in other places.

In the multi-homing situation, we have two NICs in the same server on
the same subnet with the same IP address but different MAC addresses.
Both try to send responses and so show up as duplicates - not sure why
though as I would suspect the sequence numbers would be off in the
echo-reply? The host shouldn't be sending the exact same packet out both
NICs...only load sharing some packets on one and some on the other...

On a server that really only has one NIC - I would look for errors on
the switchport or the host. I suppose if the IP stack on the host saw
errors it could retry right away on it's own even though the packet
might have been ok? Just an idea...

-Jake

-----Original Message-----
From: Paul Weaver [mailto:paul.weaver at bbc.co.uk] 
Sent: Wednesday, August 27, 2008 9:00 AM
To: Paulus, Jake; Nagios Users Mailinglist
Subject: RE: [Nagios-users] (Nagios-Ping)

> From: Paulus, Jake [mailto:jpaulus at sourceinterlink.com] 
> Sent: 27 August 2008 13:50
> To: Paul Weaver; Nagios Users Mailinglist
> Subject: RE: [Nagios-users] (Nagios-Ping)
> 
> I have this issue as well. In my case I believe it exists 
> because servers are improperly multi-homed; this is a server 
> configuration problem, not a network one. I have brought this 
> issue to the server administrator's attention and they are 
> unaware of any impact (probably because TCP retries are 
> hiding this) it causes to users and so have chosen to take no action.
> 
> -Jake

I'd be tempted to believe this is the case in two of the worst offenders
-- both outside provided machines -- but one of the machines only has a
single connection to a switch, so the compass swings back to some
OSPF/HSRP issue. 

As to people ignoring issues that TCP hides, we have that problem. A
friend from a fairly large company was suffering from a 3% packet loss
on one switch last week, which caused havoc with a UDP based system they
had. The network guys refused to believe there was a problem because
outlook was still working (even 80% packet loss doesn't affect exchange
-- it's slow and crashy enough anyway)

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
					

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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