Technology Blog

Hidden Costs of Controller-less Architectures

by ‎12-20-2013 02:10 PM - edited ‎01-10-2014 11:47 AM

image001.jpeg
 
When we're in a hurry, controller-less architectures advantages are tempting. Controllers often require a significant amount of planning and resources, which includes technical decisions about tunneling, redundancy models, and sometimes extra bandwidth planning to accommodate centralized traffic.  These can be daunting to new WLAN administrators. Proponents of controller-less architectures argue that these complexities are too much and rarely (if ever) worth it.
 
But where do we hide the costs on a controller-less WLAN? APs, rather than purpose built appliances, now become the bottleneck for forwarding traffic.  This has has the following implications on larger campus networks:
 
  • VLAN explosion: network admins must configure edge switches to include all WLAN user VLANs, whereas if the AP tunneled back to a controller, it could preserve a user's VLAN tag across switching and routing domains via encapsulation.
  • tunnel explosion: when a user moves from one L2 domain to another, her traffic snakes through one or more controller-less APs before dumping on the right user VLAN.
 
Looked at this way, controllers -- despite the extra up front costs -- are considerably less expensive in the long run when deployed properly in large campus environments.  Not having to configure user VLANs on edge switches could allow for faster provisioning, particularly in remote campus areas. Tapping APs for pcap dumps can be tricky when tunneled traffic meanders across so many different access points, and a mobility controller at the core makes it easier to troubleshoot new devices that hit the market. High tech campuses with swarms of mobile students will usually find that students need to access resources north of the controller, which makes traffic engineering decisions fairly predictable, and in these cases, a controller is often a very good idea.
 
If all things are considered and you still want a controller-less architecture, how might Aruba be different? Well, two ways:
 
  • No forced cloud-management: Aruba does not compel its customers to use cloud-management on controller-less architectures.  A local (non-cloud) management tool is always available on each Instant AP cluster, and network admins have the choice of selecting cloud management (Aruba Central) or on premise NMS (Airwave).  At no point does the management features of the local Instant AP cluster go away or are not accessible.
  • Re-use NMS and policy manager: A controller-less architecture can still include the same AP hardware, policy manager, and NMS as controller-based hardware.  That means complex networks (e.g. a main campus with satellite offices) can leverage the same Aruba policy and NMS across its network, rather than having two different networks (unlike Cisco, which would sell a controller-based solution for the main campus and then position Meraki for the areas with a controller-less or cloud-management requirement).
 Network requirements change, and admin WLAN options should accommodate. Aruba understands these nuances and has a solution for both ends of the spectrum: the AP-based virtual controller and hardware-based mobility controller.

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Announcements
Read all about it! If it’s happening now, it’s in the community.

Check out the latest blogs from your community team, the community experts and other industry sources.
Labels