By Brian Lusk
Does this sound familiar?
Scenario 1: Last year, your pre-IPO dot com started with two guys and a PC. Now, you are adding your 100th employee and spending more time rebooting PCs than providing strategic vision for your upcoming IPO. Your network performance is flaky, saturated, and poor when it works at all.
Scenario 2: Your company has been around for 20 years, originally starting as a family-owned business. You have technology from those same 20 years scattered around your network and (once again) you are spending most of your time trying to keep it running with your 150 people on board.
By now, many of you are saying, “A hundred people? I have 100 people in a single department!” Relax, and read on. If you don’t think my advice can be applied to an enterprise network spanning thousands of users, you can tell me in the discussions forums or by e-mail. I’ll incorporate the best suggestions in a follow-up piece, if enough people respond.
So 100 users or thousands—what should you do? Divide your network. That is, implement technologies that minimize your collision domain and maximize your throughput. Remember that Ethernet is a collision-based technology. One unit talks; the rest listen. When two computers try to talk at the same time, a collision occurs, causing both computers to time out and retransmit after a random time-out period. This problem is most pronounced in companies that still use hubs instead of switches.
Tips for avoiding network traffic jams
Keep departments and data together. How often do you have a computer or workgroup that has to hop through three different hubs or switches to reach frequently needed data? If the answer is more than zero, it’s a problem. Every time one PC or workgroup accesses data, it ties up every switch and hub on that route until it is done. Ideally, a department’s most frequently used data should be located on that same switch or hub as the requesting PC and shouldn’t have to hop to another hub. Since that’s not always possible, hopping up one hub to a centralized server is certainly adequate.
Do workstations on one hub print to a printer on another hub? Again, this should be avoided at all costs. Printer data tends to be long and complex. Sending a 100-page document to the network printer will tie up every hub or switch between the two locations. Anyone who prints regularly should have a printer on the same switch or hub as his or her computer.
The key here is that you want to avoid hopping up the chain of hubs and switches if at all possible. Locally transmitted data arrives faster and avoids collisions on the larger network. In some cases, establishing workgroup or departmental servers may be a logical approach.
Upgrade to newer technologies. Too many companies started out with a hodgepodge of hubs that they stuck together with spit and CAT3 wire. But the same hubs that worked great when you had 10 employees won’t work as the backbone of your 100-plus-employee network.
Switching technology is quite mature these days. Take the time to research and invest in manageable switches from a reputable manufacturer. Although many might say that the management features aren’t worth it, I have saved my own bacon by monitoring and determining the root cause of network problems via those features. Many managed switches will even provide an alerting mechanism that gives you advance or up-to-the-minute notice of problems.
Depending on network traffic, you may also consider the venerable bridge technologies available. One bridge can divide your network into two smaller collision domains and reduce traffic on the individual segments. I find that switches accomplish the same affect in many smaller networks.
The cabling plant may need some upgrades as well. Current standards call for CAT5, and I would never do a new install with anything less than CAT5e. Plus, with appropriate CAT5 or CAT5e cabling, full-duplex operation, 100-megabit and even gigabit data transmission speeds are within reach. Fiber also makes an excellent backbone between switches in an enterprise environment.
Subnet your network. If you’re working on a very large network, subnetting may be the best idea for you. Combined with switches to limit your hardware collision domain, subnetting can really shine. Switches are powerless to prevent an IP broadcast from spreading and tying up the entire network until it has finished, but subnetting can fill in the gap.
For those who aren’t familiar with subnetting, it’s basically the process of making a smaller set of logical IP networks out of a larger IP network. This means that a broadcast sent to the entire network will really only propagate to the members of the subnet instead of out to the entire network.
In my previous article, I promised to tell you how my Linux upgrades went. The upgrades went so smoothly, I am hesitant to publish comments about it for fear of jinxing it. However, I’m not that superstitious, so here you go. After replacing the motherboard, processor, and RAM, I experienced no trouble at all. My copy of Linux booted up, recognized the extra RAM, and started using the extra hardware with no additional interference from me. My Linux box is no longer the slowest server on the network and has the horsepower it needs to get the job done.
What technologies have turned your network around? Do you think my suggestions need to go back to the drawing board? Start a discussion below or send the editor an e-mail.