Just went through this thread; apex1x listen to TheLad, he knows what he is talking about and is pointing you in the right direction.
I have had this issue my self on two of my clients networks. The resolution was to replace the switches in one case; the other was to force the server NIC to 100MB Half Duplex (servers and network devices should never be set to auto, only clients should be left with this type of setting).
In the first case the 3Com Superstack switch was rebooting it's self for some stupid reason we never dug to deeep into. Took about two weeks of testing and monitoring to find out what was causing the issue. Once we found that packets were stopping at the switch, not the server, we watched the switch. Sure enough we were able to see the stupid thing reboot it's self. We installed a Cisco switch; problem solved (infact now the network bandwidth is better, Cisco has a better product; 3Com keeps screwing Ethernet up when ever they make a change to thier firmware).
The second case was much more easy to figure out. We didn't look to much into the Cisco switch they had, the logs we would get out of the switch showed it was not doing what the last issue did. The switch was self installed by the client, so all default settings were still in place (everything auto). So we nailed the entire swith (all ports) to 100MB HalfDuplex and did the same to the server. The problem went away; no more clients would disconect.
Another thing to look at would be the MAXIMUM PHYSICAL PACKET SIZE setting; I see a lot of admins that think they are savy narrow this setting down to the ethernet spec (1524 I think, TheLad may be able to correct me). In Intel based NIC running NetWare 5 and above, this just screwes up communication on the server. The default setting is 4224. More than likely this won't be the problem though. Brent Schmidt CNE, Network +
Senior Network Engineer
Why do user go into a panic when a NetWare server goes down, but accept it as normal when a Windows server goes down?