Troubleshooting Slow Network Conditions (Part 1) – The First Steps

I received an email from a remote user the other day. All it said was “The network is slow.”

Sigh.

When compared with other phrases I don’t want to hear on a Monday morning this ranks just after “Was that your car I crashed into?”.

I’m probably exaggerating a little. Sometimes dealing with these issues isn’t so bad; especially when a quick look at the picture reveals an obvious solution. The problem is that all too often these network slow incidents are some combination of unrealistic expectations, misplaced blame, and/or subtle technical flaws.

Unrealistic expectations you ask? I see it all time.  Everywhere I go, I often find myself tempering my clients expectations of how fast their network should be. A remote office connection can be working up to par and still be perceived as being “slow” by some users. I blame the cable companies , since the majority of my clients’ employees have some type of broadband access at home.  When these people are working away in their offices most of them are sharing a network connection that is at best equivalent to what they have at home. Prior to the past couple of years, people could generally count on their work connections to be faster then what they have at home, and that is not always going to be the case nowadays. I’m always trying to give my users a realistic notion of what their experience should be like given their particular network design.

Misplaced blame? Constantly! Why do people always first assume it’s the network is slow? Nobody every calls up the server guys complaining about a slow server without going through us first. Same thing with our app or desktop support teams. If something isn’t up to speed, it’s the network’s fault until we prove otherwise.

Back to the matter at hand. So we have a potential slowness problem. The first thing I find myself doing is just to fire off some simple pings to see if anything obvious is happening. I’m looking to verify my own connectivity to source and destination of the reported slowness. I’m also want to see want the latency looks like and if any packets are being dropped.

Assuming I see nothing obvious, the questions must start. I want to determine the scope of the problem (how many people/sites are effected) and get some idea of what the actual cause of the slowness is (be it application/fileserver/or network related) I’ll get a hold of the person suffering, and start the interrogation. What applications are slow? How fast can you pull up a website? What about pulling a file off a server (which is usually a remote server in my world). Are other people around you experiencing the same things you are? When did this start? Has this happened before?

While I’m giving the 5th-degree to my contact, I’m usually accessing utilization reports on the links in question. I want to see what utilization/latency/error levels the site is seeing now and over the past few days. Maybe I’ll see an oversubscribed circuit. Maybe there will be a ton of errors suggesting a dirty connection. You do have network monitoring software, right?

If I determine the slowness issue seems isolated to a certain application or host, I’ll start to pull in the other support teams. I still will examine my infrastructure around whatever app/server is bogging down, but I know most of the time in a case like this it’s not going to be an issue with anything that is directly network-related.

If the complaint does seem to be a network issue, it’s time to roll my sleeves up and start digging. More on this later.

Jason

Tagged as: Routing, troubleshooting telecommunications