Problems with network at work-please help :)

[Thunderbirdaholic]

We have about 35 pcs (mix of 98se to xp) on a windows 2k server network. We have two 24 port unmanaged linksys switches running things. Our file server for the last two weeks has been giving our act and access database people a lot of disk and network errors. I've been working on this for a while but am not always the best at troubleshooting. Originally it was hooked up to a small 5 port linksys switch at the file server and the printer and server shared internet connection-took that out of the equation and hooked printer up to server via lpt port. Took out linksys lne100tx nic card and swapped with intel pro 100. That seemed to fix the problem for about a week and then it started happening again. The users are spread out on the two 24 port switches but the problem isn't isolated to one switch. There is users with the problem on both switches. I have network monitor running on the server and over the course of a day it seems there is a lot of dropped frames, does that matter? Any ideas on what to do next?

I have moved a couple of the databases off to another server and will have users test that tomorrow to see if it's network wide or isolated to one server but I'm at a loss of what might be happening. Any utilities that might help me solve this or ideas would be greatly appreciated.

Stumped

 

[Nutz]

Sound like your errors are happening either at the PHY or Data Link Layer. Check cables for proximity to EMI producers such as power cables and phlorescent lights. Something else I see alot of is duplexity mismatches between NICs and switches. Double check the duplex and lines speeds of the NICs that your having trouble with. Just keep in mind that ~70% of all network errors are cabling related and go from there.

It also occured to me that the machine you swapped out the NIC may not be your culprit. Another possiblity is line saturation to your server and frames are being blocked/dropped. Another thing could be a host on your network spitting out giants or runts. These can fubar things pretty quickly on low-grade network devices.

 

[JustinLerner]

In my opinion, moving ONE database to another server SHOULD resolve your problems because separate databases are now on separate drives, separate systems and access to databases is through different NIC's with separate IP addresses instead of one server NIC, shared drive.

Really though, you need to analyze where the problems are originating or what actions/events result in the errors. Troubleshooting/monitoring and finding the actual problem is the first task at hand.
Are the drives good? Are network connections/connectors certified/verified and have they been retested? Is drive response slow, are workers waiting all the time for file access? What do the users say? What other problems are occurring?

----
File sharing problems, locks, and violations may be occuring if the file server is just running the database as a shared application instead of as a client/server application. If the applications are not client/server but shared applications and multi-user enabled, then you may need to write some script that prevents multiple user access to any same file/record. (This is the old way of preventing sharing violations and I have no knowledge of databases.)

Are you running SCSI drives on your database/file server? If not, why not?
Always run critical data on SCSI. It can managed/block bad blocks on the fly (you loose the data in blocked blocks, but continual errors don't occur), IDE/Ultar ATA CANNOT do this, even with S.M.A.R.T. You may have a bad drive in your file server. Have you checked the drives for errors (something more advanced than SCANDISK)?

---
Decrease contention on your file server hard drives or array. If you do use SCSI (Ultrawide, Ultra2, or even Ultra160 is fine), separate your ACCESS and your ACT databases on to separate, individual SCSI drives or different arrays (if using RAID). If you don't use SCSI, you really should bite the bullet and install SCSI with a hardware RAID controller (single channel OK, since on most Adaptec Ultra 160 RAID solutions a single channel can support 3 arrays and JBOD or 4 arrays. (These arrays should be 0,1 for speed in my opinion, not 5. For example I would run something like 2 drives RAID 0 and mirror on 1 drive twice as big. Make sure system/file caching is on another drive, not the arrays or drives where your databases are stored.)

---
Decrease LAN delays on your file server by using either of three methods: Increasing NIC/LAN bandwidth, load balancing on your NICs or multilinking (or all three with Intel).

I'm inclined to believe that all you need is load balancing. For this, I recommend the Intel Dual 10/100 Server NICs. (One or two or more single port NICs for your server.) Adaptive load balancing (ALB) is a breeze with Intel NICs and works with any brand Ethernet SWITCH.
(Intel 10/100 S Dual Port Server Adapter [64 bit PCI adapter!!!], PILA8472C3, $229 retail;
Intel PRO/100+ Dual Port Adapter [32 bit version] is being discontinued, and is the same price $229, PILA8472;
Or two or more 10/100 S Server Adapters [32bit PCI], PILA8470C3, $80 each.)

It's also easy to implement adaptive fault tolerance (AFT) with the Intel NICs and this also works with any brand Ethernet SWITCH. (AFT and ALB cannot be used together, except automatically by the 802.3ad standard or FastEtherchannel/link aggregation.)

Multiple Intel NIC's can also multilink in conjunction with any SWITCH that also employs the 802.3ad standard, like the Linksys dual Gigabit/24 port switch EF24G2. $460 at Provantage.com.
802.3ad acts to link multiple NICs/ports for load balancing and adaptive fault tolerance and one way full aggregate bandwidth. 802.3ad works with ALL Ethernet protocols, even the non-routed ones like NetBEUI.
-- This switch is not like the typical Linksys 'SOHO' switch, but it has a high forwarding rate, bandwidth backplane/fabric with dual Gigabit to boot. Here's the reference: http://www.linksys.com/Products/product.asp?grid=29&prid=417

If you have the right type of CISCO or Intel SWITCH, you can also use Fast EtherChannel/Link aggregation (which is Cisco proprietary) and works similar, but better than the 802.3ad standard, by functioning as both multilinking (aggregating bandwidth full duplex, full bandwidth on linked NICs/ports) AND load balancing and fault tolerance on the same NICs to switch setup. For this, you must use the right type of NICs and either CISCO or Intel SWITCHES which have the Fast EtherChannel/Link aggregation (proprietary) capability, not just the 802.3ad standard. Intel and Cisco switches vary in price, check their websites and online vendors for the type of switch you need which must support 802.3ad AND Fast or Gigabit Etherchannel/Link Aggregation. This does not work with non-routed protocols (NetBEUI and others).

Additionally, if you have a Gigabit SWITCH, then you can add a Gigabit adapter to your loaded server and connect this to the Gigabit uplink port with cross-over cable. Most Gigabit adapters now require 64bit PCI slots.

---

Really though, you first need to analyze where the problems are originating or what actions/events result in the errors. Troubleshoot, monitor and find the actual problem.
Read this: http://www.itpapers.com/cgi/PSummaryIT.pl?paperid=10045&scid=60

 

[Nutz]

Well, I read JustinLerner's post and he made some good points. But given the errors you're recieving, it appears its an error on the network itself and not with the servers (except if its in the NICs). I'll get back with you on how to look for runts and giants. In all honesty its been so long that I've forgotten. From my experience, I'd have to guess that your server is getting slammed and its buffers were getting full and packets were lost. If this happens for an extended time and your system nevers get the chance to catch up, then you'll start having these sorts of problems like your experiencing. A quick fix is to keep the server connected to the switch at 100BaseT and manually force everyone else down to 10BaseT. This will help ease the burden on the switch and the server's link. Oh, that's another thing. On lower-end switches like the SOHO Linksys, netgear, DLink jobbies they don't have the massive switch fabric that something like a Cisco would. In addition to that, they can't process as many frames per second. If it gets too much traffic to process it may start "port blocking". What that is is when too much traffic is passing through the switch to handle. It will finally get to a point and says, "Okay, thats it. No more traffic can come from this port, that port, and that port". Its only for a fraction of a second, but its enough that it will result in lost packets/frames.

Hope this helps.