This post is going to stray a bit from my usual geeky fare. I’m being asking far too much to help sort out haphazard home network designs that are causing real problems for their users. I decided to collect all the answers that I’ve given together in a single place that I can point to when asked.
Simplicity
Rule #1 in any network design is simplicity. Most of the instructions here are built on this rule. At it’s simplest: if you don’t need a device, take it out. If a device does more things than you’re using it for, replace it with something that does less or turn those functions off.
You get what you pay for
A Cisco Aironet is going to crash less than a Linksys access point. A Cisco switch is going to provide better throughput than a NetGear one. This isn’t a hard-and-fast rule; there are certainly decent, cheap network devices out there. However, generally, if a device has a plastic case and an external power supply and you’ve got more than 3 people depending on it, you’re going to regret the decision.
Make sure that you only have one DHCP server on your network. More than one will likely cause some machines to get incorrect IP addresses and be unable to go anywhere. Testing for this is a little difficult. First, burn an Ubuntu CD. Reboot with the new CD in your drive, and your system should boot into the Ubuntu environment. Open a terminal window (Applications -> Accessories -> Terminal) and type:
sudo ifdown eth0
sudo dhclient eth0
You should see one or more lines starting with DHCPOFFER and telling you where the offer came from. If you see more than one source of offers, you need to eliminate extra DHCP servers.
By far the most common network issue seems to be nebulous “slowness”. We’ll try to eliminate possibilities one by one.
You’ll need the exact hostname of the service you’re trying to access. For example, if it’s slow when you try to visit http://firestuff.org/ in a web browser, then firestuff.org is the hostname. Pull out your Ubuntu CD again, and in a terminal, type:
host firestuff.org
(obviously, replace firestuff.org with the hostname you’re concerned with)
This converts firestuff.org into an IP address using DNS. It should take less than a second to complete. If it takes much longer, either your ISP’s DNS servers or those that provide the firestuff.org data may have problems. To narrow it down, try:
host www.google.com
If that returns instantly, then it’s the firestuff.org DNS servers that have problems; contact the administrator there. If the Google test also takes a long time, your ISP has a DNS server problem, or you have the wrong DNS servers configured in your DHCP server. Type:
cat /etc/resolv.conf
then call your ISP and read it to them. If the numbers aren’t what your ISP says they should be, reconfigure your DHCP server. If they are, ask what the holdup is.
Open your Ubuntu terminal and run:
mtr firestuff.org
You’ll want to make the window a bit bigger. This application gives you real time timing data following the route from your network to firestuff.org. Watch the average times and loss percentages. Nothing above 0% is really acceptable loss; your ISP will probably claim that it is, but they’re lying. Remember that the numbers are cumulative; if hop 3 is dropping packets, those drops will effect hop 3 and everything beyond it. However, it’s really hop 3’s problem, and if hop 6 has a problem, it’ll be hard to see until you get the closer issue cleared up.
Do you have long-running connections (SSH, telnet, MySQL, etc.) that get disconnected when they’re not doing anything? It’s your NAT device’s fault. Period. If it doesn’t have a setting to change the maximum idle time for a connection, throw it out and buy one that does.
I’m rather hoping that the geek readers will contribute a few of the complaints that they regularly hear from family members et al and their solutions below.