Router / Switch Performance

control

To those working in the field - If there are complaints of a "slow network" from users how do troubleshoot this and what sort of testing/checking should be done?
How do you check if a router is under strain / low on resources?

DANMOH009

DEBUG ALL!!!

(by the way im joking dont do that)

What sort of issue is it? WAN connectivity or LAN? Is this a production network or one you are just practicing on? I'd personally start by eliminating certain aspects from the connection first (potential saturation issues),

the guys and girls will correct me if im wrong, but if its a production network and its struggling already running just random debug commands will slow it dont a thousand times more.

control

I guess a bit of both, WAN and LAN. It's just to get a general idea on the first port of call for reported issues. If running DEBUG on the routers, what exactly would you recommend I should debug? Not to clued up on the way to troubleshoot these sort of issues.

iamme4eva

Not an answer from experience, just a thought, but you could check show interface commands on the suspected interfaces and check the output / input queues to get an idea of how saturated they are - you also get the 5 minute input / output rates there.

Node Man

Is it an end user complaining about a slow network? If so, i suggest having them running a speedtest, and use the email option to email you the results:

Speedtest.net - The Global Broadband Speed Test

MrXpert

I agree with DANMOH009, debugs could be a bad thing especially doing work hours. if you're going to run debugs should be done at mutually convenient periods and you may have to let people know. If the connection is already slow then it will get even slower with debugs.
I'd look at finding out what users are affected, when etc. In some companies certain trends can develop such as slowdowns during end of month account periods. If you have reporting tools such as snmp or ip sla these maybe useful in monitoring performance?

networker050184

Debugs wouldn't be a starting point for a slow network IMO.

Start with figuring out the path the traffic is taking. Get your source and destination. Show ip routes, look at mac address tables and find the explicit links the traffic is taking.

Next start looking for problems with these links and devices. Show interfaces, look for errors, high utilization, duplex mismatch etc. Show proc cpu to look at usage.

All of this is hopefully also reporting to some type of SNMP monitoring system where you can look at historical data.

control

Great, thanks a lot, it's always good to know how others look at things and the steps they make take.

spd3432

We had a problem with some small sites several years ago (1 T1 in / 1 T1 out). Users complaining about slow network. Looked at the queues then looked at where the connections were going to. Amazing how many people were streaming radio into their cubicles.

kweevuss

spd3432 wrote: »

We had a problem with some small sites several years ago (1 T1 in / 1 T1 out). Users complaining about slow network. Looked at the queues then looked at where the connections were going to. Amazing how many people were streaming radio into their cubicles.

I agree! I work a school district I graduated from as a junior helpdesk, and most of the time it isn't super slow, we have about 50Mb/s up and down, but all the teachers recently got ipads all I ever see is streaming from Pandora.

MAC_Addy

networker050184 wrote: »

Debugs wouldn't be a starting point for a slow network IMO.

Start with figuring out the path the traffic is taking. Get your source and destination. Show ip routes, look at mac address tables and find the explicit links the traffic is taking.

Next start looking for problems with these links and devices. Show interfaces, look for errors, high utilization, duplex mismatch etc. Show proc cpu to look at usage.

All of this is hopefully also reporting to some type of SNMP monitoring system where you can look at historical data.

Networker! (I'm currently frowning at you). You always beat me to it. To the OP, this is the best bet on your troubleshooting practice for your network.