Home > 802.11n, Cloud computing, WiFi Access > Is your cloud Wi-Fi genuine, or is it controller over WAN imitation?

Is your cloud Wi-Fi genuine, or is it controller over WAN imitation?

November 7th, 2012

With rising popularity of the cloud Wi-Fi in the distributed Wi-Fi deployments, there is also an attempt to pass off the legacy controller technology as the cloud Wi-Fi by deploying conventional controllers over the WAN. Realizing that it is infeasible to deploy many smaller controllers in the distributed Wi-Fi deployments such as retail, remote offices, etc., the controller over WAN architecture deploys bigger controllers at the HQ and calls it a cloud Wi-Fi. However, the controller over WAN Wi-Fi does not measure up to the true cloud Wi-Fi for many reasons as outlined below. We will use example of Cisco’s controller over WAN architecture to illustrate these differences. Earlier, Cisco called it H-REAP and ELM, now it calls it FlexConnect, but does changing terminology get controllers to measure up to the true cloud? Let us find out.

Equipment deployment and management overhead: True cloud Wi-Fi relieves the enterprise IT from the overhead of deploying and managing excess equipment. In the controller over WAN architecture however, enterprise IT is responsible for deploying and maintaining controllers at the HQ. For high availability, it is required to deploy redundant controllers. Additionally, if the controller-based architecture is multi-layered such as controller layer, services layer and console layer as in the case of Cisco FlexConnect example, the equipment overhead occurs at multiple layers of the architecture.

Dependency on the health of the WAN link: To cite an example, Cisco’s deployment guidelines for the FlexConnect recommends reserving 12.8 Kbps WAN bandwidth with 300 ms round trip guarantee between each remote AP and the HQ controller for CAPWAP control messaging (for data+voice, it recommends 25 Kbps with 100 ms round trip guarantee). This bandwidth is presumably required to support delay sensitive and continuous “chatter” of control messaging occurring between the remote AP and the controller. The more the chatter, the higher the chances of service degradation due to problems over the WAN links. True cloud does not require any bandwidth reservation thus making it much reliable compared to the controller over WAN.

Lost access functionality at the edge: Controller over WAN Wi-Fi offers degraded functionality when the WAN link is down or when the controller fails. For example, careful review of the FlexConnect user guide reveals that when the controller fails or when the WAN link to the controller is down, remote FlexConnect APs turn off important access services. For example, they turn off guest WLANs as these guest WLANs require functions such as click-through splash page, sign-on splash page and redirection; which need controller co-ordination. On the other hand, true cloud Wi-Fi does not have such controller dependency, so access services will be up independent of what happens to the branch connectivity to the HQ.

Security failure at the edge: Controller over WAN Wi-Fi can drop security cover if the WAN link goes down or the controller stops running. In the FlexConnect example, the entire security cover (which is weak to begin with, but still) evaporates if the FlexConnect AP loses connectivity to the controller. That includes IDS, IPS, rogue detection, and PCI. With the true cloud, APs are built as intelligent devices which maintain the security cover even when they are not talking to their cloud manager. In the true cloud architecture, security at the edge is not degraded when APs lose contact with the cloud manager.

Complexity of configuration: Force-fitting controllers into the cloud results into complex and error prone network configuration and management. Network admins have to work with distinct silos of configuration domains such as controller groups, mobility groups, AP groups, FlexConnect groups, and WLAN IDs; and cross referencing among them. True cloud, on the other hand, offers intuitive web based console with elegant configuration and network management workflow which directly relates to the way network is organized from functionality perspective and not controller perspective. While superior user experience is difficult to describe in words, it becomes instantly apparent as soon as the controller over WAN configuration interface is viewed side by side with the true cloud Wi-Fi console.

All this shows that true cloud Wi-Fi is not about throwing controller over WAN link. There is large gap in benefits achieved between the genuine cloud Wi-Fi and the controller over WAN counterfeit. Cloud Wi-Fi is a different architectural thinking to enhance simplicity, reliability, and economics of Wi-Fi deployments. We at AirTight Networks have been innovating and supplying solutions based on the true cloud architecture since 2008. AirTight today offers controller-less Wi-Fi access and security with the true cloud architecture with smart, service-aware APs/security sensors at the edge, with option to have the cloud manager in the public cloud or the private cloud.

Hemant Chaskar

Hemant Chaskar is Vice President for Technology and Innovation at AirTight. He oversees R&D and product strategy for AirTight Wi-Fi and WIPS; and also performs roles in technical marketing, business development, and customer facing activities. Hemant has worked for more than 14 years in the networking, wireless and security industry, with 9 years in Wi-Fi. He holds several patents in these technology areas and has Ph.D. in Electrical Engineering from the University of Illinois at Urbana-Champaign. Follow on Twitter @CHemantC.

Twitter 

802.11n, Cloud computing, WiFi Access , , ,

Comments

  1. Andre
    January 21st, 2014 at 18:56 | #1

    Saying Cisco is pushing Flexconnect as “Cloud” is at best inaccurate. Cisco is pretty clear that Meraki is their cloud offering and that controllers are their on-premise model. They actually work hard at differentiating the two.

    Other vendors are another story …

  1. November 28th, 2012 at 19:16 | #1
  2. February 10th, 2013 at 12:07 | #2
  3. February 10th, 2013 at 17:46 | #3
  4. April 10th, 2013 at 12:02 | #4

Your email address will not be published. Required fields are marked *