Lots of Bandwidth but Data is bogged down...

[NcCorduan]

Hello,

I asked this in the leased line forum, but I wanted to ask it here, too, to get at another vantage point...

I work for a university with two campuses on a backbone of Cisco switches and routers. Between campuses we have two leased T1's, each with about 960K available bandwidth for data. The traffic across the WAN is *incredibly* slow, even though our use of the bandwidth never exceeds 390K on one T1 and only spikes above 480K on the other one during the dead of the night.

I'm on the software / server / PC side of things. The network infrastructure guy I work with (who's on the other campus, so isn't affected by the slow WAN)insists that the very fact that we're not using our max bandwidth means that the slowness is not an issue with the T1's or the Cisco routers.

To my way of thinking, this seems backwards. If our data transmission is so bogged down that our WAN performance is slow, then more of the bandwidth *should* be used.

Is there something you know of which could be damping out data transmission or preventing us from making use of the entire bandwidth?

Thanks!!

 

[wybnormal]

This is one of the most misunderstoon issue of a network. More traffic means high load means slow? right? wrong!!!

For example, if you have a smallish router and a ton of dinky packets of..say 64Bytes to 256Bytes, that router is going to be buried from a CPU perspective and the network will be "slow" even though the pipe itself is only running at 40%. Flight of fancy??? think again, I just described a Citrix server farm on a LAN/WAN that was not designed for this type of application.

Slowness can be from excessively large packets, excessively small packets, excessive broadcast packets, TCP Sliding window problems and a host of other fun things. None of which deal with the size of pipe. Not to say that the pipe will not contribute to network slowness, it certainly can.

Someone needs to spend some type building up some baselines and some sniff traces( or equivelent) to see just what really is happening on the wire.

MikeS Find me at

http://www.packetattack.com

"Diplomacy; the art of saying 'nice doggie' till you can find a rock" Wynn Catlin

 

[marsd]

What kind of queueing are you using?
Traffic priority and a decent qeueing scheme can solve a lot of slowness problems.

of course:
As the above post mentioned the causes are myriad, you need to diagnose the problem.

 

[heymex]

I'm going to plug my favorite WAN analyzer here... it's ungodly expensive, but worth every penny: Emcom Net/QC. Plug one of these probes into your T1 interfaces, F/R, whatever and you will get *the* most detailed and accurate real time and historical reporting you could imagine. You most certainly will find the cause of your problem if you use something like this. At my last employer we saved an average of about $2-5k/mo. just on being able to report back to MCI when our frame circuits were actually down, not to mention the fact that we saved oodles of money being able to do real traffic engineering on the WAN links because we knew exactly what was happening at all times down to 1 sec. granularity.

http://www.emcom.com

And no, I don't work for them

 

[jeter]

the easy way to test is to remove the network from your side off the router and install directly to the ethernet via a cross-over cable. test your speeds there. If all is ok put your lan back on an start sniffing out the problem.
Like Mike mention is caused by packets. Do a show process cpu and check out the stats. Good Luck! Jeter@LasVegas.com
J.Fisher CCNA