Search Now

Controllers Add Wired Complexity to Wireless Networks

I can’t remember how many Wi-Fi classes I’ve taught where students have said, “There sure are a lot of wires for this to be a wireless class!” It’s a travishamockery, I know, but you just can’t totally get away from the cables in networking.

That brings me to today’s topic of how controllers add wired complexity to wireless networks. We all know about the cost and complexity that controllers bring to wireless networks, but in this blog, I’d like to discuss the WIRED side. Let’s take a look.

Controller vendors invariably tell their customers that their controller solution is redundant because redundancy is a requirement for any primary network. The most common redundancy type in the Wi-Fi market today, for cost reasons, is N+1. N+1 is where one active (online, live, hot) controller backs up one or more other active controllers, taking their place should they fail. Implementations of N+1 vary, with variables such as:

  • Feature licenses being required for the N+1 controller.
  • AP licenses being required for the N+1 controller.
  • Lack of client session state sharing between controllers.
  • Lack of automated configuration synchronization and consistency across primary and backup controllers (all controller vendors).

In order to implement N+1 for real redundancy, there has to be some wired-side (both power source and Ethernet connectivity) changes to the network that add significant complexity to a deployment. Without these complex changes, N+1 only provides redundancy for controller hardware failure, but doesn’t provide any real network redundancy. For example:

Some pertinent, co-authored (big love to #RevolutionWiFi) questions ...

 

  • Question: Do you power your Backup controller or Primary controllers from the same power source?
  • Comment: If so, any controllers powered from the same source will fail together if a power outage is the cause of the down time. A significantly more complex deployment of power to your controllers is required.

 

  • Question: Do any of your controllers and core Ethernet switches share a power source?
  • Comment: If so, they will fail together during a power outage, and your Backup controller will need to be connected to a different power source and Ethernet switch (than your primary controllers) in order to have access to the stranded APs. This probably means that the Backup controllers needs to be dual-connected via Ethernet, which also means that it will be grossly over-subscribed (unless it can load balance in two directions ... doubtful) once it is called upon for service. The complexity of power sources, Ethernet connectivity, and load sharing in this model gets out-of-hand quickly.

 

  • Question: Do you have redundant core Ethernet switches? Are they active/active or active/standby?
  • Comment: If so, then controllers should be connected to both of these switches, each with equal capacity. Given that controllers are already grossly under-subscribed on their interfaces as compared to APs in aggregate, splitting their interface speed between two core switches makes a bad problem worse and adds a tremendous layer of complexity to the data forwarding model. A major question that comes into play is whether or not the controller can forward data through both core Ethernet switches simultaneously. Do you know how switch stacking, virtual switching chassis, or other such technologies work? Are you prepared to implement them?

 

  • Question: Do you implement Layer-3 (L3) gateway redundancy? Which methods are supported by your router vendor (VRRP, HSRP, GLBP)?
  • Comment: A gateway router will serve as a single point of failure for multiple controllers when the controllers are sitting behind the same gateway. If you have designed a L3 network, are you prepared to support an additional L2 inter-connect between multiple redundant switches (including spanning tree)? How does that affect your wired network design and redundancy?

 

  • Question: Do you have visibility into client traffic tunneled between remote APs and your controllers over WAN links, traversing routers, firewalls, VPN links, and WAN optimization solutions?
  • Comment: How will you properly handle various client applications that are abstracted within a CAPWAP, GRE, or IPSec tunnel? Proper traffic shaping and prioritization become incredibly complex over WAN links. Tunneling can also cause packet fragmentation issues if you’re not careful, which increases network overhead and can create problems traversing firewalls.

 

  • Question: If you are considering a centralized wireless controller, do you have 10Gig capable switches, SFPs, and fiber cabling?
  • Comment: Centralized controllers sound reasonable when considered in the narrow scope of the wireless network (let’s not get into feature disparity right now though). :-) But have you considered the expense of adding or expanding your 10Gig wired switch footprint (ports, switch, backplane, etc.) to support those huge, honking boxes? How does 10Gig affect switch inter-connections upstream (cost, cabling type, etc.)? Have you evaluated the bandwidth capacity impact throughout your network to support all this data tunneling into and back out of a few centrally-located controllers? When 802.11ac comes, will you be ready to re-design your network, again?!


Controllers may seem reasonable on paper, but are littered with complexity issues in real networks. Most of them can be overcome with enough time, proper design, and skilled engineers on-staff or contracted. Additionally, this complexity prolongs incident and problem resolution and can significantly increase network operational costs. Don’t be fooled into thinking the vendor-quoted BOM is all-encompassing. Those hidden costs will eat your budget alive!  Perform a proper TCO, including required staff hires, training, consultant hours, wired network upgrade costs, and increased operational support expenses. It ain’t cheap.

Oy, vey ... and we’ve only discussed the WIRED complexities introduced by wireless controllers. There are tons more on the wireless side, but that’s another post entirely. If there’s one thing we hate, it’s complexity, and it seems that wherever controllers go, complexity follows.

Andrew & Devinator say: Simpli-Fi. Ya dig?



Comments for Controllers Add Wired Complexity to Wireless Networks

blog comments powered by Disqus