Forum

I see what you are saying, but my question is, why send all of that data through the controller/switch anyway? Why not have the intelligence at the AP so that you reduce your overall network traffic and possibly limit some of these bottlenecks?

A guy named Joel Barret convinced me of this back in the day (before Cisco acquired a controller company :)).

P.S. I also read that 802.11n is only going to require about 150 Mbps data rate (~100 Mbps throughput). Any word on that?

I have the 802.11n draft 1.0, but I haven't dug into just yet...will shortly.

About the throughput, check out Colubris's whitepapers. They have one on architecture that I'm sure you'll find interesting. They took the controller out of the data path, but still use it for control and management. very smart - at least until the unified architecture gets here.

Yeah, that is the design that I think works. Proxim does the same thing. They only set up IP tunnels when subnet roaming is needed. With LWAPP and with Aruba's controllers you have data tunneling back to the controller all the time.

Man - this is a way cool thead. Thanks, Devin, for (ex)posing these issues/problems.

I think that the centralized/not-centralized issue is a great discussion starter, so here's my take on it - filtered through my security & managment concerns. In a large enterprise environment, centralized is a better way to go (depending on your specific needs, of course) for the following reasons:

1) Centralized controllers give you a centralized entry to your wired network. this is the place to put RBAC -Role-Based Access Control (read firewalls) for securing the wired network from the wireless network. It's much easier to control a single point of network ingress (the controller) compared to a large number of ingress points (APs).

2) If you decided to control network access via SSID/VLANs on fat APs. you would be extending your (layer 2) VLANs across your wired entire network - meaning across many different (layer 3) subnets - to maintain your security policies. This <IS> a wired switch managment nightmare.

3) Centralized controllers give you tightly coupled centralized management of your APs. Yes, I know that there are many companies that claim to be able to manage fat APs, but they are not nearly as tightly coupled as a centralized controller.

To give you an idea of where I'm coming from, we have hundreds of subnets in hundreds of buildings, with a (layer 3 - IP) routed core network. We have multiple virtual WLANs for various functions - both authenticated and open. To extend layer 2 VLANs supporting thse WLANs across all of those locations would be a herculean task.

OK, I admit it - I'm a centralized controller bigot - but with good real world experience and reasons for this predisposition.

Yes, there are concerns with running all the data through a central point, but there are good redundancy and throughput reasons to limit the number of APs connected to a single controller. If you are building a mission critical network, you definitely don't want a single point of failure, so use multiple controllers.

I'm ready to duck - hit me with your best shot, Joel (and others) :-)

Dude, I'm with ya on this. :-) No stones coming from my direction... hehe.
You administer one of the biggest, most complex WLANs I know of personally. Your input on the forum is most welcomed.

Devinator

Hi Stan,

I understand that you administer a Huge wifi network.
How do you tackle the 100m Cat 5 Limitation between the
Controllers and APS.

Can you explain more on this .


Best Regards,

S.Senthilraj CWNA,,CWAP,CWSP

Stan,

You make a great point. If you want a WLAN overlay, you need a controller. With standalone APs it takes a reconfiguration of the wired LAN to accomplish the same function. Most network admins don't have the time to hassle with something like that.

wirelesswizardCWSP Escribi?3:

I understand that you administer a Huge wifi network.
How do you tackle the 100m Cat 5 Limitation between the
Controllers and APS.

Can you explain more on this .

This is a fundemental feature of WLAN controllers. In most cases, the thin APs create tunnels (GRE, IPSec, etc) from the AP to the controllers. These tunnels are layer 3 (IP) routeable, so your APs don't have to be within 100 meters of the WLAN controller. They can be many subnets away. In effect the thin AP/WLAN controller architecture creates a virtual WLAN overlay network using tunnels. This frees you from creating layer 2 VLANs on all of your Ethernet switches that are connected to your APs.

As an example, we are running APs at our Oxford campus located 40 miles from the main campus. The controller that these APs connect to are located on the main campus (we have GigE fiber between the two locations :-) gotta love that!).

We have had issues where the APs were located more than 100 meters from the nearest existing wiring closet. In those cases, we had to add another closet (ugh!).

The tunneling aspect of a centralized WLAN architecture highlights the potential issues that Devin initially alluded to - namely that the tunneled traffic needs some QoS mechanism on the network to address voice and other real-time traffic originating on the WLAN.


Ben -

You hit the nail on the head. I firmly believe that WLANs should be an overlay/separate network for security purposes. This is especially true when you have multiple costituent bases as we have - authenticated users, guests, VoIP over WLAN, etc. Hence my centralized architecture "bigotry". Clients of WLANs today are just that - clients - not servers. Their individual data bandwidth requirements are that of an end user. While bandwidth requirements are growing, they are still typically managable for running trhough centralized controllers. Just my 2 cents...

wlanstan, might I ask what "vendor" controllers and APs are you at Emory utilizing? Your knowledge and experience in the field is most impressive. Like to understand more of your experiences.

Regards

Since you asked...

We are using Aruba equipment. Currently, we have about 750 active Aruba APs, with another 400-500 scheduled to come on line by the end of May (or sooner if I can get the site surveys and designs completed). We have 14 controllers active with more coming on line as needed to support the additional APs.

Our WLAN network is designed to have no single point of failure - we have redundant controllers, RADIUS servers, etc.

To see our main campus coverage, go to
http://it.emory.edu/unplugged

In addition to a number of academic buildings, we completed lighting up all of our residence halls and frat houses last month. All told, we have over 100 buildings covered (most are partial coverage, but the residence halls are fully covered).

BTW - if you come by Emory, we have free guest access. It is limited to Web, secure Web, and VPN. It is also bandwidth limited to 500kbps - not too shabby for checking (web-based) email and surfing. You want to do more, you'll have to VPN back to your home organization :-).