Discussion Locked

Intermittent TCP/IP Problem

0 helpful
17 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
We have a Compaq Proliant server that is part of our e-commerce process. We use IBM's MQ Series on that server to trade documents back and forth to our trading partners. However, intermittently, that server loses communication to our LAN. Looking in the Event Viewer, we can tell when it has lost it's connection, but the reason remians elusive. There have been days when it has retained it's communication, and then for some reason, it cannot even "talk" to any device on or network. I verifiedthis by trying to "ping" that server when it's going through one of it's episodes, and likewise tried pinging from it. Then, from no manual intervention, it somehow re-establishes connectivity. Anyone have any ideas how I can track the source of this problem further ?

17 replies

by mackem

The first thing i would check here is the cabling. you may have a break in the cable which you can not see. If you can't test the cables then change all cables to that server, and see what happens.
Best of luck

by tbui

After checking the cables, Then if still a problems, Replaced the cables. Then if the problems still exist, Then re_Install Tcp/Ip.
If you still have the problem then the next thing is to replace the Nic's and reinstall the latest driver. Hopes this will help you trouble shoot this problems.

by some guy in seattle

There might also be an issue with network topology. If this machine is on a hubbed segment, and there are other machines (particularly servers) there as well, there could be a problem with network saturation.

If possible, try and move the mostbusy machines to a switch. Or try moving this machine to a different port on your hub/switch to eliminate problems with that. Look at your interface settings - if it's running at 10MB, try setting to 100MB. If it's set to full duplex, set to half(many drivers/NICs have problems running at full duplex and sometimes cannot handle the load).

Hope that helps,

by sean_tomas

This seemed to be the problem. Looking at the topography, I noticed it was hooked up to a switch, when really for all the communication this box does, it should have been connected to a switch. Thanks for the help!!!!

by dlongan

It could be quite few things causing such failures. You will need to document the failures detailing everything possible from data/time to what occurs in the event logs prior to the failures.

The following are some basic trouble areas to look at.

1. cabling
2. hub/switch port
3. hub/switch port config
4. nic card
5. nic configuration
6. routing

by picturethat

I had a simular issue and removed the TCP/IP stack from the server, rebooted then reinstalled TCP/IP. This solved my issue.

by frobo

Hi ,

guess you have checked every thing arround the Server, like other's described above. Maybe the problem is somthing diffrent, like an screensaver who uses 3D (3D-Pipes, 3D-Marquee....). When you chose this things, the NIC's have no chance to send a bit.

I would take the performance Monitor and establish a long term session, for later analyzes. Chose things like Memory, Prozes ..... you now the stuf i mean.

After this make an analyzes of the data you collected with perfmon.

Perfmon is an very good tool for such things,
with this method i found an faulty NIC in one of our Servers in the DMZ.

regards

Frobo

by sean_tomas

Thanks for the tips!!! These are things I really never considered. However it doesn't appear to likely though because we don't use screen savers on our servers. But the PERFMON tip was excellent!!! Thank you for the help though !!!

by dennis_herr_jr

You might also check the environment that your cabling is running through. If you have a lot of electronic noise, it can cause some problems if your cabling isn't shielded.

by sean_tomas

Not totally disproven, but it seemed that there was an issue with the server being hooked up to a hub, not a switch. Thank you for the help though !!!

by stillatit

If your server is dialing out for any reason, it is probably losing its routing for the duration of the calls as it picks up a new IP address and default route. When the call terminates, it puts back the old information.

If you can catch the server during one of these periods, print its routing table (ROUTE PRINT from a command window) and see if that is the problem. If its default route (for 0.0.0.0) is not your router, that is what is the tip-off.

Try putting persistant routes, using the route command with the /p option, for your local segment, and for each of your other lan and wan segments.

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

Whether or not you are dialing out, putting in the persistant routes for your own lan and wan segments can also preventproblems if a local router advertises a bad route for any reason.

Good luck.

by sean_tomas

Thanks for the tip!!! Our server doesn't do any dialing out, just straight TCP/IP over LAN. Thank you for the help though !!!

This discussion is closed to new replies.