[BBLISA] slow wan link

[Rob Taylor]

Hi Daniel.

When you say WAN link,  are you referring to a network link between two 
offices at your company, or do you mean your Internet connection?
Also, what speed is this link? When you say WAN, I think T1, T3, etc...
Can you monitor your gear with SNMP or command line to see what 
performance stats on the gear are? Can you throw in a linux box running 
ntop to see the traffic coming and going? Can you do ttcp test just 
over the link itself?

Some network gear can queue smaller "interactive" packets ahead of 
larger bulk transfer packets, to give better response to some 
applications in heavily loaded situations.

Most of the following suggestions are ways to reduce load/optimize the 
use  on the link.

X-windows is not the most network lite protocol out there. I've seen it 
work well on a lan, but very poorly over a slow/high latency link.
If you can, have the users try using VNC, or freenx. Both create a 
virtual X desktop on the target machine, and just shows you a mirror of 
it on your desktop which you can disconnect from and reconnect to at 
will. (They are the gui equivalents of screen or tmux)
The benefit of that is that instead of getting X updates,  your client 
gets smaller raster updates(like rdp), which works better over slow 
links.
VNC is not encrypted by default, so keep that in mind if it's going to 
go over an untrusted link.

For web traffic, you could setup a squid proxy on a spare machine on 
the lan side of the link. This can share common web traffic among 
clients.

Year ago when I worked at a company that only had a T1, we did this and 
it worked quite well. We had to configure the client machines to use 
the proxy, (but there are automated ways to do that now and you can do 
it transparently). At the time, windows updates worked really with 
squid, as the first client primed the squid cache with the files, and 
all the other clients got them at lan speeds.

If you control both sides of the WAN link, (it's not just a pipe to the 
internet)
You could possibly look at link compression, depending on the equipment 
and the speed of the link. I did it years ago over a t1, and it was ok. 
Got maybe 2:1 compression.

You can also look at some WAN accelerators, from companies like 
riverbed.
They optimize chatty protocols, perform caching, and compress the 
traffic to get more out of the link for you. Not cheap though.

If you have a windows server 2008R2, you can look at using BranchCache,
which does some of the same things.

http://www.microsoft.com/en-us/server-cloud/windows-server/branchcache.aspx

You might also be able to tweak some setting on your WAN gear to 
prioritize the traffic that you consider important, or at least ensure 
fairness.

If your wan gear can't do that, then you can also at traffic shaping 
gear, which can optimize/prioritize the flow of traffic over the link.
On a network mailing list that I am on, people have mentioned liking 
Netequalizer, which is a inexpensive transparent traffic shaper.
It tries to make sure that people don't hog the link by default.

Let me know what you discover.

rgt



On Wed 06 Jun 2012 07:43:56 PM EDT, Daniel Feenberg wrote:
>
> We have maxed out our WAN link, and users are complaining of slow access
> to websites and x-windows interaction. Yet when I ping sites on the
> internet I see no lost packets, and ping times for relatively close hosts
> are consistently 20 - 30 milliseconds. Large packets are about the same.
> Ping times to our ISP's router at their POP are 2-4 milliseconds. I see no
> dropped pings to real hosts. Sometimes the ISP router drops a ping but I
> understand that may be due to ICMP limiting.
>
> I have difficulty reconciling these facts. If pings are fast and packets
> are not dropped, why do users see problems? I can confirm things seem
> slow. Is this the dreaded "buffer bloat" problem so recently hyped? Is
> there anything I can do here to aleviate it while waiting for more
> bandwidth?
>
> Thanks
> Daniel Feenberg
> NBER
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa