HPUX networking, netstat command

[Ronald W. Widlewski]

When executing the netstat -s command
There is an incrementing counter under
" xxxxxx ICMP messages dropped "
where xxxxxx is incrementing < 500
daily. There are 5 other HPUX (K and L)
9000's on the same network segment. The
ICMP messages dropped counter does not incremnet on the others and is value=0.

Any ideas what would increment this ?
counter on one system only ?

Thanks, in advance.
Ron Widlewski

[harry d brown jr]

Is someone pinging that IP or is that machine trying to ping a machine that doesn't exist or is having network issues?

live free or die
harry

[sven verhaegen]

well

ICMP is in fact part of the IP functionality , it is used for specific message relaying by the systems themselfs , in fact the most known icmp is probably 'icmp redirection' , meaning that the end routing node couldn't forward your packet (because it's interface to that network is down) and knows an alternate path or machine to the same network , lots of icmp type messages exist and the most are not sent by the HP-UX , they are normally sent bij a remote system/router/switching device , so the message can be comming from any possible direction , to really know what it is you should monitor (trace) the system to see what type of ICMP's you find...

[Sridhar Bhaskarla]

If you are NFS particularly over UDP, there is a good possibility of you seeing these errors. Depending on how your system is connected to the network, ICMP messages (not only) may get dropped to the MTU fragmentation issues. However, TCP/NFS can circumvent this problem by using PMTU (Path discovered MTU).

-Sri

[Ronald W. Widlewski]

A note to clarify my initial posting.

I have two K460, two L class and one
RP systems all running HPUX 11, same
patch levels, all running NFS mount
points with WAN mounted disk and
Oracle databases. Only one of the
5 systems is displaying a value
other than "o" in the ICMP messages
dropped netstat -s command output.

The system and environment is close
enough that one would expect all
systems to record similar statistics

The counter has been incrementing
since near the beginning of the year,
24 hours a day, accumulating stats.

[Sridhar Bhaskarla]

Hi Ron,

Systems may be similar but the fragmentation of the packets is based on how the systems are routed/connected not to ignore the capabilities of the switches they are connected to.

Another interesting test I would do, if possible, is to swap the switch ports of the dropping server and non-dropping server and see if the behaviour is exhibited on the other server.

BTW, are you seeing any "NFS server not responding" on the problematic server often?.

-Sri

[Steven Sim Kok Leong]

Hi,

One of the best ways of finding out what is happening is to run ethereal, tcpdump or nettl to monitor and sniff ICMP traffic to find out the source of these packets and the ICMP packet type.

Ethereal is most intuitive with a graphical interface for parsing each portion of the packet in a hierarchical tree-like fashion for details.

http://www.ethereal.com

You will need GTK installed as well.

Hope this helps. Regards.

Steven Sim Kok Leong

[sven verhaegen]

I have to agree with the last remark here , even if systems are identical , you have no idea where the icmp are comming from , is it from your own system or is it from the connecting device ... you are completely in the blue about that , it is imperative to use soething like tcpdump or nettl to see what in fact the icmp is telling , it is true that even the same machines types on the same segment could be receiving icmp or not depending on

a/ what they ask
b/ who they ask it to
c/ what kind of HW they have to pass to get the message relayed

d/ even the internal setting could play a rol as with the remark on the fragmenting from the previous entries

only make sure that when you look at this thing with tracing yoiu have such a trace looked at/analysed by a guy knowing the ip protocol (if you are not knowledgable on the subject) as traced packets are usually cryptical for non-network specialised persons

[Ronald W. Widlewski]

Thanks, all,

I have a couple things to try.
We did not look for the source-IP
as I was thinking that it may have been a problem/configuration issue associated
with HP RPseries systems.