10 tips for troubleshooting slowdowns in small business networks

A sluggish network can mean cranky users, loss of productivity, and big headaches for the IT staff. But solving--and even preventing--slowdowns is a whole lot easier when you know the most likely culprits. Here are some basic problems that small business IT pros may encounter.

This article is also available as a PDF download.

Network congestion and slowdowns--whether caused by faulty hardware, negligent users, viruses or spyware applications gone wild, or other factors--lead to serious headaches for network administrators and support personnel. By keeping a wary eye tuned for the following 10 items, IT professionals can help prevent the most common causes of network slowdowns.

#1: Bad NICs

Intermittent network errors, particularly those isolated to a specific workstation or server, can often be traced to a failing network interface card. When you believe a network adapter may be failing, visually inspect the card's LED link lights.

A solid green (or amber) LED indicates the NIC has a good active physical connection with another network device, such as a network switch or router (blinking LEDs typically indicate the NIC possesses an active connection and is processing network traffic). If the LED is not lit green, it's likely the network adapter is disabled within Windows or doesn't have an active connection to the network. It's also possible the cable plugged into the NIC is connected to a nonfunctioning wall-jack or faulty network port.

If you can rule out nonfunctioning wall-jacks and faulty network ports (the easiest method of doing so is to connect the same network connection to a laptop known to have a properly functioning network adapter), and if the network adapter is properly enabled and configured in Windows, it's likely the NIC is bad and requires replacement.

#2: Failing switches/routers

Many network slowdowns are foreshadowed by strange occurrences. For example, regular Web traffic may work properly, but e-mail may stop functioning. Or, regular Web traffic may work properly but attempts to connect to any secure (HTTPS) sites may fail. In other cases, Internet access simply ceases across the board.

Often the best remedy for inconsistent network outages and/or slowdowns is to reboot or power cycle the network's routers/switches. If local network connectivity exists (if users can view and access network shares) but they are not receiving e-mail from external users or cannot access the Internet, rebooting or power cycling the WAN modem can often return the network to proper operation.

If you're having to reboot or power cycle a piece of network equipment consistently, make sure that it's connected to a quality uninterruptible power supply. Power fluctuations often result in confused switches and routers. If a network device is connected to a good UPS and still frequently experiences trouble, it may be necessary to replace the failing switch, router, or modem.

#3: Daisy chaining

As organizations grow, particularly small businesses, outside IT contractors often implement simple solutions. Many consultants choose to simply add a five-port router to an existing four-port router/firewall. Small businesses everywhere boast just such a setup.

However, as switches are added to a network, data packets must navigate additional hops to reach their destination. Each hop complicates network routing. Depending upon the amount of traffic a network must support--and even a small dentist's or doctor's office can easily stress 10/100 Mbps systems due to X-ray imagery, patient file information, and other data--the addition of an extra hop or two can spell the difference between a smooth running network and one that frequently slows employee productivity to unacceptable levels.

Resist the urge to daisy chain multiple network switches and routers. Instead, plan for capacity. Or if unforeseen growth has resulted in successive connected switches, eliminate as many devices as possible through consolidation to a more potent and scalable unit.

#4: NetBIOS conflicts

NetBIOS, still in use on many Windows NT 4.0 networks in particular, contains many built-in processes to catch and manage conflicts. Occasionally, however, those processes don't handle conflicts properly. The result can be inaccessible file shares, increased network congestion, and even outages.

Guard against NetBIOS conflicts by ensuring older Windows systems all receive the most recent service packs. In some cases, Windows NT 4.0 systems having different service packs will generate telltale NetBT (ID 4320) errors.

Strange network behavior can also occur when two systems are given the same computer name or when two systems both believe they serve the master browser role. Sometimes the error will log itself as Event ID 8003 in a server's system log. Disabling WINS/NetBT name resolution (only if it's not required) can eliminate such issues.

If disabling NetBT is not an option, such errors can often be eliminated by identifying the second system that has the same computer name within the same domain and giving it a new name or by restarting the Netlogon Service on the domain controller. Yet another option for eliminating legacy NetBT issues is to search a system's LMHOSTS file for inaccurate or outdated entries. Some IT professionals claim they've solved similar errors by disabling and re-enabling the NIC on the offending system.

#5: IP conflicts

Windows typically prevents two devices with the same IP address from logging on to the same network (when using DHCP). But occasionally, two systems with the same address wind up on the same network. For example, one system could receive an address automatically, while another computer logs on using a static address specified by a user. When such conflicts occur, network slowdowns result (and the systems sharing the same address frequently experience outages).

Troubleshoot IP address conflicts by ensuring you don't have a rogue DHCP server on the network. Confirm, too, that configured DHCP scopes don't contain overlapping or duplicate entries and that any systems (such as servers and routers) that have been assigned static IP addresses have been excluded from the DHCP pools.

#6: Excessive network-based applications

Occasionally, networks are overrun by the applications they power. For example, a physician's office that uses a Web-based patient and practice application will commonly have every workstation logged on to the program during business hours. Retrieving data from the patient database and consistent monitoring of appointment and scheduling information alone can place stress on even a well-architected network.

Add in the fact that each workstation is likely tuned to e-mail (and many offices are turning to VoIP) and it's easy to see how introducing a few streaming audio/video files to the mix (either in the form of online music services, news videos, or instructional medical presentations and Webinars) can unacceptably slow a 10/100 Mbps network's performance.

Implement policies--and if necessary, hardware-based Web filtering tools--to prevent applications from overwhelming available network bandwidth. Make sure employees understand they're not to stream unnecessary audio and video files. Further, when working with VoIP, be sure adequate data pipes are in place to manage both voice and data traffic.

#7: Spyware infestation

Spyware, the scourge of the last few years, finally appears to be meeting its match in business environments. The development of potent anti-spyware tools, combined with effective end user policies, is reducing the impact of spyware in many organizations. Windows Vista includes Defender, a decent anti-spyware application powered by the popular Giant engine.

However, infestations still occur, particularly on older systems that haven't been properly safeguarded. Implement strong user policies and either gateway-based protection or individual client applications to prevent spyware programs from consuming precious network bandwidth.

#8: Virus infestation

Just as spyware is proving containable within business environments, so too are viruses. That said, despite an administrator's best efforts--including firewall deployment, routine and consistent Windows patching, and the use of regularly updated antivirus programs--viruses do get through. The result can bring a network to a standstill.

For example, many viruses place Trojan programs on Windows systems, where they can wreak havoc. In addition to leveraging a system's ability to send e-mail to forward hundreds (if not thousands) of spam messages an hour, viruses can corrupt network configuration.

Defend against virus threats to network performance by ensuring firewalls, Windows updates, and antivirus programs are properly configured and maintained.

#9: Insufficient bandwidth

Sometimes, a network just doesn't have the throughput it requires. As with # 6--excessive network-based applications--some environments demand more bandwidth than others.

When a network does bog down, several options typically exist for increasing capacity. Besides boosting up- and downstream speeds, some offices may require additional dedicated connections. From multiple T1s to DS3s to even optical carrier-grade connectivity, many potential solutions exist.

Further, some organizations may need to upgrade existing 10/100 Mbps networks to gigabit speeds. By upgrading NICs, cabling, and devices to 10/100/1000 Mbps equipment--and replacing any remaining hubs with switches--many firms can realize significant capacity gains. In other cases, it may be necessary to subnet networks to localize particularly intense traffic to specific network segments.

#10: DNS errors

DNS configuration errors can lead to numerous network failures and generalized slow performance. When no DNS server is available on a local LAN, local systems may have trouble finding one another or accessing local resources because they'll have trouble finding service locator records that assist Windows systems in communicating with Active Directory. Worse, systems with no local DNS server or those workstations having DNS servers several hops away may experience delays or flat outages in accessing Web sites and extranets.

Try placing DNS servers as close to network systems as possible. Although adding DNS services to existing servers places greater demand on those boxes, properly configured machines can remain secure and noticeably enhance response times to external resources.

Also, always check to ensure systems are configured to use the proper DNS servers. Network architectures change over time, yet older workstations (particularly those set to use static addressing) occasionally are forgotten and continue operating using outdated DNS settings. As your organization and ISP update DNS systems, be sure workstations and other routing equipment actually receive the updates.


Slow network is a common phenomenon. Slow network speed can be caused by a number of things. to troubleshoot slow network is one of the most common and troublesome work in daily network management.

According to analysis, major reasons for slow network are:

  1. Loopback
  2. Broadcast/Multicast storm
  3. Virus attack
  4. Server slow response
  5. Too many clients
  6. Application slow response
  7. Error client mask

I recommend the following article. I think they can help us to find reason:

1. How to Diagnose Slow Server Response, please visit

2. How to Diagnose Switching Loop,  please visit

3.How to Diagnose DNS Erro,  please visit

4.How to Detect Sasser Worm, please visit


I kid you not. Friend of mine was the IT guy for a polytechnic in the early 90's and found that two PCs wouldn't run at the same time. Turned out that the Taiwanese NIC maker had been creating duplicate MACs and the training institute was unlucky enough to end up with two of these cards on their LAN


Number one slowdown on networks is duplex mismatch. This is not even mentioned. If you are talking small networks,adding(cascading)switches causes very little, if any propgation delay. So I don't quite get that one. Screwing up a subnet mask is also another gotcha. Cheap switches can also cause issues if they can'y auto negotiate correctly. DNS servers? What is this,a windows only seminar? Their are other,better methods for nework discovery(SLP being one). Netbios broadcasts and WINS suck,but if you are running M$ based garbage,you get what you deserve. Top 10,maybe a couple of obvious ones,but there are loads of others depending upon the size of the network.


I have found that it is pretty straight-forward to identify any of the 10 items listed as the culprit when the problem is isolated to just one of the 10 causes. However, when it gets really fun is when it is a combination of more than 1 of the ten and some moron is trying to figure it out. I recently had a twist on 1, 2, and 3 where the client used a big name firm from the other side of the state to install $25 daisy-chained switches throughout their production work area onto a combined Win-Linux network. The customer's cue-to-call in for help was it was taking 15 minutes for color print jobs to reach the printer's output tray. The customer had their big-firm, non certificated specialists come in-2 hours of drive time each way-in tandem because one "specialist" was obviously not enough horsepower to troubleshoot the problem. They came and scratched their heads on Friday and again all day Saturday (weekend rates!) They also hauled the printer's manufacturer technician/specialist at $200/hr, min. 2 hours, in on the weekend to troubleshoot his "broken equipment" only for all to leave without resolution except finger pointing to each other. I happened to be on the site Monday morning when the owner of the business said "you know how to troubleshoot these issues. We have already spent well over a thousand dollars and still no resolution and we still can't print in color!" He asked me to clear my evening schedule because he expected a full network rebuild and wanted me to do it rather than his IT Department's outside firm. I said, why not take a quick look at it now. I went to the daisy chained switch and noted that it had a bank of green lights and one orange one (a Clue!) I traced the orange one to a mis-configured, half duplex PC NIC, reset it, the light turned green and I said "have your people try to print now." The big-named firm sent back a kid (4 more hours of drive time) to confirm that the staff could really print, but when I bumped into him he said "You got lucky pal, but I still think the NIC on the printer is bad and so does everyone in my firm!" That was three weeks ago and the firm from the other side of the state is still blaming the printers manufacturer. The funny thing is everyone can print in color and the problem hasn't resurfaced, but they have a Full Network Rebuild on their to-do list. Although that firm's ego is still preventing them from admitting that they really missed some obvious clues, their lessons should be: Consider the big picture, look for the warning lights-they generally mean something, use quality enterprise hardware, don't assume that it is automatically someone else's fault, and be willing to admit when you are wrong. Oh, and try to have fun in your work.

Andy The IT Bloke
Andy The IT Bloke

It's amazing the amount of places I see that still use hubs. And sometimes the network guy doesn't know the difference between a hub and a switch. Bin those hubs and replace with switches.


Architect is a noun, a person who designs, typically buildings and landscapes. You cannot really architect something. You design something. Perhaps you meant a well designed network? As a Florida registered Architect, I find the improper use of the word architect by many IT types, as strange at best. The IT industry is full of extremely intelligent people and to misuse a word like this is egregious.


Had a situation where a sales group on the "other" side of the corporation brought in an outside vendor with a product solution and installed it without IT oversight. Vendor refused our access to computers after installation and refused installation of virus protection software. Sales force used software, along with the required internet connections, and obtained trojans that slowed network down to a crawl. The problem was made worse by the vendor insisting it was not their systems causing the problem. Demonstrated their error by disabling network access to those computers, and Lo and Behold! the network returned to normal!


I've seen it happen a few times where an office will have both both hard-wired and wireless networks. Someone will turn on or forget to turn off the wireless card on a laptop and it will be connecting to the network via both connections. We don't use wireless so it's not an issue for us but I know of a few IT contacts that have run into this.


How many of these problems have you encountered on your network? Can you add some other performance-killers to the list?

Editor's Picks