Hi everyone!
As a quite recently examinated CWDP I´d like to contribute to this tutorial collection with one of my favourite subjects in the book, WLAN Architecture. I´m also guessing this is a hot topic for many of us Aruba engineers who offers and deploys WLAN solutions to customers and are constantly faced with the choice of Controllers vs Instant.
So what is WLAN architecture?
Simply put I´d like to summarize WLAN architecture as the design of where different operations regarding the WLAN is performed. These decisions are to be made out of knowledge of customer demands and traffic patterns. In the book they talk about three working planes of a WLAN, they are:
Data plane
Management plane
- Configuration
- Firmware handling
- Monitoring
Control plane
- Dynamic RF
- Mobility/Roaming
- Load balancing
- Encryption/Decryption
- QoS tagging
- Data filtering
Centralized Architecture
Centralized architecture is where you offload these three working planes to a central location. In the book they refer to the sub types of it by using the terms “Remote mac”, “Split mac” and “Local mac”. To remember which is which, I find it easy to think about the mac functionalities as “remote” for me as a client is the controller and “local” for me is the AP. Split is of course split functionality between the controller and the AP.
There are many advantages of a centralized WLAN architecture. I´m going to give you an example of how easily we can leverage it in the deployment at a customer site.
This is a simple drawing of a customer that wants to implement WLAN in their existing building that only uses wire today. There are 500 users carrying 2 devices per person on average in this 7 floor building.
It´s a pain to create new WLAN client VLANs, distributing these to all the access switches, put the new VLANs on all the trunks, configure trunk ports for the access points making sure that the APs connect to correctly configured ports and then repeating these steps if the number of devices would to exceed the max clients of the VLANs.
In this picture we´ve decided to move in with a controller in the Core/Distribution layer and centralize the working planes there. This leaves us with a very simple overlay implementation where AP´s are connected to wired client WLANs, build their tunnel to the controller that will handle all data, control and management functionalities. New WLAN client VLANs are created and only put on the trunk to the controller.
The users will be able to roam freely between floors and enjoy the power of centralized mobility handling, encrypted data all the way to the controller and dynamically planned radio environment. For the administrators of this network, they have one single point of management, one place to troubleshoot WLAN issues and only one radius client had to be created for this.
Possible drawbacks of a centralized architecture:
Cost – controllers aren´t free, neither are licenses.
Latency and bottlenecks – If implemented incorrectly, tunneling can create detours and traffic jams.
Scalability – It´s hard to size the controllers for a customer who´s maybe going to grow their WLAN, but maybe not.
Single point of failure – To implement redundancy, put more controllers in.
Distributed architecture
Moving on to the distributed architecture, in Aruba terms Instant, we´re looking at something that looks like the old way of autonomous/fat/thick AP´s but in reality it´s far from it. Unlike autonomous AP´s a smart distributed architecture share control plane with their neighboring access points, enabling all the nice feature you´d expect from a WLAN controller, but distributed to Aps themselves. This is achieved by using inter-AP communication protocols.
If you´re deploying only one site with a distributed architecture, we could say that you are spreading out the “data plane” to all individual AP´s but keeping the “control plane” and the “management plane” common for all the AP´s. All mac functionalities are provided by each AP.
The true advantage of a distributed architecture comes when you´ve got multiple sites, maybe each have their own internet access, maybe there´s local resources to each site, maybe they demand local survivability. By deploying a distributed architecture in this scenario you make data forwarding local to each AP, control functionality local to each site and of course you want management plane offloaded to a central or cloud WNMS (Airwave or Central for example). By the way, distributed architecture is redundant by design! Here´s a design example for a company with many distributed locations, local resources and internet access:
Possible drawbacks of a distributed architecture:
More RADIUS clients – Each cluster or AP is typically a radius client that needs to be configured on the RADIUS server.
More switch configuration – You´ll need all the client VLANs on the AP trunk ports.
Shorter encryption – AP decrypts the traffic and puts in on the wire.
Final words:
Having all this said, I´d also want to add that many of the vendor implementations you find out there today can act as a hybrid between these two architectures. The most important thing is that you learn how to listen to your customers need and translate that into the best architecture for them. Keep your head straight when designing redundancy and local survivability, I´ve seen to many redundant networks fail because of bad design. Know who your radius clients are, who and where your radius servers are, who and where your DHCP servers are, and make sure those new client VLANs are created on all controllers/switches/trunk ports!
Best of luck to all of you passing the CWDP exam!