Hallway Design Nightmares Part2: TXPower

One of the effects of the hallway design is that Radio Resource Management (RRM) frequently doesn't work as expected.  It's not that it doesn't work, it's just that hallway designs significantly limit the perspective of how APs see each other, which is primarily how RRM determines what it should be doing.  Given that all the APs in the hall generally see each other at or about the same level, they all have a very similar view of the network.  For illustration purposes, I've mocked up an imaginary residence hall.  A specific hall that I visited recently was build with concrete walls.  We will talk about some of the things I saw, and how they apply to this generic sample floor.

For this example, I've place 3 APs where the black dots are.  Let's also assume that this is the 2nd floor in a 3 story building.

Hallway Design Nightmares Part 1: Introduction

A lot of people know that Hallways designs are a bit of a pet peeve of mine.  My opinion is that they do not work, and beyond moving the APs out of the hall, you cannot fix them.  But the reality is that moving APs and existing infrastructure can be really expensive, time consuming and difficult to get management to buy off on.  This means that you probably will have to live with some of your existing hallway designs for the foreseeable future.

In this series, my aim is to explore the options available to improving performance of a hallway design.  As an engineer working for a Cisco Gold Partner, I'm going to talk about some of the tools available in the Cisco Unified Wireless Network (CUWN) to help deal with these designs.

I'll leave this short intro post with the following advise:

Don't put APs in the hallway.

Put APs as close to clients as you can get them.

Think about how RRM works, and incorporate that into your designs

Don't put APs in the hallway, PLEASE!

Aerohive Hivemanager: A System of Control

So you will never win an argument with an @Aerohive agent employee about controllers.  I've discussed with them how there are some things (a lot really) that HiveManager does that is a function that controllers do.  "Management Plane!" they scream in unison.  No-one who has faced an @Aerohive agent employee with the word controller has lived.  We are survived by not mentioning controllers around them, but sooner or later someone is going to have to fight them.

Well, this isn't the matrix Neo, but what @Aerohive does with their HiveManager product is implement a system of control.  That system is designed to turn this:

into this:

*EDIT: This is a joke. I'm not saying that HiveManager is a WLC.

---

Poor Abby, she gave me lots of fodder with her recent blog : What Is a WLAN Controller

It's a good article, well written and she articulates her point clearly, although I don't agree with most of it.  Please don't take this as an attack on your blog, but I think that the good ol' WLC will be around for a long time no matter how much the cooperative control marketing gets thrown around.

But Abby does try to define exactly what a wireless LAN controller is.  Something I challenged her to define.  And I did warn you #ItsATrap

Oxford Dictionary:

She goes on to define what she calls a wireless LAN controller, but i think she misses a lot.  Her definition is: "A wireless LAN controller is a device that directs or regulates traffic on the wireless network..."  I'm truncating her definition.  Not because I want to be snarky, but because you cannot define a WLAN controller by a vendor that sells WLAN controllers.

I actually find her definition pretty weak.  A WLC does a LOT more than directing and regulating wireless traffic.  I would say a better definition would be "A WLAN Controller directs or regulates the operation of a Wireless LAN."  While the distinction is small, a WLC is much more than the regulation of wireless traffic.  You could even say that a WLC is a collection of multiple "System of Control." A WLC also regulates what a wireless AP can or can't do based on its features. I'm going to take a discussion that I've had with Abby and other @Aerohive guys around their BR series of routers/APs.

Did you know that a BR200 can operate as just an AP/Switch?  Bet you didn't.  That's because it isn't supported by @Aerohive.   Now the BR100 does this and is supported.  So what I did was take the config that my HMOL pushed down to my BR100 (Thanks @Aerohive for providing me with one for attending #WLPC) and applied those same commands to my BR200 and Voila, an AP with a swiitch.  All the commands are documented in their CLI Reference guides http://www.aerohive.com/support/tech-docs-and-online-training but they are supposedly not supported because HiveManager does not support this on the BR200 platform.

The moral of this story is that HiveManager, a supposed "Network Management System" regulates what an AP can or can't do.  I would say that it is not a NMS because it regulates and/or directs what can or cannot be configured on the equipment.  And once you configure things via the CLI, 

forget about managing it with HiveManager.  Especially if you configure something that isn't possible with HM.  Here's another example:

When trying to configure a port-forward on a BR200, I ran across the limitation that HMOL will only allow you to forward a port that is directly connected to the BR200 (the BR200 is the L3 interface for).  I was trying to setup connectivity from my BR200 over to my home lab, and wanted to forward a port across a L3 routed link to my console server.  No dice, HMOL pukes when trying to configure this.  But if you configure the port-forward from the CLI of the BR200, it works, and works well (although likely unsupported).

There you have it, HiveManager, while not a controller, is certainly a system of control.  I'll tell you something else, even with a WLC not always do you "HAVE TO" have a NMS.  I can deploy a WLC in a small network and configure and operate it without deploying the NMS.  And while I'm sure you *could* deploy @Aerohive gear without HM or HMOL, it would be easier to try to rescue Morpheus from a military-controller building being held by three agents.  I believe even the @Aerohive team-members would suggest spinning up a temporary version of HiveManager to get the initial config implemented.

P.S. Please don't take this as "I don't like Aerohive equipment."  The hardware is what you would expect from an enterprise equipment manufacturer.  It's been great in the lab and my 330 has been driving my wife's wireless network for over a year with very few issues.  The BR200 and 100 have been also been good, but the lack of support in HMOL for features has left a bitter taste in my mouth especially around HiveManager.  I really think @Aerohive needs to take a hard look at Hivemanager and follow the philosophy of "As simple as possible, but no simplier."  Right now, the biggest thing holding back @Aerohive is HiveManager.

*Edit:
After a lengthy and good discussion on twitter, I thought i would clarify that I'm not saying that HM is a controller.  It is fun to make correlations between HM and functions that common WLCs perform.  When I say control, I do not mean a control plane.  I just mean that the HM exerts control over the equipment.  While it doesn't participate in the control plane, limiting what you can do on the equipment in my book is defined as control.

Evernote helps you remember everything and get organized effortlessly. Download Evernote.

CCIE-W: QoS Study Notes

I've had some people suggest that I should post more of my study notes.  QoS is one of those black magic topics that I really do need to understand more of.  I went through with one of my co-workers who gave me the Catalyst 3750 QoS in 30 lecture.  Between that and some of Jerome Henry's QoS videos on youtube, here the basics on QoS.  So here are my notes in all their ugly glory.

One week to the CCIE-W lab, An approach

So in just over a week I will make my way to lovely San Jose to take my first attempt at the CCIE Wireless lab.  Sure it's a long shot passing on a first attempt, but even a failure at this point will give me the experience of "The Lab" and help point my studies in the right direction.  Not to say that I'm not going to give it my all, but I also don't "expect" to pass.

I'm currently going through the Fastlane lab material, and a lot of configuration guides and implementing them in my home lab.  I feel ok about the material.  I wish I had more time to to cover topics like MSE and WIPS, but I decided to go ahead with the lab on a short timetable.  At this point I'm looking more at SWTs (Stupid Wireless Tricks), learning some lesser known CLI commands and building a strategy for dealing with problems in the lab.

My focus for skills building is moving away from the simple "How Do I?" to more of a "How Do I Verify?" or "What is the quickest way to configure feature <x>?"

5760 Session Timeout: To Infinity and beyond!

If you're familiar with the advanced tab while configuring a WLAN  on a Cisco (Airespace) WLC, you've probably seen the Session Timeout checkbox and corresponding timer value.

This timer is used to setup how long a wireless user can remain connected before reauthentication is required.
While deploying a 5760 to match an existing 4400 controller, I attempted to disable the session timeout, but to no avail.  Let's look at my simple WLAN I have configured: