What's the best reason to stay with a controller-based solution when transitioning to 802.11ac?

  • 1
  • Question
  • Updated 4 years ago
  • Answered
If you read our blog or if you're on Social Media, you have probably seen the conversation about the death of the WLAN controller. Conversations on this topic are welcome here in the community, and here is a conversation to get you started. Please feel free to chime in, or start your own. Be sure to tag the Death of WLAN Controllers category when you post, and follow this category in order to stay up to date on the latest.

Question: What's the best reason to stay with a controller-based solution when transitioning to 802.11ac?
Photo of Amanda


  • 396 Posts
  • 25 Reply Likes

Posted 4 years ago

  • 1
Photo of Bradley Chambers

Bradley Chambers, Champ

  • 302 Posts
  • 53 Reply Likes

If you like sleepless nights, single points of failure, and showing others *how not* to build next generation networks.

Photo of Andrew MacTaggart

Andrew MacTaggart, Champ

  • 483 Posts
  • 86 Reply Likes
What's a controller? he said sarcastically.

you forgot cost and endless licenses Bradley
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2487 Posts
  • 449 Reply Likes
Erm, the best reasons to stay with them!?

Well... When the heating breaks, they're useful to take home on those cold winter nights to huddle around and stay  warm.

Controllers also make me feel important as they are often big with lots of pretty, flashing lights and large fans. It makes sure people at least think I must do something for my job when they take up so much space in the server room and wiring closets. They certainly allow me to mark my territory. (It is for this reason that I am unhappy with so-called virtual controllers that you run in a virtual machine, or anything small. Who wants that!?)

For me, the clear choice is:

(Yes, that actually is a wireless controller... 7U...
12.1” x 18.5” x 29.0” / 30.7 cm x 47.0 cm x 73.7 cm
80–240 lbs, depending on configuration / 36.3–108.9 kg)

Photo of Jenni


  • 93 Posts
  • 7 Reply Likes
These comments are cracking me up! Keep them coming and stay tuned for the next phase of our campaign where we get you to have a little bit of fun with this too ;-)

Photo of Gregg Kalman

Gregg Kalman

  • 1 Post
  • 1 Reply Like
Because it helps your alma matter (aka the company that taught you networking) more than it does the company that employs you.
Photo of Crowdie

Crowdie, Champ

  • 967 Posts
  • 270 Reply Likes
To play the devil's advocate there are some valid reasons to have a centrally controlled wireless network:

1.  You don't want to run hundreds of VLANs to each access point across a large campus.

2.  You want a single ingress/egress point for wireless traffic.  This is commonly used when you want all traffic to traverse a firewall and/or proxy.

However, this can be achieved using Aerohive's Cloud VPN Gateway product.  Place two of these into the corporate network and GRE tunnel (unless the access points have to traverse the Internet) the traffic back to the CVGs.  This means:

1.  The only VLAN that needs to be run to the access points in the management VLAN housing the access point.  The access point will GRE encapsulate the wireless user traffic and tunnel it to the CVG.  The CVG will VLAN tag the traffic, just like a wireless LAN controller, and place it onto the switching infrastructure.  You just trunk the CVG's inbound port(s) with all the wireless user traffic VLAN IDs.

2.  You can have a single ingress/egress point by routing the CVG's inbound port(s) to the firewall and/or proxy.
Photo of Joel V

Joel V

  • 50 Posts
  • 5 Reply Likes
Great answer! I actually asked the question to be posted because I want people to understand:

1. There are perceived valid reasons

2. 95% of the reasons can be addressed with a controller less solution therefore saving you thousands in hardware costs.

3. Just like Mainframes, you may find a couple of corner cases where you want to keep it! They'll be around for a while.

Bottom line - If you're cutting over to 802.11ac, consider your options and decide who is actually publishing FUD.

Great thoughts everyone! Keep 'em coming!
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I agree, though in my view Aerohive need to implement the GRE tunnelling function a little better to be able to do everything a controller-based solution can do.

Interesting we are talking about a data-plane function here, not a control-plane function! Why's it called a controller again? Anyway.

These are the issues with the way Aerohive have implemented GRE tunnelling:

1. There is no ability to have a failover configuration for GRE tunnels as there is with many controller solutions. For example, consider the common situation where there are two data centres (primary and secondary) with separate Internet connections (primary and secondary). The GRE tunnelling configuration in Aerohive can only specify a single range of IP addresses as the termination point (and addresses in this range are load-balanced). There is no way to have traffic egress the primary data centre in normal operation but failover to the secondary data centre (i.e. for the GRE tunnels to terminate on a HiveOS VA in the primary data centre, but if that is unavailable to failover to terminate on a HiveOS VA in the secondary data centre). Sometimes its possible to span VLANs between the data centres which solves half of the problem, but sometimes it is not.

2. In a common situation where some APs have direct connections into a VLAN but other APs need to use GRE tunnels, it is necessary to create completely separate network policies and duplicate user profiles as HM insists that every AP that references a user profile with a GRE tunnel policy be either in the "tunnel sources" list or "tunnel destinations" list. We therefore need one network policy referencing user profiles with GRE tunnels enabled and a second network policy referencing otherwise identical user profiles without GRE tunnels enabled. Why? Surely a logical design would be to assume an AP in neither list has a direct connection to the VLAN? Having to create separate network policies is a little crazy.

Fix these two trivial design issues and I'd say you have functional-equivalency with controller solutions.