Cisco WCS Issues

March 1, 2013 at 11:12 pm Leave a comment

WARNING:  Very technical (but short) article follows that deals with the inner workings of a little documented file used in Ciscos WCS.  If you don’t already know what WCS is, you should probably stop reading now, as the rest of this article won’t make much sense.  I’ve most written this post to document this for myself, but if there’s anyone else out there that this helps, then that’s a bonus.

Cisco WCS (Wireless Control System) is a system used to manage WLCs (Wireless LAN Controllers).  A WLC manages access points.  So, WCS is basically a software package that manages devices, which in turn manage access points.  The APs don’t need any individual config on them, as they get everything they need from their WLC.

We’ve been running the latest edition of version 6.0 for quite some time.  It works beautifully.  Our routers are configured to hand out a special set of DHCP options just for WLCs, which we can do because there is only one per remote site.  The vendor class ID of the WLC is inspected by the router, and if it’s found to be a WLC, the scope using the special options is used.  These DHCP options allow a brand new WLC to be unboxed and plugged in with no pre-configuration.  DHCP will point it to a good startup config from the WCS server, after which it will pull all the appropriate templates that are configured in the config group it is part of, using a feature of WCS called AutoProvisioning.  This has worked beautifully for several years, applying about 25 templates to each location, adding settings such as WLANs, Radius servers, NTP and Syslog, and much more.  This makes for super easy new installations, not to mention replacing WLCs.  No need to pre-configure the hardware.  Just unbox it, plug it in and go.

Recently, we found that the Cisco 2106 WLC has been discontinued, which is what we have in more than 500 sites.  Since we are adding 200 sites, we’d prefer to use the same model, but they have been replaced by a newer model, the 2504.  It supports a maximum of 5 APs (verses 6 of the 2106) and it has only 4 ports (verses 8 of the 2106), but otherwise it has at least the same capabilities.

Unfortunately, the 2504 requires WCS version 7.0 at a minimum.  Cisco has versions of firmware that are 7.2, and 7.3, etc, but those won’t work with WCS.  Cisco moved to NCS (Network Control System), and as of the latest version they’ve changed the name again.  Furthermore, NCS and later are virtual appliances, so you can’t run it under your own Windows server, as you could with WCS.

Anyhow, we set out to test things.

Our test system was upgraded to version  After performing numerous tests, we found that WCS version 7.0 has some issues.  (We tried also, same issues)  It didn’t matter if the WLC was running the matching firmware, or even back on a 6.0 version of firmware, the same problems exist.

1. The AS_4200_startup.confg xml file is really a template that forms the basis for each -confg file that gets generated by WCS using the AutoProvision filter.  It has a username embedded within it, along with a password.  Unfortunately, the password didn’t work for the 2504.  I found that you can export a config from a WLC with a password set, then replace the contents of the <iv>, <mac>, and <passwd> fields within the AS_4200_startup.confg xml file and then the 2504 will work with the password you set.  Unfortunately, that password won’t be properly decoded by a 2106 that’s loaded using this xml file.  This is really more of an annoying issue, but still a problem.

Fix A:  The password store defaults to a ps_type of PS_STATIC_AES128CBC_SHA1.  This can be changed in the xml config template to a type of PS_NULL_NULL_NULL, and the <iv> and <mac> tags can be deleted.  Then, take your password, convert it to hex, and place that in the <passwd> tag, and set the <passwd_len> tag to the number of characters in your password.  Note:  Don’t change the number of characters in the <passwd> tag.  It’s padded with 0’s.

Note: The above fix isn’t the most secure way to handle things, but it will allow two different versions of WLC hardware to use the same username and password, as passed in this file.  You should not do this at all if your WCS server is listening on a public IP for TFTP traffic.  If it’s publicly available via any insecure protocol like TFTP, someone will probably find it sooner or later.  Whether they’ll know how to exploit what they find is another question, but it’s best not to leave that to chance.

Fix B: Another, more secure alternative, is to set the password in your xml template file to be one that will work on 2504s, since that’s probably what you’ll be installing, and place another username and password in a WCS template that gets applied when the device gets provisioned.  That way, you’ll have a local user on 2504’s and once installed, you’ll have a local user (applied via WCS template) that will work on either model.

2. ACL templates are not properly pushed when autoprovisioning a WLC.  Note that if you go to the Config Group page, and do an “Apply”, the ACLs will typically get applied properly, but this is a manual process, and we want it to be completely automated.  The problem is that after a WLC comes online and gets everything applied by WCS, all ACLs that we pushed via template exist in name only.  All the individual ACL rules are missing.  This also means that any WLANs that use this ACL won’t be added, since the required ACL isn’t complete.  This is a major problem.

Fix: After much experimentation, we found that if you manually add the ACL names to the xml config template file, they will be in place when the WLC completes it’s boot, before being added to WCS.  WCS will then see the ACLs there, and will populate them with the appropriate rules.  Here’s an example:

In the <ACL-Configuration> tag, add a new section like so:

<aclTable index=0>
<ACL-name>Your ACL name here</ACL-name>

Make sure that “Your ACL name here” exactly matches the ACL name in WCS.  If you have multiple ACLs to add, copy and paste the above in multiple times, incrementing the index each time.

NOTE:  When we ran across these problems in our testing, we dropped back to the original AS_4200_startup.confg file.  It didn’t help.  We even dropped back to a 6.0 release of WCS, validated that we could get it working there, then upgraded to a 7.0 release and repeated the same process, to find that it failed.  These are definitely deficiencies in WCS.  It is possible that the password thing was a design decision they made, but the ACL issue?  Inexcusable!

Anyhow, those are the two problems we have found, and some workarounds.  We have upgraded our production system and have one 2504 that we’ve autoprovisioned using WCS with our modified xml template.  It worked just as well on the two 2106’s that we’ve loaded through this new version.   I expect that we will be rolling out the new 2504’s to remote sites within a month.



Entry filed under: Networking. Tags: , , .

My DIY Fusion Drive Follow-up Synology DSM 4.2 is out! Radius Alert!

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


March 2013
« Jan   Apr »

Most Recent Posts

%d bloggers like this: