Cisco Aironet 1200 Series - optimization question

I have a pair of Aironet 1231G units I purchased to do a bridge between 2 buildings, & we're experiencing serious network degradation first thing in the morning. I realize that the start of the workday will be a bit laggy due to all the PCs on the network logging on & requesting service, but I have a set of Nortel Baystack switches that are 10/100/1000 in my main location providing the backbone, so that shouldn't be an issue. Both domain controllers have Gig network cards (Intel Pro), so the ability for PCs to synchronize files to their home folders shouldn't be so hampered that it takes users 15 minutes to log in.

In any event, I'd like to know (as somewhat of a WiFi newbie) what I can do to possibly optimize these 2 units so they either ignore traffic not destined for devices on the other side of the wireless (at the remote location), or just to fine tune them so they aren't letting all the broadcast traffic through. The PCs on the remote side communicate w/ 4 servers & a couple printers on the other side (main office location), & occasionally we have users at the main site who will send jobs to a network printer or two on the wireless side, as well as myself using VNC to support users there, & our patch manager pushing updates out as scheduled (usually during evening downtime). Any help would be greatly appreciated.

Reply to
jdieckmann
Loading thread data ...

snipped-for-privacy@valleycountyhospital.org hath wroth:

Yep. That's typical. I have a wireless link to the servers from a remote office. Everything comes on at once, looks furiously for Windoze and anti-virus updates, and cloggs the network for about 15-30 minutes. No way around it except to install SMS server with locally stored updates.

It's way more traffic than that. My own desktop starts up with:

  1. Windoze Update.
  2. Anti-spyware update
  3. Anti-virus update
  4. Quicktime update.
  5. Google Pack update (which includes Firefox, Acrobat, Thunderbird, and Google apps updates)
  6. NTP time sync
  7. Office Active Sync to office server.
  8. RDIST project directory synchronization.
  9. Whatever else I forgot.

I suggest you do some traffic monitoring with Ethereal/WireShark and see what's actually moving on the wireless link. I think you might be suprised. I was accidentally replicating an ever growing monster log file between my office for no obvious reason. Since both sides added records to the file, it was contantly going back and forth.

I think you'll be suprised if you sniff your traffic. I've found Bittorrent servers running on corporate LAN's and users watching videos fed from their homes.

Ok, so the symptom is that the system appears to be so congested that it takes users 15 minutes to log on? Is that correct? Any other symptoms?

My measurements of broadcast traffic on a typical Microsloth LAN is that it accounts for no more than about 8% of the peak bandwidth. In most cases, it's much less. Broadcast traffic is not your problem if you have adequate wireless bandwidth.

That's all very light traffic. The print jobs might be huge if infested with graphics. What's missing are the monster file transfers and database updates.

What's also missing from your description are any useful numbers. For example, at what wireless speed are you connecting betweeen offices? In general, your thruput should be about half your connection speed. Therefore, for a 54Mbit/sec connection, you should get about

25Mbits/sec thruput minus anywhere from 5-20% loss for encryption and VPN.

Have you measured the wireless thruput? If not, use IPerf:

for benchmarking between both ends. Try to do it without any traffic on the wireless. Also do it through your maze of switches and spagetti to make sure they aren't part of the problem. I have an IPerf daemon (service) running on some of my Unix/Linux boxes specifically for performance testing.

The Cisco 1231G has SNMP built in. That will allow you to deploy proper traffic monitoring. For starters, I suggest you configure the access points for SNMP, and run MRTG on a monitoring station or server. You'll get traffic graphs in both directions.

What you're looking for are traffic patterns, any peaks (such as someone running a backup over the wireless), saturation, and possibly indications of interference. You can tell quite a bit from traffic history. In addition, you can also add graphs for the switches and routers if they are "managed" devices (support SNMP).

If you want something fancier, try RRDTool:

Once you have SNMP running on the radios, you can also use it for troubleshooting and error reporting. For this, you'll need the various Cisco MIB files:

and a MIB browser: (not the best but what I use) to look at the numbers from the wireless bridges. You can also see some of these numbers from the IOS or web based configuration interface. Any imparements to traffic will show up as retransmissions, lost packets, packet corruption, or loss in thruput.

Once you have some history, a collection of performance statistics, and some clue as to what traffic is actually moving on your WLAN, then we can talk about optimizing your network.

Reply to
Jeff Liebermann

Wow, thanks for the detailed reply. Unfortunately, my knowledge of TCP/IP is still a bit limited, so when I try to interpret Ethereal logs, my head starts to hurt because I have a hard time figuring out what I'm looking at. I've also only briefly played with SNMP, though I'd be willing to give it a go if it will help me figure out what is causing the link to be so slow.

Reply to
jdieckmann

snipped-for-privacy@valleycountyhospital.org hath wroth:

The most important test is finding out what type of traffic is moving on the wireless. Install a HUB (not a switch) at one end of the wireless bridge. Sniff with WireShark. You can get a fair idea of the type of traffic from the IP socket numbers. 80 is http, 21 is ftp, 443 is MS Netoworking, outgoing email is 25, incoming email is

110, etc. You should be able to get a picture of what ports are being used and how many bytes are moving. If WireShark is too daunting, try one of these network monitoring tools:

Maybe start with Ntop (for Linux):

There's a Windoze port somewhere out there.

Also, do the IPerf speed test. That will tell you if your wireless is operating normally.

My guess(tm) is that you have a bandwidth bottleneck at the wireless, compounded by excessive and uncontrolled traffic over the wireless link. You're NOT going to get gigabit ethernet performance from a wireless link that will go perhaps 25Mbits/sec (in one direction at a time) maximum.

Good luck and either learn quickly or get some experienced help.

Reply to
Jeff Liebermann

Thank you for all the advice - I'm going to try to use some of these tools to get up to speed.

The most troublesome part is that it seems like performance has only improved marginally since we replaced our old Proxim AP's (10MB/s half- duplex units purchased in 2002). I realize that the jump from 10 to

54 (w/ realistic throughput of 25 as you said) is not astr> snipped-for-privacy@valleycountyhospital.org hath wroth:
Reply to
jdieckmann

The older Proxim bridges were probably 802.11b which run at

11Mbits/sec maximum. The thruput is perhaps 6Mbits/sec with such an arrangement. See chart at:

for what to expect.

There are a few things that can be done to improve the speed. However, my guess is that the traffic content is probably more important. It really only takes one clueless user to run or setup some manner of bandwidth wasteing application, to bring the wireless bridge to a crawl. If the MRTG traffic graphs show that the wireless link is saturated, then optimizing the wireless isn't going to do much.

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.