LAN DUMP

[Matthew Clarke]

Is it possible that one machine (hp e-Vectra PIII)connected to a hp e3000 could be causing LAN DUMP's which result in the system having to be brought down, and causing all users to have to be logged off. This is a major concern of ours, and the LAN DUMP only seems to happen when a certain computer is connected to the the e3000 via teminal emulation. If there is not a session open on this machine then the problem does not seem to occur. We have checked the network connection and the LAN DUMP happens with different network cables (connections) and different hub settings. We have since changed the network interface card, added more memory and countless other options to try and figure out this problem and possible solutions? We have created DUMP Tapes when bringing the system down, but nothing has reconciled this problem as of yet. This only started happening also after the upgrade from 6.0 to 6.5. Any help on this problem is greatly appretiated.

Thanks,

Matt Clarke

[Sebastien Parayre]

Matthew,

The suggestion would be run a Packet Trace from the Vectra to the HP3000, and start the session, so someone can look at the trace and try to identify what is could be causing the LANDUMP on the HP3000...
It seems that you took all the necessary preliminary steps, so a packet trace would really help you out.

[Matthew Clarke]

Sebastien:
Can you send me instructions on how to do a packet trace? I am still knew with the whole e3000 and mpeix formats.

Thanks Matt Clarke

[Sebastien Parayre]

Matthew,

To perform a Packet Trace, you will need a software to do so, the software usually runs on a workstation (Microsoft, Unix?) there are several out there, for example:
-Sniffer see www.sniffer.com (they have a free trial package with instructions).

Unfortunately it is easy to capture a trace, but much more complex to analyze it. I would recommend that an experienced network engineer analyze the trace to try to determine if and what could be the problem with this workstation.

Yours Truly,
Sebastien

[Gerhard Roets]

Matthew

Start by reading this document for background info.

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/mpeix/onlinedocs/36922-90039/36922-90039_top.html&con=/mpeix/onlinedocs/36922-90039/00/00/59-con.html&toc=/mpeix/onlinedocs/36922-90039/00/00/59-toc.html&searchterms=linkcontrol&queryid=20010220-132610

1.)Now after that has happened again try to reset a DTC with a power cycle if its download aborts rapidly after starting and restarting again ad infinitum. This roughly points to a broadcast storm.

Check for network loops.

See if you have internet connection sharing set up on that Vectra machine. Disable it for a test.

2.)Enter linkcontrol @;status=all and compare its values to that in the first document, this could give a lot of info. If all else fails post the data you got.

3.)Create a printout of nscontrol status=services before the problem occurs and then do it again after the problem occured and compare these two. This ought to indicate to you if a specific service failed. Type help nscontrol for other formatting and verify that my syntax for that command is correct im not in front of an hp now to verify it.

4.)Get the user who ussually works on the vectra to work on another terminal/pc and see if the problem recreates itself without that vectra on the netowrk that could definitely indicate a software problem in that user session.

5.)Ping the server and pc constantly till this problem happens again and see if a tcp/ip stack fails you could have a conflicting mac-address. PS this is extremely unlikely.

6.)Ohhh and when you install a sniffer make sure its on the same hub / coax not a switch else you will not see all the network traffic. If you have to put it on a switch put the switch port of the sniffer in a flooding state so you can get all the data. Under linux there is a tool called tcpdump to capture network data, but you must be logged in as root for it to work.

Gerhard Roets