Tuesday, 24 April 2012

Decoding Cisco CAPWAP With Wireshark

Here's an interesting little gotcha I wasted a few hours on recently...

I have been looking at QOS on a Cisco WLC and was looking at DSCP markings in CAPWAP packets between a Cisco WLC and access point. I did this by spanning the switch port that the AP is connected to and then using a copy of Wireshark on another switch port to capture the traffic so that I could have a look through it.

However, when I looked at the CAPWAP frames, Wireshark was reporting most of the CAPWAP packets as being "Association Requests" and that they were "[Malformed Packets]".

After testing this in quite a number of versions of Wireshark (assuming a Wireshark decode bug), I finally gave up and reported a bug to the guys at Wireshark. They were incredibly quick to respond and diagnosed the issue very quickly!

It turns out that Cisco have not implemented the final draft of CAPWAP (according the guys at Wireshark), and that there is an option in Wireshark for Cisco CAPWAP support. You can it in the find the options panel at : Edit > Preferences > Protocols in the Wireshark GUI.

Select the CAPWAP protocol and check the 'Cisco Wireless Controller Support' check-box and everything decodes as you would expect :)

Thursday, 19 April 2012

Fast SSID Change - Out Of The Shadows

There are many configuration settings on a piece of networking kit that are just 'there'.

They sit there year after year just minding their own business being a quiet little chunk of configuration sitting in their default state not doing anyone any particular harm. Then, occaisionally, you come across some obscure case that causes you to actually pay attention to what exactly that particular setting is 'bringing to the party'.

One particular instance I came across recently is the 'Fast SSID Change' setting on a Cisco WLC.

From memory, it's been sat there for quite a while on many of the controllers I've installed, sitting dutifully in its default state of 'Disabled'. I've never really paid it much attention as it doesn't (on the face of it) seem to cause anyone any particular problems.

However, I recently ran in to a situation where a customer had some Apple iPads that he wanted to connect to an SSID that was mapped to an internal corporate VLAN. The iPads connected up quite nicely using PEAP - nothing too interesting there. However, the customer also wanted to flip an iPad or two across to the guest user SSID, which was mapped on to a completely different VLAN and anchored to a DMZ controller. The reason to flip between the 2 SSIDs was purely to carry out testing of the new wireless solution (i.e. corporate users with iPads and guest users with iPads).

The iPad was correctly configured for both SSIDs. To flip between the 2 SSIDs, we simply opened the network settings of the iPad and selected each SSID in the list of shown wireless networks. (For full disclosure, the iPad was running iOS 5.1.x, the guest SSID was brodcasting and the corporate SSID was set to not broadcast).

However, when I tried to flip between the SSIDs (e.g. guest SSID to corporate SSID), the iPad would attempt to connect to the newly selected SSID, but would fail and fall back to the original SSID that it was connected to. The real head-scratcher was that a smartphone correctly configured for both SSIDs switched between the two SSIDs back and forth with no issues at all!

After quite a bit of pondering and double-checking of the iPad wireless configuration, I decided to run a client debug on the WLC. The debug seemed to show that the iPad was associating with the newly selected SSID, but then reverted back to the original SSID before any authentication took place. I wasn't too sure what was going on...

After some digging around, I found a few Cisco forum posts talking about 'Fast SSID Change' which sounded like it might be related. Here is the description of the 'Fast SSID Change' parameter from the WLC help files:

"When you enable Fast SSID Change, the controller allows clients to move between SSIDs. When the client sends a new association request for a different SSID, the client entry in the controller connection table is cleared before the client is added to the new SSID.


When Fast SSID Change is disabled, the controller enforces a delay before clients are allowed to move to a new SSID."

So, I tried changing the 'Fast SSID Change' parameter to 'enabled' and suddenly the iPads were happily switching between the two SSIDs with no issues!

I'm guessing this was a timing issue on the iPads - I guess they weren't quite as patient as the smartphone.

The question remaining in my mind is this: why is 'Fast SSID Change' set to disabled by default? I wonder if there are any particular reasons you wouldn't want to just blindly enable it for every installation of a new WLC? (I haven't found any reasons to date...)

I tried to think of other scenarios where you may run in to this issue. It's hard to think of any beyond the testing scenario I described above, but I guess there will be one or two use-cases. I thought of something perhaps around a provisioning-type WLAN where maybe some type of client or agent is provisioned to an iPad and then you need to flip across to another SSID to use the new client or agent, but that was the best I could come up with.

I'd be interested to hear if anyone else has any good arguments for or against enabling 'Fast SSID Change'.

References:

Thursday, 12 April 2012

Cisco NCS 1.0/1.1 - Internet Explorer Chrome Plugin Gotcha

If you're like me, then when it's time to use or install a new release of software, you quickly scan through the release notes trying to make sense of the reams and reams of 'new features', 'caveats', 'bugs fixed' etc. without falling to sleep and smashing your nose on the desk in front of you. (Why can't technical writers give those things a plot, a love interest and a gripping ending..?)

The main purpose of this exercise is often to pick up the 'headlines' so that you can fairly comfortably install or implement the new software, armed with a reasonable amount of knowledge to allow you to not fall down any particularly large holes during the process.

One area I'm particularly guilty of 'glossing over' in this release-note-scanning activity is the section that describes the versions of browser support that are provided for web-GUI based products (e.g. network management software).

Sure, I give the browser support section a quick glance and verify that the usual suspects are there (IE, Firefox & maybe Chrome), but never really pay too much attention beyond making sure that there nothing too old there that may cause any issues.

However, I have fallen down a very large hole recently when it came to using Cisco's NCS. To make matters worse, I have to admit to having fallen down this particular hole twice.

The gotcha to watch out for is the browser support for both NCS version 1.0 & 1.1. If you skim the release notes quickly (like I did), then it's very easy to miss a very important piece of information. Here is the relevant extract from the NCS 1.0 & 1.1 release notes:

"The NCS user interface requires Mozilla Firefox 3.6 or later minor version and Internet Explorer 8.x with the Chrome plugin releases or Google Chrome 12.0.742.x. Internet Explorer 6.0 is not supported."

The important piece of information here is : "Internet Explorer 8.x with the Chrome plugin"

The "with the Chrome plugin" doesn't seem too important if you scan over it quickly. But, believe me, you don't want to ignore that particular phrase if your customer uses IE as their corporate-standard browser.

On both of the occaisions when I have installed NCS recently, the customer used IE as their standard browser, with strict policies restricting the download of plugins (or other browsers!). This meant that in both cases, we couldn't install the Chrome plugin. Believe me we tried (..and tried and tried!!!) But, the corporate AV policies wouldn't allow the installer to run as it looks like the Chrome updater, and, it has to have access the Internet to download updates & 'stuff'.

So, in both cases (after much embarrasment, head scratching and silent cursing), we had to admit defeat and get some change controls in place for special dispensation to install Firefox...which was very painful and took some considerable time.

Not having the Chrome plugin (which, incidentally, you can get from here: http://www.google.com/chromeframe) means that if you login to NCS using IE8 as an admin user, you have very limited GUI functionality. It sort of limps along and gives you access to a few features, but it doesn't take long before you're tearing your hair out with it as you find things that don't work.

If you login with a Lobby Ambassador account, things are even worse. Instead of being presented with the usual Lobby Ambassador GUI, you actually get to see a read-only version of the home page that an NCS admin would normally see! As, I said, it's a read-only version of the page, so there don't appear to be any security risks there, but it's weird (and totally useless) to login as a LA and see the usual NCS home page...

So, the key takeaway from this: don't fall down the NCS/IE/Chrome plugin hole that I did (twice). Make sure your customer is able to install the Chrome plugin before you start putting NCS in, or make arrangements to ensure they can use Firefox or Chrome as an alternative.

Finally, don't scan software release notes...(even if you spend hours and hours and hours reading them that could be better spent with family, friends and picking out those bits of fluff that seem to collect in your navel).

...anyone else remember suffering plugin issues with other Cisco NMS products - dare I mention Java..?

References: