Get your attention yet? This isn’t fresh news by any stretch, but there are some good concepts to observe when deploying today’s controller-based WLANs. We have known for years the benefits of the typical controller-based wireless networks. The intelligence that the controller has of the access points (APs) and the ability to dynamically change channels and power outputs is obviously fantastic. Depends on the manufacturer as to what they call it – Radio Resource Management or Adaptive Radio Management etc. Either way, it’s one of the main reasons to go to a controller-based solution.

On top of this we also can get Layer 3 roaming capabilities. A typical controller-based solution has each individual access point create a tunnel back to the controller. In a lot of cases this gives you the ability to roam between L3 subnets. Consider a scenario where you have a corporate campus – there very well could be a voice and a data VLAN per closet. If the access point didn’t tunnel back to a controller we would potentially drop sessions (unless you extended a wireless VLAN across campus which has its own implications) when you went from one AP on one subnet to another AP on a disparate one. Often, this may not be an issue with some standard TCP applications – but if we are talking about time-sensitive applications such as voice this could be disastrous. If we have a tunnel from each AP to the controller, we can now set up Layer 3 roaming capabilities without having to create a sprawling wireless VLAN. Voice connections stay up and all is good – right?

So what happens if we have a situation – let’s call it a remote office without a controller – where you want to keep local traffic local, but tunnel the rest of the traffic back to a controller at the Data Center. If we stick to the newer model, all traffic gets directed to the controller via the tunnel. Kind of seems pointless for me at a remote branch sending a print job back to the Data Center and then back to the remote office to the printer next to me right? Many companies now are allowing their controller-based solutions to “hairpin” local traffic to keep it local rather than waste valuable bandwidth. This hybrid or HREAP type approach does in fact give us the ability to glean the benefits of both the centralized intelligence of the controller, but also can minimize the bandwidth burden that these tunnels take up. If it’s meant for the Data Center so be it; if it’s meant to remain local we can do that too. If the remote office is large enough to warrant its own local controller then that is a different conversation – until next time.

If you're interested in learning more about our Networking Practice, fill out the following form [gravityform id="15" name="Networking Form"]