Why Can’t I Contain?! (Part 1 of 3 on Containment)

Disclaimer – Containment is a very serious topic and can have legal and financial consequences.  You should never contain any APs that are not your own unless they are a security threat, like spoofing your SSID or a rogue ap attached to your network.  The spectrum allotted for use by the fcc is not licensed and therefore anyone is free to use it as long as they are within the bounds of the fcc regulations.  Marriott was nailed for doing this in their hotel a few years back – see here.   


As I am sure most of you are aware, sometimes crap just doesn’t work when you are trying to set something up.  I had the idea of doing a blog post on containment for a while and so I was setting up the lab at home to test with.  But no matter how hard I tried I couldn’t get my APs to contain each other.   I was limiting the containment to a specific SSID to avoid causing disruption to family and neighbors (and to avoid any legal issues).  I tried getting my Aruba APs to contain my Meraki and Cisco APs, Meraki APs containing my Aruba and Cisco APs, and my Cisco APs containing my Aruba or Meraki APs.  Nothing worked!  None of them would contain the other and it was pissing me off!

I had set up a quick test a few months back and it worked great, so why was this not working?

In my Cisco 2504 controller when I would set the SSID to contain, the response on the WLC said Containment Pending with a message stating “No AP’s available for containment.”  I had up to three APs running on monitor mode and it still wouldn’t do it.  They would see the AP and classified it, just wouldn’t contain it.

My Meraki APs would list the SSID as “uncontained” and never switch to “contained.”  I had one MR32 with a dedicated radio that should have done it, and another MR24 set to Air Marshal mode also.  Still nothing.

The Aruba (Instant) APs would tell me nothing.  Once I set the AP in monitor mode and the SSID to containment, it just sat there.  Now full disclosure, I am not very savvy with Aruba so it may have actually been telling me more but I didn’t know where to look.  But according to the packet captures, it did nothing.

When I set up the test I was using only 5 GHz and statically assigned the channel I was using to 100 as it was clean and I wanted to avoid impacting anything around me.  I set up an SSID called PleaseDontContainMe to broadcast and then connected a few devices to it.  I would set up a packet capture using Omnipeek and then set the APs to contain and watch for the containment symptoms to show up (see my next blog post for details on that!).

I tried different code versions on Cisco and Aruba, and even Meraki (I had an upgrade pending) but didn’t get anywhere.

Some of you more savvy/experienced/smarter engineers than I may have already identified my issue.  Apparently APs will not perform containment on any DFS channel!!!

I tested both channel 100 and channel 60, and no containment.  So it is not limited to U-NII 2 extended, but impacts all U-NII 2 channels (52-144).  As soon as I moved to channel 161, containment away!  I didn’t test all of the U-NII 2 channels, but can assume I would get the same results on the rest of the channels in the U-NII 2 range.

The reason for this obviously has something to do with the DFS requirements for radar energy detection.  Specifically I don’t know why, maybe an AP when doing containment isn’t built with the intelligence to check or listen for radar? If you know why please let me know.  Or send me to the documentation that explains it.

It does bring up an interesting security risk.  If you are attempting to do something malicious, like spoof an SSID to perform a man in the middle attack, or place a rogue AP on the network, choosing a DFS channel to broadcast on would prevent any containment methods from interfering.  The business or entity would have to utilize other methods to mitigate those threats.  Either manually/physically tracking them down to remove them, or in the case of the rogue AP on the network, some kind of port trace to disable the switch port.

Interesting stuff!  Now, on to the blog post I was trying to do to begin with…