GreenPages Blog

As an IT professional, you need to stay current on all things tech; with articles from industry experts and GreenPages' staff, you get the info you need to help your organization compete and succeed!

Optimizing Controller-Based Wireless LANs with Good Old-Fashioned Autonomous Concepts. Well – Kinda.

Posted by: GreenPages Blog
Read More
All Posts

Optimizing Controller-Based Wireless LANs with Good Old-Fashioned Autonomous Concepts. Well – Kinda.

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"]


Related Posts

Whose Job Is It Anyway? Microsoft, You & the Shared Responsibility Model

Many organizations have moved onto Office 365 and assumed that “Microsoft has got this.” No matter what SaaS-based platform you’re talking about, there will almost always be an expected shared responsibility to take care of and protect your data.

Tech News Recap for the Week of 06/22/20

If you had a busy week and need to catch up, here’s our recap of tech stories you may have missed the week of 06/22/20!

Public Sector: How to Leverage Funding from the CARES Act to Enable Your Employees & Communities

What Is the CARES Act? The Federal government enacted the Coronavirus Aid, Relief, and Economic Security Act ("CARES Act") which established the Coronavirus Relief Fund and appropriated $150 billion to it.