Here are the 4 wireless controller/management architectures you NEED to know, and an overview of what vendor solutions fall where.
In the past several months, as we’ve been working on a variety of NAC implementations, I’ve had the grueling task of explaining to customers that their wireless system wasn’t quite what they expected. Instead of the super-easy management they anticipated, their choice in solution resulted in quite a bit of additional overhead, manual configuration on the wired side and in many cases, severe limitations.
With several new wireless solutions popping up in the last 18 months or so, there’s been an added layer of confusion piled on to an already mind-boggling suite of wireless systems. In the past, we had the simple categorization of autonomous AP systems and light AP or controller-based systems. Now, the controller-based category has sprouted branches of its own, and the myriad options are confusing the heck out of even the most technical buyers. Here, I’ve outlined the 4 types of wireless controller systems that can be used to describe all types of products in the marketplace.
With each of the 4 types, you’ll find a brief technical background explaining what’s going on under the hood, as well as some pros and cons to consider when selecting a wireless technology for your environment. I’ve even thrown in graphics to illustrate the functions. I can’t say there’s one single option that’s best, but you’ll see there are some that offer much more flexibility than others, although that may come at a cost and complexity not well-suited for some organizations.
As always, I’ll leave it to you to decide what’s best for your organization, but if you specifically selected one type of solution over the others, I’d love your feedback.
1. Autonomous AP Architecture (no controller)
Full heavy APs, no central management design
We’ll start with the wireless system that is the oldest and easiest to explain – the autonomous AP system. Frequently referred to as heavy APs, autonomous APs are stand-alone access points with full intelligence integrated. You can have one, you can have many, and they’re all managed individually. In this system type, you can think of an autonomous AP as you would a switch.
If you want to add VLANs to support SSIDs, configure routing or set policies, it’s all done on the AP through its web GUI or CLI management. Each AP has an IP address for management, and each AP drops traffic on the switch it’s directly connected to. Because of this, routing and ACLs to control the traffic must be handled on a switch or firewall acting as the default gateway for each of the wireless networks.
Pros: If you just need a single or a couple of APs, an autonomous system will almost undoubtedly be the least expensive and fastest to procure. If you’re accustomed to using and configuring heavy APs, then this technology offers a small learning curve.
Cons: If you have more than just a couple of APs, managing them all individually can be a nightmare. Updating wireless network SSIDs, upgrading firmware, managing management security and certificates, authentication details and pre-shared keys all have to be configured on each device individually and often results in mis-configurations, mis-matched configurations and frequently non-configurations, where someone adds an AP and just drops the traffic right on the wired production network. With this system, management is difficult, which leads to security vulnerabilities. In 99% of organizations I’ve seen still using heavy APs, at least 1 AP (and usually many more) has been forgotten or not secured.
Examples: Apple Airports, Cisco Aironet standalone APs, HP MSM (legacy Colubris) in autonomous mode, HP legacy HP AP420 and AP530, (Cisco) Linksys wireless routers
2. Controller-based Management Only
Heavy APs with a central management software or hardware
To ease some of the management woes from the Autonomous AP System above, vendors began offering a Controller-based Management Only solution. Interestingly, this wasn’t the most prominent immediate follower to the Autonomous AP Systems. With these systems, the vendor offers a management system that can be used to centrally monitor and manage what would otherwise be autonomous APs. Think of it as you would any switch management tool, but modified a bit for wireless.
These controllers will help push firmware updates to APs, push security settings, push wireless networks and SSIDs, etc. But, underneath the hood, it’s just a management system modifying the configuration of each individual AP.
Pros: Controller-based Management Only systems offer a low entry price for a much more manageable wireless solution than autonomous APs. Some of these vendors offer the management controller as a virtual appliance and even as a cloud-based hosted service. Wireless-as-a-service and wireless-management-as-a-service is an extremely attractive option for organizations that don’t have the resources in-house to manage a more complex wireless system. Centralized management also makes monitoring and trending of wireless usage more easily accessible.
Cons: Because the AP is still autonomous, it must be configured as such. The cons associated with these systems are usually related to the infrastructure needed to support the wireless, as opposed to management of the wireless itself. In general, the biggest pain comes from the need to extend wireless VLANs through the network and out to the port the AP is attached to. If you want 3 wireless networks on 3 different VLANs, you’ll need to deliver the VLANs to each AP port. If you decide to add a new wireless network in 6 months, you’ll have to repeat the process for that VLAN. If you’re using RADIUS- or NAC-assigned VLANs, you’ll need to bring every possibly-returned VLAN to each AP. On a similar note, if you’re using 802.1X for any wireless authentication, each AP will need to be registered with your RADIUS server as a RADIUS client and configured on both sides with the shared secret. With cloud-based hosted wireless management solutions, changes can be more time-consuming as larger configuration files and firmware have to be pushed from a server on the Internet through a WAN link and to your APs. And, from cloud-based controllers, the success of configuration changes can be spotty, and network admins may have to push settings multiple times for complete success on all APs, and in some systems the updates are pushed linearly, or to only a handful of APs at a time, proving to be quite an impediment during changes.
Examples: Aerohive, Cisco HREAP, Meraki, Xirrus
3. Controller-based with Traffic Tunneling
All wireless traffic is tunneled to a controller, APs have various capabilities
Controller-based with Traffic Tunneling solutions were most prominent immediately following autonomous APs, as the needs for central management emerged and grew rapidly. In these products, all traffic is tunneled back to the controller. The APs are light or semi-light and have little to no intelligence. In many of the original products of this type, the APs are really nothing more than a radio, whereas newer solutions offer more intelligence in the AP in the way of traffic management, monitoring and security features like rogue mitigation and WIDS/WIPS.
With these products, the APs communicate to the controller over a tunnel, which may be encrypted, or may be a simple GRE tunnel. All traffic coming through the AP will be sent over the tunnel to the controller for traffic processing and management. The connection can be layer 2 or a layer 3, depending on the network. Some products offer an auto-provision feature that uses the controller and the switch to automatically put APs in a specific VLAN to ease deployment for layer 2 implementations. Whether layer 2 or 3, once the connection is up between the controller and the AP, all traffic is encapsulated in the AP-Controller tunnel and sent along. At the controller, traffic could be firewalled, routed, filtered or simply dropped on the network. By virtue of the technology (not the method of connection) most novel solutions in this category will also bring advanced RF management and troubleshooting.
Pros: The advantages of a Controller-based with Traffic Tunneling system are varied. In solutions with less-intelligent APs, the cost of the APs or radios is likely to be half the cost of their full-featured cousins. The smarter APs and more advanced controllers come with a higher price tag, but you’ll get many added features for your coin. With all products of this type, deployment is swift and simple. Knowing all traffic is being tunneled back to a controller gives network administrators ease of mind that wireless traffic isn’t benefiting from a rogue route or mis-configuration on the wired side. These solutions may offer encryption from the endpoint to the controller (versus just to the AP), adding some security on the wire. As with the previous type, monitoring and reporting on wireless usage is simplified, and newer products in this category will offer the more advanced RF management and troubleshooting needed in enterprise and campus environments.
Cons: The cons can be as varied as the pros for this wireless system type. The most pervasive issue with a full traffic-tunneled solution is the inflexibility of design implementation. Products in this category must send all traffic back to the controller, and there exists no option to bridge or drop it locally on a switch. In most environments, this may never be an issue. In logically larger environments, environments that are passing large files over wireless and environments that are geographically disperse, this solution may not be well-suited.
Examples: Aruba (except Remote AP), Cisco controllers including WiSM, HP WESM line (legacy)
4. Controller-based with Split Traffic
Wireless traffic can be tunneled to a controller, or bridged locally and dropped on the wire
Wireless products that offer a Controller-based solution with Split Traffic design are by far the most flexible of the 4 types here. In this arrangement, a controller can be configured to either tunnel traffic back to a controller, as in our previous system type – or – it can be set in bridge mode and drop wireless traffic on the switch it’s directly attached to. Most often, this behavior is desired when organizations want to drop authenticated wireless traffic on the wired network, while tunneling guest traffic to the controller and directly out to the Internet. In other scenarios, this configuration might be used to secure specific types of traffic to and from protected resources in the network, since this behavior can allow for encryption all the way to the controller, protecting data on most of the wired network as well as on the RF side.
Let me go one depth further here and tell you that the capabilities of this vary slightly from product to product. Some products can support split traffic on different wireless SSIDs within the AP, whereas other solutions may only be able to support an entire AP in either tunnel or bridge mode. If one method is of significant importance to you, make sure the vendors you’re exploring support your chosen method.
Pros: A solution of this nature is extremely flexible and can be configured to support a variety of enterprise needs. Although I’ve most often seen organizations choose a complete implementation of one or the other (tunneled or split), knowing the option to modify the wireless to meet changing business needs is comforting for network administrators and CFOs alike. As with the previous controller-based class, these solutions usually offer rich tools for monitoring and managing the wireless, both on the RF side and the configuration side, and all offer built-in and add-on tools for advanced troubleshooting and reporting. And also as found previously with traffic tunneling controllers, these products usually offer options to extend encryption all the way to the controller, instead of terminating just at the AP. At least one vendor in this category offers Fourth Generation Wireless technology (a term coined by Gartner), which although not directly related to the categorization here, usually accompanies these more advanced systems.
Cons: Because of the added functionality and more developed management features, you can plan on these solutions being the most steeply-priced of our 4 wireless types. Due to the extensive options available when implementing these technologies, wireless managers that don’t have a solid grasp of both wireless (RF) technology and networking may find the array of menus and check boxes daunting, at best. Misconfigurations are more common in the more complex products. Having said that, the remaining disadvantages are minimal, as this solution addresses concerns raised in all three previous wireless types.
Examples: Aruba (using Remote AP feature), Cisco controllers using Flex mode, HP MSM line (legacy Colubris), HP WX line (legacy 3Com), Juniper WLC line (legacy Trapeze), Meru Networks
I hope this clarifies some of the mystery behind the wireless, and specifically the wireless controller system capabilities. If you think any vendors or products should be added to examples, please let me know, post here, or have a manufacturer SE contact me. Other technologies charted in this year’s Gartner’s Magic Quadrant for Wireless LAN Infrastructure include Bluesocket, Motorola, Juniper (legacy Trapeze), Brocade.
Good luck on your wireless adventures!
# # #
[…] The 4 Wireless Controller Architectures […]
How about for Ruckus and Huawei wifi system? Isn’t these products popular as well? Pls advise.
Hi,
Interesting discussion, and I’m sure it will be for quite some time.
A note on HP MSM, I’ve been running a MSM controller solution for four years as a customer, and I can assure you it can survive a controller failure for those VSC’s that bridge and authenticate at the edge, which I would highly recommend.
In regards to resellers and vendors I’ve dealt with, it can certainly be a mixed result, especially with the sales cycles and hard sell, often you don’t find out the reality until you actually have to implement a solution.
In terms of our most recent upgrade, there really isn’t much difference between the old and new because the solutions are basically the same technology under the hood, i.e. hybrid solution based upon open source OS and software, to implement a mix of edge and centralised approaches using L2 or L3 approaches.
Regards,
Stephen.
Wowzers!!
What an unexpected bounty of messages this link delivered.
I work on the global network engineering team for a consumer package goods company. I’ve been working with wired and wireless infrastructure for more than 3 decades. I really like the technology and respect all the vendors who continue to deliver new and interesting innovations with it. Greatest network improvement ever: Ability to add devices without a drill.
I found your article whilst searching for other’s thoughts about the differences between Autonomous vs Controller based WiFi.
I’m in what seems to be an annual event of presenting WLAN topology business case comparison. An event which has continued to deliver different results over the years.
Initial Controller based costs/”useful benefits” for business customers was overwhelmingly in favor of autonomous.
Population explosion of WiFi devices in recent years has significantly changed that in favor of controller based solutions. For reasons you have identified and other factors. For example, impact of autonomous on backline systems should also be carefully weighed and measured. ie: 6000 APs connecting to backline authentication services vs. 15 Controllers for the same number of APs. That’s a significant multi-faceted change with Capex and Opex impact to calculate and report out on.
This current time we are in with mobility on the rise reminds me of when PCs were introduced to enterprise. We still seem to struggle with attempting to maintain governance of PCs with process we founded for Mainframe. Mobility seems like the tempest to finally create a need to build a new framework of governance. It is so much more pervasive than the PC wave. The rate of change / innovation is not measurable in mainframe or even PC terms. This is truly the most exciting time I’ve witnessed.
Keep up the good work and keep the great articles coming.
PL
Brilliant article, clarified a lot of questions for me.
The discussion thread supports why I didn’t select Aerohive in a recent procurement. If someone has to strive so hard to sell their product, somewhere it is deficient.
Very Interesting. Where is Motorola in this discussion?
I work for Ruckus and we weren’t mentioned. I’m mad. :) Kidding…
JJ. I want to meet you sometime and buy you a drink of your choice. Nice work in the article and the responses. It’s a tough crowd. :)
GT
JJ,
Thanks for the concise post on the different wireless architectures. I found it very informative; especially for the intendend audience. I like the fact that it is “vendor” neutral and free from “spin”. I have also read all of the subsequent comments and feel moved to share some of my thoughts as well.
I deployed the HP E-MSM solution very soon after the Colubris aquisition because of the flexibilty it offered in handling client traffic, either tunneling or distributing traffic at the edge via vlan trunking. At the time, no other leading vendor was doing this as elegantly as HP/Colubris. I do agree the future lies in controlling traffic at the edge. However, for now, I need the option of tunneling traffic back to my core because I do not have the ability (yet) to do policy based routing. The MSM765 has a 10GB connection so bandwidth is not an issue. The one big issue I have with HP E-MSM right now as Devin pointed out, is that when the controller is down, the AP’s are useless even though the traffic is being distributed at the edge. My 6000+ users don’t like that.
As a result of my negative experience with the HP E-MSM architecture in my environment, I am now looking at other solutions including Aerohive and Meraki. In my opinion, they offer the flexibilty I need without the reliance on the controller. I too share your concerns about “cloud-based” management but I am sure I will get over it eventually.
Any solution has it’s pros and cons. What it really boils down to is good network management and the ability to be flexible, especially with the impending doom of “bring your own device”.
Hi Paul,
Thanks for the comment! I agree with everything you’ve said and it make sense to me. My feeling about a controller as a single point of failure is this… Personally, I’ve never had wireless go down because of a controller (not yet, anyway). For mission critical wireless, our customers always have an HA configuration. And, in cases like the MSM 765, with the switch module form factor, if the SWITCH goes down, very often there’s a much bigger problem, and in many cases, that’s a routing device, so regardless of the AP architecture and whether it needs a controller is a moot point, because the traffic can’t be switched or routed out.
Having said that, my bigger concern is that yes – if you have configured it so that all the traffic tunneled, and the controller goes down, you lose a lot of functionality (ALL functionality, in some cases). However, here’s my rebuttal for that. In these cases, even if the APs are directly handling traffic if any of the backend services go down (RADIUS/IAS/NPS, AD, Captive Portal services, certificates, etc) then you’ve lost those parts of functionality also. So, in my mind, the controller is not any more of a point of failure than the rest of the infrastructure that’s integrated, and required to run the wireless.
Also, as you’ve experienced, it’s much more difficult to control VLANs, routing and security policies out at the edge, than something more centrally-located. Again, some vendors will argue this point, but we work with high-risk organizations, those with many regulatory compliance requirements, etc. Centralized models are much easier to maintain and monitor for many organizations. And, for those that don’t have the personnel and resources to manage VLANs to the edge for AP, it’s almost a requirement for an efficacious solution. I do quite a bit of maintenance on switches for customers, and those with heavy APs (or before Devin jumps on me for using the word “heavy”.. those APs that bridge locally) are always missing VLAN tags. It’s hard for maany organizations to manage.
Some vendors just really over-hype the controller-less architecture, in my opinion. It has its place, and is appropriate for some customers (as it sounds like it may be for you), but the benefits are sometimes over-exaggerated. You’ve reached the conclusion because you’ve tried things and have experience and an understanding of your environment and what works and doesn’t work for you. That’s a great way to operate, versus going with a solution based on FUD a vendor threw out. I tried to accurately highlight he pros and cons of each architecture, based on my experience directly with the technology and the customers using them. Are there OTHER features and bells and whistles I didn’t cover- absolutely!
-jj
Full disclosure: I was previously an Aerohive Customer and worked for a C1 Law Enforcement Agency in SC for 13 years and SC State Government for 19. I believe in taking chances when the value is there and that is what I did with David Flynn and Aerohive because I believed in their conceptual vision.
Now having said that…
Devin and I have already had a twitter DM conversation about this but I felt the need to post here so that things are subjected to the light of day.
First of all, the condescension was not called for and attacking JJ at all is not something that matters to anyone that knows her except to put you in a bad light. The reality is that day in and day out JJ deals with customers that need things explained a certain way. While there could be some minor tweaks to her post, I think the vested interest by anyone responding to her in this post tends to overshadow anything else whether valid or not. The problem is, when you sell hammers….everything looks like a nail. JJ does not have that bias because she can sell any of you and make money and as a matter of fact she can sell the less optimal solution and just charge more for services. Agree or disagree, I know that when JJ writes something she has done her homework and actually the terms she uses are the ones I heard as a customer no matter what my level of certifications. To be clear, I have them so if we wanna start listing shit back all the way to Enterprise Certified Network Engineer I can do so, but what is the point.
No matter, agree or disagree, bring your objections constructively because the minute you step up and act like an Alpha on someone like JJ or myself or any of us for that matter…, our dogma will eat your karma…and then where are we? You would be the same way.
Dev, I love ya bro and Bryce knows I have been a big supporter but when given the chance to talk about what you do and do not do…take it seriously and do what you can to make sure folks like JJ can inform the general public. I take umbrage at you saying that professionals don’t take this blog seriously because in reality I pay so much less attention to vendor bullshit than I do knowledgeable VAR or professional sites simply because the agendas, while there, can be overlooked in most situations for the good of solutions that work as a whole…
Why?
Because no matter what, these folks have to live with the stuff they sell while the manufacturers can just blow people off…
Why do you think my ass went direct so much? I need a throat to choke and JJ and folks like her are that throat so treat them with the respect they are due.
Separately, of all the people out there, JJ is one I respect a great deal for her professional skill and business acumen. She does get it, whether or not she agrees with you or Cisco or anyone…she gets it. That is not a phrase I just throw around and you know that.
Anyway, peace…love…and all that jazz.
Should I list all my certifications or just the most recent half a decades worth? Just checkin because, ya know, I like Donkey Kong so bending people over barrels is right the hell in my wheelhouse.
Jus’ sayin…
*grins*
David
@David Awww :) Thanks! That means a lot coming from you.
@Andrew I’m definitely Germany.
@Devin hasn’t been skipping meals so I think we’re all okay now.
Except, someone (Andrew?) still needs to tell me where to place appropriate Cisco solutions in the list. And, my door is still open to either or both of you (jointly or separately) writing a piece on management versus control plane. I’ve been meaning to since I wrote this original post, but frankly, RSA is more pressing at the moment :)
Here’s a picture of something we all love:
.
.
.
-jj
I feel like I’m Great Britain watching the invasion of Poland by Germany in 1939… and I don’t even know which side is which at this point! And what’s worse, if I step in to help I’ll just get Blitzkrieged like the rest :P
I think we are all passionate about the technology and getting it RIGHT for customers. Let’s agree on that :)
As for the “other” stuff (aka where this all started), well, our blabbering on here doesn’t make a whole lot of difference anyways. The market will choose the solutions that are best for customers. (Customers themselves may not choose the best solution for their own needs, but will find out the hard way and learn if nothing else).
I try to stay objective and vendor-neutral. Ultimately, if you take pricing out of the equation then almost any solution on the market can meet customer needs. And lets face it, pricing is only one consideration customers make in a selecting a solution. Vendor partnership, trust, and familiarity also play huge roles in those decisions. I’ve stated many times before, but I’ll say it again – the best technology rarely wins on its own laurels. Solutions that meet business needs and are the “best fit” almost always win regardless of the best technology or the lowest price of another solution.
Peace, love, and the kickass Wi-Fi to you all!
Andrew (Wi-Fi and Nerdy) vonNagy
P.S. – Yes, I changed my nickname from “Pretty Fly for a Wi-Fi Guy” to “Wi-Fi and Nerdy”. But I still like both!
Keeping my response simple:
1) Yep, Chief Wi-Fi Architect, Aerohive Networks. Guilty as charged. Thought that was clear…but thanks for clarifying nevertheless.
2) You over-reacted with an over-the-top response to my comment regarding Andrew’s credentials. As a technical professional involved in social media, that’s not a great idea. ;) I’m speaking from experience.
3) The only real value this blog currently has is that Google will rate it highly because of the key words in the responses. No self-respecting industry pros will support it as-is. Would love to see you make appropriate edits because it has the potential for greatness.
4) On terminology: you lost control of your creation. Your point no longer matters.
5) Your paragraph starting “At Aerohive” is spot-on. No arguments. My accusation that you don’t seem to understand the difference between the control and management planes is due to what you wrote in the article and your responses. Andrew drew the same conclusions about your understanding. If you understand the differences, awesome. Please represent. ;) If you have points to make in light of that knowledge, throw down. We’re here to support you – EVEN if it’s to say that you’re 100% right about what Meraki, Xirrus, Aruba, or some other competitor does or doesn’t do. Truth is truth…no matter where I work. Andrew is vendor neutral and can claim to run one of the largest Wi-Fi networks in the world…and it ain’t Aerohive, trust me. Lord, I wish it was. :)
6) When the controller is down, the APs lose features with HP/Colubris. Need a list? Let’s start with key caching for L2 fast/secure roaming, L3 roaming, RRM, and RTLS… W00t.
7) You talk about trunk pipes to the AP like it’s an Aerohive and/or Xirrus thing. It’s an everyone thing…both now and forever. If you’re still deploying APs on access ports, get ready to say goodbye to that. Write it down.
8) On that 2b point, I don’t know either, and maybe your site had some kind of odd issue, but it isn’t, by a long shot, the norm. If it was, it would be the death of 2 companies… Instead, other companies are moving into cloud management already. I know without a doubt that in the SMB that you already have Ubiquiti entering the market and Adtran/Bluesocket is coming into the SME with public/private cloud as well. Vendors aren’t running away from this model, but instead are running toward it. You’ll see at least 2 large enterprise players enter this market soon enough, and already you’re seeing Cisco and Moto hawking large centralized controllers for distributed branches. Same basic scenario for firmware and config updates. I’m right. End of story. Yes, I know I can be an ass sometimes…it’s Friday night and I’m spending it arguing with you on a blog, I haven’t eaten in about 12 hours, my blood sugar is low, and I need to fix my stupid Palo Alto firewall because GlobalProtect is the buggiest thing ever…. I claim the right to be irritable at this very moment. :)
9) Point 4b. I don’t feel like being an adult right now. First glass of red is in the history books. You should be glad that #2 is still in the bottle. Need a job? You’d be really great at sales. :P OK, that was wrong. I apologize…but I’m not deleting it because it was funny.
10) Trust. Yes you are. You’re just feeling wounded because I rained on your acronym parade. I still love you. I just want you to fix this blog so that all of the vendors (incl Aerohive) can point to it and say, “See, JJ knows!”
11) Yes you do. You do care. If you didn’t, you wouldn’t be spending your Friday night arguing with me, probably polishing off a bottle of red while thinking, “that bozo Devinator is wasting my Friday on Wi-Fi architecture! ARGH!” :D I challenge you to give this blog another try…it’s not terrible, but it’s not your best either. If you have all this piss and vinegar in you to argue with Andrew and me (that takes balls), then put it to good use and turn this post into something great…not just good. Dig deep. Grow. Be excellent.
Your friend,
Devinator
Oh sweetie, I’m a Southern girl… this isn’t anywhere close to “piss and vinegar”. I just refuse to be bullied, that’s all. :)
Bless your little heart. Go eat something. I’m trying to understand WTF is going on in this movie “Death Race” my husband’s making me watch. I’m ready for a reverse 180 in the cul de sac.
-jj
Oh, and I’m not rewriting this post. I like it. If you don’t, my invitation stands for a guest post. I’ll gladly title it “Why I’m wrong”. No joke.
-jj
Hi jj,
First, I couldn’t find fault in anything Andrew said…and given his credentials…I’d say he’s got you over a barrel.
Here are my responses to your responses to Andrew’s responses…numbered to match your response to his responses. Just sayin’.
1a. There’s no such thing as a Heavy AP. You harp on terminology, but you mis-use it. Now, before you decide to go off on me, consider that as co-founder of CWNP, I actually helped create and decide on industry terminology over the last 12 years in this industry. Accuracy and consistency is key, and you are doing neither in this article.
That little section in white is the most horrible thing I’ve ever read. It’s confusing on a variety of levels. The explanation that Andrew gave was spot-on.
* WNMS manages APs and/or controllers.
Controllers operate the real-time functions of the Wi-Fi system and can be replaced by protocols between intelligent/coordinated APs in some systems.
The problem here is that you still don’t seem to understand the difference between a management system and a controller. Andrew made that quite clear. To reiterate:
A WNMS performs functions such as reporting, pulling stats, pushing configs, and pushing firmware updates
A controller perform functions such as RRM, authentication, tunneling, WIPS, key caching, etc.
A controller can be used as a management system, however, a management system is not, and cannot be used as a controller. Please understand this fact.
You are 100% wrong about customers not caring about the difference between a control plane and a management plane. It all depends on the type of customer, vertical market, and customer needs. Aerohive makes its living selling to customers who require a superior level of up-time, scalability, no single points of failure, and so on…and all of this comes from our architecture, which is built on cooperative control protocols at L2 (between intelligent APs). There are no controllers in our platform. Our management system is not a controller. If our management system fails, our platform (APs) still runs at full capacity with full features. This is important to 100% of our customer base. Our ~3500 customers (and growing very rapidly) are proof that your statement is wrong.
1b. Name one controller-based system that can do as you say, and please explain how it works. :) I understand how every almost system on the market works, and I don’t know of one that can do this…even after 13 years in this market. Andrew is right.
2a. No such thing as Heavy APs. Terminology matters. On extending trunks to APs – Aerohive has ~3500 customers who would agree with Andrew. Then of course there’s Xirrus, Ruckus, Meraki, and well…any controller vendor who is doing distributed data forwarding (at the AP). That would total tens of thousands of customers who disagree with you. If you plug an AP into an access port, then you have to tunnel your data to the controller, killing your scalability. You can’t have it both ways, and in an 802.11n world, scalability is more important by a mile than the admin’s hope not to ever have to deal with VLANs. :) Sorry, you’re just wrong about this. I don’t know which vendor(s) you implement for, but I will bet you lunch that I can get them to tell you that you’re wrong. :)
VLANs at the AP are the future, are required for distributed forwarding, and will rule the roost from this point forward. The way you’re doing it today will go away.
2b. Aerohive has customers with up to 10k APs using cloud-based management. I know Meraki does as well. You’re WAY off base on your assumptions there. If it were not so, Meraki would be out of business, and Aerohive would’ve had to stop selling cloud management. Instead, it’s over half of our management sales. First, Aerohive has a feature that allows firmware to be pushed to a single AP of each type at each location and then those APs push the firmware across the LAN to other APs of that type securely. Secondly, I’ve been using our cloud management system (HiveManager Online) for over 2 years, and I’ve never experienced what you mentioned. Were you speaking from experience with our system, Meraki’s or some other system? What would be the difference in pushing from a cloud management system and pushing from Cisco or Motorola’s gigantic “cloud” controllers? Not much…firmware has to go over a WAN link…only our system is more intelligent than having to push the firmware to every AP individually. Silly rabbit.
3a. Nothing to discuss. Andrew was right.
3b. I agree with Andrew again. Whether using a controller-based platform or a controller-less system like Aerohive, because of the need for distributed forwarding to scale your throughput, you must extend VLAN trunks to the AP. To do otherwise means you must tunnel everything to the controller – a massive bottleneck that will only get worse with faster 11n speeds, 11ac, and higher client densities.
3c. Please read his blog. It rocks.
4a. Dear lord…stop with the BS. Andrew was spot-on. End of story. Every controller vendor knows this and is moving toward a controller-less solution for this very reason. Features versus scalability is an unacceptable decision to have to make.
4b. Given that you don’t understand the difference between a controller and a management system, I’m not sure I’m ready to extend any technical trust just yet. :)
I worked for CWNP for 10 years, working directly with every vendor in the market during those 10 years…most of whom are still in business today. Andrew is a CWNE and CCIE, and he has the good fortune of being able to vet solutions from any vendor he chooses given his employer’s buying power. Additionally, he has participated in the last two Wireless Tech Field Day events and offers technical feedback to a variety of vendors. I think that qualifies us both to fairly and equitably represent the architectures and technology solutions of other vendors. You may note that though I work for Aerohive, I admire technology solutions from a variety of other vendors and have stated so often.
Final Notes:
1) In your original post, you left out an entire category of cooperative APs, whereby protocols between intelligent APs take the place of controllers, and those APs are managed by a management system. This architecture is unlike anything in the other categories you listed.
2) I know my tone in this response is likely a little harsh, but your go at Andrew was a little more than I could stomach to be honest. He’s one of the finest technologists in this industry. Please do your homework before going on the offense. ;)
3) I like technical discussions like these, and I’m glad you took the time to write the blog to start with. I think it was worthwhile, but I don’t think it achieved its goals of properly educating the audience. Perhaps a rewrite whereby my suggestions, Andrew’s suggestions, and others (pinging Marcus Burton at CWNP, Keith Parsons at Ubiquiti, GT Hill at Ruckus, and I could list others if you like) would be taken into consideration. It could ultimately be a very nice article that we all point to and support.
Devin
Devin,
First, I think in the interest of full disclosure you need to let everyone know that aside from being involved with CWNP, you are in fact also the Chief Wifi Architect at Aerohive. You mention working with Aerohive in your comments but I’m not sure this was said specifically.
Second, I take extreme exception to you saying “given his credentials… I’d say he’s got you over a barrel.” First, I have nothing but respect for Andrew, so this is not directed toward him in any way. I assume you mean CCIE and CWNE? Those are both EXTREMELY admirable certifications, and ones that are difficult to attain. I’m not arguing that. If alphabet soup is what you want, I have my CISSP, and in fact was one of the 20 people internationally that wrote the last official (ISC)2 CISSP courseware. I have my HP Master ASE (their highest level technical certification) in three different disciplines, including Infrastructure, Wireless and Security. I’ve consulted for vendors to write some of their certification training and testing. I’ve had Juniper JNCIA certs (full disclosure, recently expired), I’m recently Meru MCE certified and in fact was planning dates for Aerohive training too. I’ve read almost the complete set of CWNP certification books. Actually that’s not true; there are a crapload of them, but I’ve read CWNP and CWSP materials. And I’ve had a list of other various vendor and technology certifications that I don’t think are even relevant here because I don’t drink the alphabet soup Kool-Aid.
No, I don’t have the CWNE certification, so I’m not as cool as you two, and I don’t suppose to be as experienced as you are. But, aside from certification, I do live in the real world, and have read full implementation guides and deployed several vendors’ wireless in production environments. I’ve been in this business since I was a teen and I know the value of certifications, and the value of real-world experience, so please don’t patronize me with certifications or imply that what I’m saying has less weight because I didn’t throw acronyms behind my name.
I’ll get off that horse now and move on.
On terminology…
You’re still missing my point. This wasn’t written for people like you and Andrew, I’m using terminology that my customers understand. And, I feel comfortable saying, despite not being a CWNE, I’ve been in this business a very long time too, and I maintain hundreds of clients and consult and work directly with everyone from SMBs to international organizations. I talk to engineers, I talk to network admins, I talk to CIOs, CISOs and everyone in between – on a daily basis. Daily. Every day, this is what I do. I don’t manage a network for just one company, nor do I deal with just one wireless vendor. I talk to people every day, and I know what terminology they use. Since you seem to need me to validate myself, I’ll play along. I speak at all types of events, including RSA, Interop, SecTor, DeepSec, InfoSec World, CSI, NSA Trusted Computing, TechnoSecurity, USSS ECTF, FBI Infragard, and more places that just really don’t matter. I’m not a country bumpkin stuck in the backwoods of NC. And yes, *gasp* I too consult for vendors prior to, and during development. Enough with snarky, it’s not productive or even entertaining at this particular moment.
At Aerohive, your special sauce is in having a controller-less architecture. I get it. I understand that completely. But what that means is that it is of utmost importance for you (plural) to describe the difference between management and control planes to customers, and to make them care. That’s how you sell your product. Every vendor has their sauce; that’s yours. But don’t think that customers KNOW the difference out of the gate. They know because they’ve been educated by someone who has a vested interest in making sure they understand the differences, and someone who will highlight the benefits of one over the other.
In your comment to me you said “The problem here is that you still don’t seem to understand the difference between a management system and a controller.” Devin, I can assure you that is not true, and I think you know better. I believe you’re having a knee-jerk reaction and you’re not hearing me. I’m using terminology that the CUSTOMERS use and understand. Yes, shame on me for not following it up immediately, or incorporating a side-note of “here’s the difference between management and control, and what each does.”
But Devin, to be fair… did I not reach out to you via Brice so that we could have a discussion about this, and to give you guys the opportunity to speak your piece on this and set the record straight from your side? We’ve exchanged brief emails, but I haven’t had the chance to speak on the phone to you because I’ve been out of the office in a training, then onsite.
re: 1b. Colubris, now part of the HP MSM series of wireless.
re: 2a. Yes, and do you know what happens? I’ll tell ya’ what I’ve seen… some (many? who knows; I won’t say most because that’s making assumptions on my part), but some of these customers have NO CLUE what they’re getting in to. NOW LET ME INTERJECT THIS BEFORE I GO FURTHER. I like Aerohive, and it has its place with many customers. The technology is neat, the over-the-air routing is awesome and my next comments are no reflection of Aerohive as a company. But I’ve read entire bid responses from Aerohive resellers, and there’s quite a bit of misinformation in there. I don’t blame Aerohive; these are resellers and I don’t know where they get the information. I’ve also come to notice that, at least in the bids I’ve read, at no time was it described that VLANs, etc would have to be extended to each AP. I’ve had customers call panicked after they put Aerohive and Xirrus in place, then needed to add guest or additional networks. Panicked. No one told them about the process involved so they weren’t ready for it. Again, in these cases, this is via a reseller, not Aerohive directly, so I’m in no way attacking Aerohive here. But shame on them. I think you underestimate the overhead in a production environment for organizations that may not have a dedicated wireless management person or team.
“VLANs at the AP are the future, are required for distributed forwarding, and will rule the roost from this point forward. The way you’re doing it today will go away.”
I respectfully disagree, at least for now. I think wireless needs an overhaul, and when it happens, I think the way we’re doing it now will be morphed into a new solution. For now, many organizations need the control of tunneling certain types of traffic back for centralized control and visibility. I anticipate how wireless integrates with wired devices will change drastically in the not-to-distant future, and we’ll have standards for identifying, provisioning and managing wireless devices on the wire. Until then, I disagree with this comment.
2b. This isn’t an assumption. I’ve experienced this first hand at customer sites. And come on Devin, you can’t control the Internet. If your management tool is on the Internet, and there are issues anywhere between you and that tool, you’re going to have problems. Be reasonable. I can tell you a story about Meraki in private, should you want to discuss that. Again, the sites I’ve been to with Aerohive, it was installed by a reseller, so maybe they botched something. What I know is, at my last NAC install, when we tried to make changes and push them out, roughly 25% of them failed, and we had to select those and re-initiate, then again address any failed updates on those, repeating until they were complete. Maybe someone set it up wrong? Maybe there was a WAN or routing issue? I dunno.
4a. How about instead of calling my response “BS” you address it like an adult?
4b. So sorry you feel that way, but fortunately for me, I’m not seeking your trust.
As for your final notes…
I have nothing but respect for Andrew, I think (hope) he knows that. And in fact I value his experience and ability to articulate so much that I have asked if he would be interested in writing a guest post here addressing the controller vs management issue to un-muddy those waters. That offer still stands, and I think readers would benefit from that knowledge. All snarky comments aside, I think we had a good discussion on twitter and here, as part of a dialogue. I learn from everyone, every day. Don’t assume I don’t do my homework. I reached out to Andrew before I published this post. But also you should not assume that because someone has letters behind their name, that I will follow their every word and not challenge him or her. And to my readers, I encourage the same. Challenge me, challenge anyone, and force us all to think and grow.
And in closing, to address your last statement… I’ll quote “frankly, my dear, I don’t give a damn”… whether you think my post achieved its goal. It was my article, and I decide the goals and success, and I am pleased. A lot of people found the explanations to be extremely helpful. I did ask most vendors where certain lines of their products would fall, and I respected what they told me as long as it had an explanation.
We’ve both been harsh here, and I hope the exchanges, while entertaining, stay professional. From my end, I respect what you and Andrew have said. You’re obviously passionate about this, and so then my olive branch to you is to also extend an invitation for a guest post, if you’re interested.
-jj
Devin,
I left a thought dangling that I think I need some closure on (for my benefit).
When my customers do call, panicked about extending VLANs or configuring for Xirrus or Aerohive, never would I say (or think) “I told you so”. Never do we criticize their decision or attempt to sway them towards a different wireless solution. What we do is find out what switches they have, and what management tools are available, and make sure they know we’ll fix them up with a good way to manage it all. Luckily, you guys make good use of LLDP and we can find APs quickly. My customers are smart, and if they’ve selected a solution, I trust that they had enough information to deem it the right solution for them. If we need to work around a little unexpected issue, that’s what we do, and that’s what makes us good at what we do. We’re not cultists, we’re integrators.
-jj
Hi JJ,
I think you’re article is well intentioned for a customer audience, but is also misleading in many regards.
First, defining management systems as “controllers” is blatantly wrong in my opinion. Controllers serve to coordinate operational capabilities of APs in real-time, such as radio management, authentication, and key-caching. Management systems, on the other hand, are solely for non real-time capabilities that do not impact the operation of the network, such as new configuration deployment, code upgrades, monitoring and reporting. The big difference is network uptime and stability between the two. If a controller goes down, the network operations are impacted. If a management system goes down, the network continues to function. It’s also important to understand that controller based architectures still have a separate management system that is usually used (e.g. Cisco WCS/NCS or Aruba Airwave). The two systems are not the same, and calling them both a controller misleads customers in my opinion.
Second, and this probably more opinion based, is that I don’t agree with the Cons you have listed for architecture #2. Extending wireless VLANs to APs and setting up APs as authenticators to RADIUS are not difficult or complex. Customers must deal with switch port configurations anyways, and there are mature solutions in this space that are affordable for even the smallest customers. I also don’t agree that the success of changes pushed from cloud-based management solutions can be spotty. That only indicates issues with overall internal network design that need to be corrected and isn’t a reflection on the cloud-based platform in most cases.
Third, I think there is an industry-wide mis-perception that lightweight APs used in architecture #3 are dumb, not intelligent, or nothing more than radios (as you put it). This is not true, and APs have boatloads of intelligence. Many lightweight APs perform the encryption / decryption, QoS queuing, split-tunneling logic, detect WIPS attacks and report them back, and spectrum analysis. Just because some logic is split between the controller and AP does not mean the APs are “dumb radios”.
Also, with controller based solutions like #3, deployment may not always be “swift and simple”. They can be very complex due to controller discovery, tunneling packet overhead and fragmentation throughout the network, the difficulty in troubleshooting performance or QoS issues when traffic is tunneled, and properly designing multi-controller tunneling for guest networks or layer 3 roaming. If maintaining switch port VLANs is your drawback listed for #2, then deploying custom DHCP options in each and every DHCP scope for controller discovery is just as big of a pain for #3. I don’t think either are difficult, but felt that should be called out.
I have a whole series on my blog about CAPWAP operations, and I think those are a testament to the complexity of designing a controller-based solution. Intelligent AP solutions that do not use a controller or tunneling are much more straight forward to design and support in my opinion.
Your point about advanced RF management and troubleshooting offered with #3 is true versus #1, but not versus #2. There are intelligent AP solutions in category #2 that offer just as robust (and sometimes more robust) features than controller solutions in category #3. Making broad-sweeping statements like that are very misleading for customers.
Finally, architecture #4 is almost always accompanied by glaring feature reductions compared to #3. When APs are put into split-tunnel mode many features are lost. Coming from a large enterprise that has been working with multiple vendors on such solutions, I can tell you the features missing have been very substantial. See my post on H-REAP feature limitations and see for yourself. To leave that out of your analysis is a big hole in your article.
Also, category #4 is likely NOT more steeply-priced when compared to a similar deployment with category #3. The split traffic solution typically actually allows centralized controller hardware to accommodate more APs at once, and removes the need for many more local controllers. So, while a few big centralized controllers seem more expensive per unit, they actually reduce the overall solution cost be eliminating many more local controllers. In addition, licensing is usually more efficient with centralized controllers as well, since less AP licensing is wasted. If a customer has 5 sites with 20 APs each, local controllers may require 25 AP licensing thus wasting 25 licenses. With a centralized controller and a single 100 AP license, 0 licenses would be wasted.
I appreciate your attempt to simplify the conversation for customers, but its a slippery slope between explaining solutions in terms they can understand versus mis-representing solutions and their capabilities.
Thanks,
Andrew vonNagy
Andrew,
Okay, I’m going to try to address these in order…
1a. Controller vs. Manager wording
I agree that there is a difference, and I thought I did a pretty good job detailing what a management-only system does, in Type 2.
I understand your irritation here is that I used the word “controller”. I wrote this article to clarify architectures for customers/users (not wireless pros), and 90+% of these users refer to WHATEVER is managing their wireless as “the controller”. They don’t know (or necessarily care about) the difference between operations at the control plane versus the management plane. In fact, as others have pointed out (various discussions here, and twitter), many wireless SEs even refer to them generally (albeit incorrectly) as “the controllers”. I won’t argue that it’s not technically correct; it isn’t. You’re right. But the point was to explain differences in AP-mgmt/ctrl interaction to users, and I think we accomplished that.
1b. Controller vs. Manager and availability
You said “The big difference is network uptime and stability between the two. If a controller goes down, the network operations are impacted.” I have to respectfully disagree here. There are wireless solutions that can do both/either. Meaning, the controller can be used for authentication, or the APs (still under a controller) can do their own authentication, or other services. Along the same vein, some of these systems can also selectively tunnel/encapsulate traffic, or choose to bridge it locally. In these cases, the controller’s availability doesn’t affect the continued operation of the AP. Now, to be fair, in MOST cases, you’re right, but there are cases where this mode of operation is possible, so a blanket statement (if we’re being very specific here) isn’t quite accurate.
2a. Managing heavy APs
You commented that “Extending wireless VLANs to APs and setting up APs as authenticators to RADIUS are not difficult or complex.” Again, I have to disagree. In my job, every day I work with customers on this EXACT issue, both wired and wireless. This is WHAT I do, and customers do not find it easy or uncomplicated. And, I disagree; there are not good tools available to auto-provision VLANs to edge ports for APs to address this. Some vendors have proprietary auto-provision VLANs but they only provision the communication VLAN between an AP and controller, and so far I’ve only seen this offered in a very few solutions, none of which go with Type #2. On top of having to do this for regular wired and wireless customers, I have to do this with all of our NAC implementations, which is why I know first-hand the difficulties between architectures and vendors. Lots of hands-on… Here are some complexities to address when dealing with Type 2 vs a Type 3:
I base this on real-world, daily interactions, not conjecture. In the past few weeks, we’ve had several customers we’ve worked with that are using Type 2 wireless, and they’ve hired us specifically to do the tasks above: find their APs, document it, and extend vLANs for Guest Networks, secondary SSIDs, or NAC needs. I’ve also found that most of these installs are dropping the wireless traffic directly on the production VLAN (I’m sure to avoid having to extend VLANs to each AP). I can’t imagine that the vendors recommend this, but it’s how their integrators are implementing it, and it’s in poor practice, so there’s a lot of cleanup here too; when we have to go in after an integrator and add vLANs that should have been in place when they installed the wireless.
2b. Cloud-based management
You can’t control the interwebz… and my (again, first-hand experience) has been poor performance when trying to update more than 5-10 APs at a given time. Most of our customers have hundreds or thousands of APs, not 20 or 30.
3a. Dumb APs
You’re right, but I’d say most of those solutions fall under Type 4, not Type 3 in my list. Some are only dumb APs, such as the HP WESM solution. In fact, they refer to the APs as “Radio Ports” because they’re basically pretty antennas; they have no intelligence. You’re right though, other vendors do have intelligence in the AP here. Again, the point in this article isn’t to discuss wireless features, but to explain how the APs interact with mgmt/controller by way of traffic and VLANs.
3b. Discovery and tunneling
Out of all the things I’ve had issues with in wireless, AP discovery is not one of them. The only time it has been, is when there was a cabling (layer 1) issue, never L2 or L3. Most solutions look for controller L2 with a broadcast first, and can be set to either go directly to a controller by IP, or they are directed to a controller via a DHCP option 43 or a DNS entry. Any of that takes just moments to set up and I haven’t had an issue with it. Some proprietary solutions let a controller act as a “master director”, APs go to it, then the director controller can direct it to the appropriate controller based on a variety of rules.
As for VLANs and DHCP, everyone works a little differently, but I think you’re a lone puppy here. I can’t think of one person I’ve worked with that thinks finding and extending VLANs across specific switch ports in an infrastructure is the same or LESS difficult than sitting at a DHCP server and chugging out new scopes. I can have 10 DHCP scopes added in 15 minutes, with options and all. Try to add 15 VLANs across appropriate switch links and edge ports… and I don’t mean GVRP, that’s never recommended and won’t address edge ports.
3c. CAPWAP
Yes, and I’d encourage any readers here to check them out, starting here: http://revolutionwifi.blogspot.com/2010/11/capwap-split-mac-architecture-overview.html. Keep in mind though, a lot of this is very geared toward Cisco, and not all vendors implement it exactly the same way.
4a. Architecture 4 limitations
But, limitations are only within the portion you want to split or change. Overall the capabilities of the system are more robust (in my opinion) and you have more flexibility. If a customer chooses a specific implementation of a type 4 that limits them in some way, it’s by their choice, and they have the flexibility to re-configure it if their needs change later, versus being stuff with an architecture.
4b. Pricing
As a reseller and VAR of many many many years, we have been a reseller and/or quoted HP (through 3 solutions), Cisco, Aruba, Meru, Meraki and we have pricing models for several other solutions that our customers use (and we support) including Xirrus and Aerohive. I’m going to ask that you trust me on this one.
All-in-all, you make great points here, and I think we all benefit from the dialogue. I will say that a lot of your experience and content seems to be geared mostly towards Cisco solutions, and while your grasp of the technical details (Cisco-related, and wireless as a technology) is extremely admirable, I want to make sure we’re all clear that no one vendor can represent fully the model of others. Everyone’s a little different, and my goal here was to express to those implementing wireless how the communications and traffic moved in the network. I did this for a very specific reason actually, after being asked to review several bid responses for public sector in which vendors/respondents (not necessarily the manufacturer) replied, but when asked some of these questions, they misrepresented or omitted details. I think this article was successful in the mission I had for it.
P.S. It sounds like the information I had from Cisco on some of their solutions is incorrect, and we need to fix that, so I will be reaching out to you on those.
-jj
jj,
How would you classify Aruba Instant in this framework?
Hi KM,
Aruba is listed as able to operate in method 3 or 4, depending on the configuration required.
KM, sorry! You asked about Aruba Instant AP (I missed that the first time). Multitasking fail. I addressed main architecutres here. I have some Aruba Instant AP-105s here, but I can’t speak to how they operate when one is managing/controlling others. Someone from Aruba (or familiar with that operation) would have to tell me if it’s a management-only (type 2) or if it operates just like true Aruba controllers (which would be type 3 and/or 4 depending on configuration.
-jj
Would you consider the Bluesocket solution to be a #4 type of wireless controller system?
Hi Simon,
You’re right; I purposely didn’t include any interactions between the switches and APs that was proprietary (not IEEE standard) in this write-up. As you point out, most of the vendors have really cool technology that does something a little different and is their secret sauce, so to speak. I have an upcoming post that might speak to some of that. I’d love your feedback on that when it’s published.
Thanks!
-jj
Excellent write-up!
I think it would be worth adding a 4th architecture like the one Avaya is pioneering where where WiFi forwarding is integrated into the LAN switches. This kind of architecture seems to solved many of the issues with the previous 3 and is probably a good option for when the ‘post PC’ revolution reaches saturation point!
Hi Devin,
I do fully understand the operational planes. But, I think you’re further proving my point; manufacturers are confusing the technology buyers with technical nitty-gritty details of terms like “controller” means “control plane”. In a user’s mind (and just trust me here, because I talk to a lot of them), a controller is whatever they use to manage the APs. Whether it’s technically correct or not, those are the gears that spin when they hear the word.
So, #2 does in fact exist, but it sounds like your beef is just that I’ve referred to the management device as a “controller” which, is not an accurate term on a more technical level.
I get it, and that’s a perfectly valid point (and the details you provided are great). But as I said, I think it further proves the point that this type of comparison is needed for customers because they’re completely baffled by inconsistent terminology; accurate or not.
Maybe the next article should be on explaining what a “controller” and the control plane interaction really means?
-jj
Hi jj,
Your type #2 doesn’t actually exist. In Wi-Fi, like in all networking, there are three planes: data, management, and control. From autonomous APs (type #1), the follow-on was a centralized management system with autonomous APs, yet WITHOUT a shared control plane. There was no controller, whether centralized like the “controller” model or distributed like the Aerohive model, in type #2. This was it’s problem, en total.
This problem forced the introduction of the controller (a single box that shares the control plane among APs). The reason for the introduction of this box was the cost, in 2003, of making all APs intelligent. Components such as CPUs, RAM, encryption offload, etc was just too high back then to make intelligent APs who could share the control plane among themselves. Fast forward to 2007 and beyond, and silicon became cheap, enabling the controller-less model, whereby the control plane could be shared among APs using a protocol suite instead of controller hardware or software. This eliminated the need for the centralized controller altogether, increasing reliability, scalability, and cutting cost by 50% minimum.
This direction of using a protocol suite between APs to operate a shared control plane means that all features can be pushed into the APs and fully distributed forwarding can be accomplished without controllers. This reintroduces linear and unlimited scalability (like autonomous APs), less components, simple design, deployment, and troubleshooting, and will change how Wi-Fi is implemented in the enterprise forever. Aerohive started this trend in 2007, but others are starting to follow now, as expected.
Thanks,
Devin
@Avaya.
Described architectures #2 and #4 completely separate data plane and control & management planes.
How is Avaya different?
Gregor
Kory,
Aerohive is listed under type 2, as is Meraki. I know I’m missing vendors; I tried to hit the ones I’m seeing most and getting the most questions about. If there are other popular products, let me know and we’ll add’em!
-jj
Not to add more but there are ones like airohive and other mesh controllers.
Thanks Kevin!
-jj
JJ,
I officially read this twice, and I am now significantly smarter than before. Thanks for keeping us all current – and focused on the important differences, not just the marketing hype all the vendors in the mix. The right tool for the job should be what we focus on – and knowing if your Wireless environment is for casual/convenience usage, business critical or mission critical is an important first step when deciding which architectures you should be considering.
Again – Thanks!!
Re: Avaya,
I’ll be happy to add examples of the Avaya solution(s) that fit in any of these architectures. Keep in mind though, this is more of a foundational document for planning wireless as it relates to the wired integration, and is less specific on whether the forwarding/control planes are separate. If you have more details, I’ll be glad to include it.
Thanks!
-jj
Gregor,
Thanks – good thoughts. I did omit topics related to specific configurations (ie switches/firewalls) and everything on the RF side for the purposes of this document, but you bring up some good points.
-jj
What about Avaya’s split-plane wireless solution? It completely separates the control and data planes.
Thanks for this! Killer post.
To add to the description, uplink and downlink QoS also differs between the different architecture type (but is also switch dependent). Stateless firewalls on the edge may also make a difference for some customers.
For carrier infrastructures on the other hand calls for point to point “E-Pipes” based on SSID VLANs per controllers, carrying the WiFi traffic transparently across Metnet without the need to learn any client MAC addresses, also avoiding broadcast / ARP storms from DHCP or other such protocols.
My comment here is that features like WiDS and WIPS are not dependent on the infrastructure choice though.
Thanks again for your time on this!
Gregor