Troubleshooting a slow network...

hbk

Hi all,

So my question is, if users are complaining about the network being slow, what are some common troubleshooting steps? I've always based my troubleshooting on the going up the layer of the OSI model, but what are some pin-point advice you guys have?
Reason it's in this section is because I've heard this question being asked in interviews and wanted to know how to answer to this.
Thanks

HBK

lsud00d

First off I would have the users elaborate...what does "the network is slow" mean? Are certain web pages loading slow? Is Youtube buffering? Is Exchange timing out? Are they getting disconnected from RDP sessions?

Also I would see if you could isolate the issue. Is everyone experiencing this "slowness", or is it sporadic/random and users are hopping on the sky-is-falling train?

I think there are more questions to answer to determine what is going on before trying to troubleshoot.

hbk

lsud00d wrote: »

Also I would see if you could isolate the issue. Is everyone experiencing this "slowness", or is it sporadic/random and users are hopping on the sky-is-falling train?

Yea it would be logical to isolate the issue to see where the slowness is coming from and troubleshooting from there.
Say the link was congested with traffic or something like that, any idea on common fixes?

bishun

I dont' think the IT Jobs / Degrees is right forum for this.

If the "link" was congested with traffic, then you know where the slowness is coming from. Is this mysterious link an Ethernet span, WAN connection, something else? If it's the WAN, perhaps you're under-provisioned, if its a small LAN, check for a loop.

There is no quick answer to determining whats causing slow traffic. There's information gathering that has to be done before you start making guesses; the size and complexity of the network will determine how much info you really need to gather, and where to start.

Cherper

I don't deal with end users a whole lot, mainly LAN techs and admins, but here are the questions we always ask them in order to troubleshoot network slowness.

• When did this issue start? Day, Time.
• Is it constant or intermittent? How often if intermittent?
• Are you the only one affected? If no, how widespread?
• Is there a specific application or is all network traffic affected?
• What troubleshooting steps have you done to determine the cause of the issue? Have them forward results if possible.
• Is there network documentation maintained by the caller or agency. Request that documentation. Involve their IT staff, if applicable.
• What is the IP address of a device located at the facility affected that we can attempt connection to for testing? Must be turned on.

dbrink

Along with what everyone else has said, one tool you could try is PsPing which is a Microsoft SysInternals tool that can do some network performance testing.

Node Man

Cherper wrote: »

• When did this issue start? Day, Time.
• Is it constant or intermittent? How often if intermittent?
• Are you the only one affected? If no, how widespread?
• Is there a specific application or is all network traffic affected?
• What troubleshooting steps have you done to determine the cause of the issue? Have them forward results if possible.
• Is there network documentation maintained by the caller or agency. Request that documentation. Involve their IT staff, if applicable.
• What is the IP address of a device located at the facility affected that we can attempt connection to for testing? Must be turned on.

Great list!

Roguetadhg

When someone puts in a ticket that includes vague information, it's always better to ask for clarification than to assume something... For example:

"Network has problems"
"Computer doesn't work"
"Application isn't working"
"I can't log in"

Things like these are red flags to ask for more information. Cherper has a fairly complete list of questions you should first ask when finding a problem. Apply the thought process for a lot of problems and you'll find things go smoother.

Who?
What?
When?
Where?
How?

You've gotta be part detective, and part techie to troubleshoot problems. For myself, I hear a lot of users "Complain" about problems but I am forbidden to work on problems without tickets. And I have explained this several times.

In all fairness, When I hear people complain to me - I listen. When I walk away I don't remember the conversation. I have a lot going on through my mind... The way I see it most people will do everything but place a ticket. People will walk around the building, call my phone, call my cellphone (When I had it) all in the attempt to talk to me THEN email me. Whereas they could've spent the 30 minutes of trying and used 10 minutes to type in a ticket. If they're willing to do that much work to avoid a ticket, their problem isn't my problem. I work on tickets, not on a person's whimsy.

hbk

bishun wrote: »

I dont' think the IT Jobs / Degrees is right forum for this.

If the "link" was congested with traffic, then you know where the slowness is coming from. Is this mysterious link an Ethernet span, WAN connection, something else? If it's the WAN, perhaps you're under-provisioned, if its a small LAN, check for a loop.

There is no quick answer to determining whats causing slow traffic. There's information gathering that has to be done before you start making guesses; the size and complexity of the network will determine how much info you really need to gather, and where to start.

There is no quick fixes, but I just want to get an insight on how and where to start troubleshooting. Don't get me wrong, a slow network can be accredited to many different reasons.
And it's in this section because of interview reasonings, I just edited.

hbk

Cherper wrote: »

I don't deal with end users a whole lot, mainly LAN techs and admins, but here are the questions we always ask them in order to troubleshoot network slowness.

• When did this issue start? Day, Time.
• Is it constant or intermittent? How often if intermittent?
• Are you the only one affected? If no, how widespread?
• Is there a specific application or is all network traffic affected?
• What troubleshooting steps have you done to determine the cause of the issue? Have them forward results if possible.
• Is there network documentation maintained by the caller or agency. Request that documentation. Involve their IT staff, if applicable.
• What is the IP address of a device located at the facility affected that we can attempt connection to for testing? Must be turned on.

Definitely a good practice to investigate a little and try to figuring out whether it's a workstation problem or an actual network problem. Thanks for the input.