Old School Cisco Wireless - 2106 AP Cert Expired; Interfaces

A quick note because I've been doing some work with an old 2106 WLC and 1142 APs. Crazy old I know, but I wanted to see the differences between a physical controller vs. vWLC and I couldn't afford a 5508 and unless anyone at Cisco stumbles across this and wants to send me a 9800 + 9100 AP then an 2106 is what I'm currently stuck with :)

It's setup in a similar way to the vWLC, unsurprisingly, but there's a couple of little quirks because I'm using an older controller that I've picked up and I want to record them.

1) Factory installed certificate expired. The factory installed certificate on the controller expires, stopping APs from joining to the controller.

There's a command to override this, but it didn't seem to work for me, so the easy fix is to turn the WLC clock back a few years. Obviously not a production fix but for my initial labbing, no issues.

2) Management Interface vs. AP Manager

I assumed, wrongly that the AP manager was the IP address to use in the DHCP option 43, however, that's not the case, it's the management interface just like the vWLC. But, worth noting, you still need the AP manager interface on these older controllers, and it must be reachable for the APs. Seemingly it manages DTLS connections between the AP and the WLC. When I removed the AP manager VLAN, thus making the AP manager address unreachable, the APs would cycle through the DTLS connections timing out and then retrying. Once the AP manager VLAN was re-added, the AP connects and registers with the controller.

Cisco vWLC deployment in ESXi 6.5 Bug - "A required disk image was missing"

A marginal side track but still semi-relevant...

I tried to deploy an OVA file of the Cisco virtual WLC (vWLC), and I've tried a number of the versions and I keep getting the same error... - A required disk image was missing

After a little googling it appears to be a known bug, Cisco vWLC doesn't like being deployed on EXi 6.5 via the ESXi web interface. There seems to be 2 workarounds:

• Deploying via vCenter web client
• Using the OVF tool

I've tried the installation via the vCenter web client and I can confirm this works fine. I've not been able to try the OVF tool yet.

Bridging Cisco Wireless Router to an AP (Or your Phone!!)

Doesn't it just feel great when you figure something out after being stuck on something for a little while? This was one of those moments...

I'm going through the motions for building a portable lab whereby I can test various applications and software and features and one of my initial considerations was how to get Internet access to the lab. I've got a 1841 with a 3G HWIC module inside it so I could buy a sim and configure that but the plans for 'non-mobile' devices are crazy expensive, plus I'm already paying for an unlimited internet package for my phone so it just feels wrong spending more money. The other option is tethering the phone to the LAN in some way - either via a USB to RJ45 adapter (but then I can't charge and tether my phone at the same time) or 2ndly some way wireless-ly, and it turns out this is very possible with a feature called universal client mode.

Universal Client Mode allows the router / AP to connect to a wireless device as though it was a client, very cool! So I able to use the portable hot-spot functionality of the phone, and connect to the phone from the router as though it was a client, below is a rough diagram of the setup:

"Free" access for my Lab.

So now here's the important bit, the configuration. I couldn't find any other bogs etc where people have done this, there are similar things but not exactly this and as such I spent some time figuring this out so I'm putting it here for future reference, and hopefully it'll help someone else out in the future.

! first of all you need to configure the radio:
interface Dot11Radio0

! Tells the router to act in universal client mode

station-role non-root 

! Set the IP address to be obtained using DHCP
ip address dhcp

! create the ssid - has to be the same as the ssid advertised from the phone
dot11 ssid SSID_NAME

!set the authentication - I've used open
authentication open

! Go back into the dot11 radio interface and associate the ssid to the interface
interface Dot11Radio0
ssid SSID_NAME

At this point you should have a virtual-dot11radio interface configured and it should receive and IP address from the phone.

And from here you just create a default route, setup NAT and "jobs a good 'un".

A couple of notes: you have to make sure there is no vlan X command because Universal Client Mode needs to use the native vlan (I.E. no vlan configured)

Also, when I added the default route I had to manually set the IP address of the phone I.E. 192.168.43.1 (in my case) it didn't work when I set the exit interface as either dot11radio0 or the virtual-dot11radio0. I don't know why, perhaps someone can comment? But that's well worth noting.

Excellent!

Here's a quick update, if you are not happy without any encryption you can add WPA2 encryption with a Pre-Shared Key (PSK) with these commands:

!Under the dot11 SSID config:
 authentication key-management wpa
 wpa-psk ascii 0 password

!Under the dot11radio interface:
encryption mode ciphers aes-ccm


!!Update number 2!!
So I managed to break my NAT translations, I was playing with settings and "cleaning up the config" and I noticed that my lab VMs had lost internet connectivity.
I've since fixed it but my method is not 100% conventional. I had to change my NAT statement to refer to the pool of IP addresses being translated rather than the exist interface (virtual-dot11radio0) for some reason my NAT statement and default route doesn't work if I point to the virtual-dot11radio0 interface. The simple fix is to use the IP address rather than the interface but I'm a little wary because IP addresses can change. We'll see, if I find away around this I will update again. Anyway for the time being, here are the revised NAT statements:

ip nat pool NAT-POOL 192.168.43.183 192.168.43.183 netmask 255.255.255.0

ip nat inside source list PERMIT-NAT pool NAT-POOL overload

ip access-list standard PERMIT-NAT
permit 172.16.213.0 0.0.0.255

Cisco MSE Appliances need L2 adjacency for HA operation

HA is a wonderful thing for obvious reasons but you do have to tread carefully sometimes when designing and deploying it.  I am specifically referring to the appliances / applications themselves and their physical location. Some appliances need to be located on the same subnet, which usually means physically very close. You can often fudge this by extending the layer 2 domain (such as using OTV) but this can be dangerous due to latency etc which can cause some unpredictable results, and not always practical.

MSE (7.4) is one of these applications. It maintains a health monitor connection to keep the two appliances synchronised and up to date.

Webinar: Cisco Wired and Wireless Convergence and Mobility Architecture

Here's a WebEx meeting I found tucked away and thought I'd put it up.

recording links are below, CCO login required:
WebEx recording: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00052036
PDF: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00052035
MP4: http://tools.cisco.com/pecx/login?URL=searchCourse%3FcourseId%3D00052037

Cisco 3850 Directly Connected APs Only

The 3850 switches are part of the converged access solution by using the embedded controller to terminate CAPWAP tunnels on the switch itself. One note which perhaps is obvious to someone else but wasn't to me is that the AP must be directly connected to the 3850 switch, you cannot have another switch in the way.

I queried this with Cisco and they said it was a software decision not a hardware limitation, so maybe it could change but at this point in time that doesn't look likely. 

While I'm on the subject of 3850s, a new release of code is out which brings the features more in line with the 3750X. Still not exactly there but better:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3850/software/release/3se/release_notes/OL_30562_01.html

References:

Cisco Unified Access Technology Overview: Converged Access Whitepaper

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/white_paper_c11-726107.html

Cisco Wireless Bits Worth Knowing: Beamforming

Here are a few wireless Tidbits I want to get down so I remember them later:

Beamforming:
Beamforming creates a stronger signal for downstream clients by noticing the client and adjusting the transmitter timing so that the signal appears stronger to the client. This is also known as Cisco clientlink. Clientlink 1.0 is used for abg devices, clientlink 2.0 is for 802.11n devices using 1,2 or 3 spatial streams.

This feature was configurable in pre 7.2 releases of code but from 7.2 onwards it is on by defualt and cannot be disabled as there would be no advantage to doing so.

Clientlink is a Cisco standard, there is an 802.11n enhanced beamforming specification but it is not as mature and feature rich:

This table is taken from the Cisco 166/2600/3600 deployment guide, link below.


References:
1600/2600/3600 deployment guide:
http://www.cisco.com/en/US/docs/wireless/technology/apdeploy/7.5/Cisco_Aironet75.pdf

Juniper WLC2 / MXR2 & WLC8 / MX8 different revisions and MSS

Here is an issue I bumped into whilst working on Juniper WLAN implementations. The scenario is that a customer has multiple Juniper WLC2 Wireless LAN Controllers, many of which they purchased before Juniper acquired Trapeze networks. This means they are actually MXR2s and some were quite old.

Now the WLC has now been called EOL (as of 4th October 2013) so it is not the best platform for use going forward, however at the time it was still a current product, and in honesty how many customers do you know who throw away hardware as soon as it's called EOL? Not many that I know, hardware is sweated until the end of support date gets too close for comfort and then the upgrade happens.

Back to the story, the newest Juniper APs, such like the WLA322 require a minimum of MSS 7.7 to work. The WLC2 technically supports MSS up to version 9.0, however the gotcha here, which is stated in the release notes, is that the Hardware revision must be at least "revision P". Here is the note from Juniper:

Warning: This release of MSS no longer supports older MXR-2, MX-8, and MX-8R WLAN controller platforms
that were initially built with 32MB of flash. Newer models support 128MB or 256MB. The best method for
determining if your controller can support MSS 7.7 is by checking the revision label on the unit:

• Models MX-8 and MX-8R controller - Revision "P" and above
• Model MXR-2 controller - Revision "N" and above
• All Juniper-branded equivalents will support MSS 7.7.

Please note this appliease to the WLC8 /  MX8, as above.

There is a free upgrade program with Juniper, as long as your device has a valid support contract, whereby you can RMA your older revision with Juniper and they will send you a newer version, however this is an RMA so can take a good amount of time, be aware.

To help myself I've put together a quick table showing WLA, WLC and the various MSS version supported:

	7.0	7.1	7.3	7.5	7.6	7.7	8.0	9.0
	Access Points
WLA632	N	N	Y*	Y	Y	Y	Y	Y
WLA532E	N	N	N	N	N	N	Y	Y
WLA532	N	N	N	N	Y	Y	Y	Y
WLA522	N	N	Y	Y	Y	Y	Y	Y
WLA322	N	N	N	N	N	Y*	Y	Y
WLA321	N	N	N	N	N	Y*	Y	Y
MP-432	Y	Y	Y	Y	Y	Y	Y	Y
MP-422B	Y	Y	Y	Y	Y	Y	Y	Y
MP-371	Y	Y	Y	Y	Y	Y	N	N
MP-372	Y	Y	Y	Y	Y	Y	N	N
MP-352	N	N	N	N	N	N	N	N
MP-341	N	N	N	N	N	N	N	N
MP-262	N	N	N	N	N	N	N	N
MP-252	N	N	N	N	N	N	N	N
MP-241	N	N	N	N	N	N	N	N
MP-82	Y	Y	Y	Y	Y	Y	Y	Y
MP-71	Y	Y	Y	Y	Y	Y	N	N

7.0

7.1

7.3

7.5

7.6

7.7

8.0

9.0

	WLC
vWLC	N	N	N	N	N	N	N	Y
WLC2800R	Y	Y	Y	Y	Y	Y	Y	Y
WLC880R	N	N	N	Y	Y	Y	Y	Y
WLC800R	N	N	Y	Y	Y	Y	Y	Y
WLC200	N	N	Y	Y	Y	Y	Y	Y
WLC100	N	N	N	N	N	N	N	Y
WLC8	N	N	Y*	Y	Y	Y	Y	Y
WLC2	N	N	Y*	Y	Y	Y	Y	Y
MX8R	Y	Y	Y	Y	Y	Y*	Y*	Y*
MXR2	Y	Y	Y	Y	Y	Y*	Y*	Y*

The Stars here show where minimum software versions or hardware revisions are required. Check the release notes for full details.

References:
Juniper MSS 7.7.4.4 release Notes:
http://www.juniper.net/techpubs/en_US/release-independent/wireless/information-products/topic-collections/wireless-lan/software/7.7/mss-rn-77-mr4.pdf

Cisco Flexconnect (Previously HREAP)

Cisco Flexconnect (which was previously known as HREAP) is a technology which allows access points (APs) to be deployed remotely from the controller but allow for distributed switching of local packets, which saves some traffic from being sent back down the CAPWAP tunnel, and over the WAN, back to the controller only to be sent back again to the AP to be switched. When using Flexconnect mode the AP actually terminates the CAPWAP tunnel rather than the WLC.

The opposite of Flexconnect is called local mode. And just to be confusing in Flexconnect mode the traffic is "locally switched", local to the AP. Where as in Local mode the traffic is centrally switched, centrally on the WLC.

In local mode there are 2 CAPWAP tunnels between the AP and WLC, one for data and one for management. In Flexconnect mode there is just one, for management, the data CAPWAP tunnel is terminated on the AP.

Flexconnect is supported on a number of different controllers, currently just the CUWN controllers (2500, 4400 [EOS] 5508, 7500, 8500). The unified access controllers (5760 Catalyst 3850) will get an upgrade at some point but do not currently support it and there is no date set. This is true as per 18/07/2013.

Flexconnect is the same regardless of the WLC, the 5508 implementation is the same as the 7500 implementation. A note on this is that the 7500 controller only supports Flexconnect mode, not local mode.

Guest networks function with the Flexconnect feature, the CAPWAP tunnel is terminated at the AP for corporate traffic that can be switched at the AP but guest traffic is tunnelled back to the controller and then onwards to the guest anchor controller as normal. See the reference link below regarding Flexconnect and auto anchor. This image, taken from that link, illustrates this well:

There are a number of limitations to Flexconnect, which I've listed below, which stops it replacing Local mode completely:

• L3 roaming is not possible with HREAP APs using locally switched WLAN.
• L2 roaming between two WLC(inter-controller) using locally switched WLAN with same mobility works only from 7.2.103.0.
• Data DTLS is unsupported for locally switched WLAN.
• Interface group is not supported however we can use AAA override.
• Mediastream feature won't work.
• Bandwidth contracts won't work for local switching.
• WGB can't connect to HREAP AP. (it may connect & work with central but doesn't work with local switching)
• All edge switches connecting to AP needs to be trunked to the core.
• HREAP AP doesn't join Multicast group. however it bridges the multicast packet to unicast for centrally switched WLAN.
• DHCP proxy by WLC is not possible. so we're exposing the DHCP server IP.
• ACLs needs to be configured & managed per AP for locally switched traffic or configure at your switch.
• CPU & interface ACL are NA for locally switched WLAN.
• RLDP may not work.
• AP group won't work for locally switched WLAN.
• Locally switched WLANs may optionally carry 802.1Q tagging to allow such WLANs to be segmented over the wired network at the Ethernet port of the access point.
• NAC out-of-band integration is supported only on WLANs configured for H REAP central switching. It is not supported for use on WLANs configured for H REAP local switching.
• External Web Authentication is not supported on local switching

References and Resources:
Flexconnect Feature Matrix
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b3690b.shtml

Flexconnect and AutoAnchor (Cisco Support Community)
https://supportforums.cisco.com/docs/DOC-24096

Local Mode vs Flexconnect (Cisco Learning Network)
https://learningnetwork.cisco.com/thread/51502

Cisco Guest Anchor WLC + Licensing

When deploying guest services in a Cisco WLAN you need to have an anchor WLC controller, which is located in the DMZ, which terminates the Ethernet over IP tunnels (EoIP) coming from the other campus controller, the foreign controller. EoIP is used in order to keep the guest traffic separate from the other enterprise traffic.

This image is taken from the Cisco Mobility design guide, link below, and illustrates the anchor controller functionality.

There is no additional licensing required to implement anchor controllers and no AP licenses are required, in fact you should purchased the appropriate controller with the least amount of AP licenses. This is because APs do not register to the anchor controller but rather to the foreign controller (the main WLC for the enterprise).

References:

Enterprise Mobility Design - Wireless Guest Access Services:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob73dg/ch10GuAc.html

Cisco WLC HA Deployment modes & AP SSO

There are 2 (that I know of) ways to deploy Cisco WLANs with regards to High Availability (HA):
N+1
1:1
Hybrid

One quick note before I start is that the SSO here is AP SSO not Client SSO, so a voice call would still be dropped. There is sub second failover but the client is required to reinitialise. Client SSO should be coming in version 7.5 of code.

N+1
As described in my previous post about N+1 HA this deployment models allows a dedicated HA WLC to be installed with the purpose of backing up an environment. An example would be a single primary controller with all APs connected to it with a HA controller, located physically somewhere else, running with the sole purpose of picking up in the event of a primary WLC failure.

An important consideration with this model is that there is no AP SSO (Stateful Switch Over) meaning there is approximately a 45 second period of delay while the APs connect to the HA controller after the primary has failed.

It's worth noting here that if you want to use the HA controller (for example AIR-CT5760-HA-K9) you need to run code 7.4 or later. Code pre 7.4 requires the HA controller to have access point licenses to operate as a secondary or tertiary controller.

The HA controller picks up licenses from a failed primary controller. So whether there is a single primary controller or multiple primaries for different groups of APs the HA controller can back up a number of different WLC. Further to this point the HA controller can pick up APs from multiple failed primary controllers. A 5508 HA has a wireless AP capacity of the device maximum, which is 500. So if there are 2 primary 5508 controllers, each with 250 APs, if one fails the 250 APs will fail over to the HA controller, then should the other primary controller fail those access points can fail over to the HA controller as well to the maximum of 500. See the HA Q&A for details.

Previous post:
http://twhittle1.blogspot.co.uk/2013/05/cisco-wireless-n1-ha.html

1:1
1:1 HA redundancy describes 2 controllers, one as the active and one as the standby. These controllers are physically located next to each other because there is a redundancy port on each controller which must have a physical cable between them. The reason for this connection is in order to achieve the AP SSO there must be a very small latency when noticing the failed primary controller. Even though theoretically it is possible to have AP SSO work when the controllers are layer 2 adjacent, the only Cisco supported configuration is with a direct link in between the two controllers.

When using 1:1 HA the APs will see this as a single controller, in fact the APs will not notice a controller failing this is how the AP SSO is achieved.

Hybrid
The Hybrid method is a best of both worlds implementation because you have a primary controller with the hot standby physically connected and located together, as well as other controllers, secondary or tertiary in remote, geographically separate, locations so that should the HQ with primary WLC go down there are other controllers in different locations ready to step up.

Another way of implementing a hybrid deployment would be to have 2 sets of 2 WLC in geographically separate locations. In one location there is a primary with a hot standby and in the other a secondary controller with a hot standby. This way a single controller can fail in each location and retain the AP SSO. However is a whole site goes down and the primary has to fail over to the secondary then AP SSO will not be retained, failing over between primary and secondary controllers will always introduce downtime.

References:
High Availability (AP SSO) Deployment Guide:
http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bd3504.shtml

High Availability Q&A:
http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/qa_c67-714540_ps2706_Products_Q_and_A_Item.html

Cisco MSE and 3rd Party APs

Just a quick post...

At this time the MSE is compatible with only Cisco Access Points for wIPS and location tracking in addition to other key functions such as ClearAir which are specific to the Cisco APs. 

Cisco does have the Ability to manage 3^rd party APs with the MSE’s management front end under Prime Infrastructure, however the advanced features are specific to the Unified Cisco Wireless Solution.

Cisco Wireless N+1 HA

Here is a little scatter shot information about Cisco WLCs in the N+1 HA model:

When using N+1 HA make sure the controllers are running V7.4 or later. Pre 7.4 the N+1 HA model requires a permanent AP count license on the backup controller. With Release 7.4 and later, an HA-SKU secondary controller can be used as the backup controller for multiple primary controllers. The overall goal for the addition of N+1 HA with HA-SKU is to reduce the total cost of ownership (TCO) for geographically separate HA deployments across the WAN link.

Keep in mind that Access Point Stateful Switch Over (AP SSO) functionality is not supported for N+1 HA. The AP Control and Provisioning of Wireless Access Points (CAPWAP) state machine is restarted when the primary controller fails. With Release 7.4, the backup controller for N+1 HA can be an HA-SKU secondary controller. AIR-CT5760-HA-K9 is the HA SKU for the new Cisco 5760 WLC, for example.

an HA WLC, with a different user count to the main controllers, can be used as the HA controller. For example 2 x WISM2 each with 750 AP licenses can be backed up by a WLC5670 which could only support 1000 APs.

The new 5760 WLC does support N+1 High Availability. If interworking with AireOS controllers in the same Mobility group, you will need either a WiSM2 or a CT5508 running 7.3.112.0 release and also in  "Hierarchal Mobility Mode"  to form a Mobility group with IOS-XE based Controllers [3.2.0SE release]. Be aware that in the current release, when AP's fail between dissimilar WLC Operating Systems (AireOS and IOS-XE) the AP's do download a new CAPWAP image and reboot; so this failover is not "sub 45 seconds"  but rather 2~3 minutes depending on download speeds and reboot times of Access Points.  

References:

Cisco Catalyst 3850 Series Switches – Q&A

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/qa_c67-722110.html

Cisco Catalyst 3850 Switch Deployment Guide

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/deployment_guide_c07-727067.html

Cisco Unified Access Technology Overview: Converged Access

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/white_paper_c11-726107.html

Converged Access Mode for the Cisco 5760 WLC and the Catalyst 3850 Switch

http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps12598/qa_c67-726507.html

Cisco Wireless Software Compatibility Matrix - (Converged Access WLC Compatibility Matrix – Table 6)

http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html#wp92761

Release Notes for Cisco WLC's and Lightweight Access Points

http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn7_3_112_0.html#wp1060401

WLC High Availability

http://www.cisco.com/en/US/prod/collateral/wireless/ps6302/ps8322/ps10315/qa_c67-714540_ps2706_Products_Q_and_A_Item.html

N+1 High Availability Deployment Guide

http://www.cisco.com/en/US/docs/wireless/technology/hi_avail/N1_High_Availability_Deployment_Guide.html

Cisco 5760 WLC Deployment Guide

http://www.cisco.com/en/US/docs/wireless/technology/5760_deploy/5760_Deployment_Guide.pdf

Release Notes for the Cisco 5760 WLC, IOS XE Release 3.2.x SE

http://www.cisco.com/en/US/docs/wireless/controller/3.2_0_se/release_notes/OL28115_3_2_se_rn.html

Juniper WLC Licensing + Cluster - Update

So Juniper wireless licensing as I know it has changed! Previous I thought it was the same as Cisco where you had to have enough licenses per controller to handle all APs should a single controller fail but this is no longer the case.

The way that AP licensing now works on Juniper WLC is that WLC can burst up to double their current installed license count as long as they have installed the HA license: WLCXXX-HA-RTU

Therefore if you have 100 APs, each WLC can have 50APs licensed and the HA license, this allows up to 100 APs in the event of a single AP failure.

One note on this is that you do not require the HA-RTU license in order to cluster Juniper WLCs. The only thing that the HA-RTU license grants you is the ability to burst to double the installed license capacity. Clustering is configurable without it, but each WLC will be limited to the number of AP licenses is currently has installed.

Here is a great description of Juniper WLC Clustering I was given:
A cluster is something you create inside a mobility domain which enhances the reliability and redundancy features in a mobility domain. A mobility domain does provide controller redundancy but an AP needs to reboot in order to find the redundant controller. If you enable A/A clustering it provides stateful peering between controllers therefore the APs do not need to reboot during controller failure. This is a powerful feature specific to Juniper which clients like for ISSU and unplanned outages. A mobility domain supports up to 64 WLCs from which a maximum of 32 can participate in a A/A cluster (currently max size of a cluster is 4096 APs) . Clustering provides the following benefits:

o   Hitless Failover (AP switches to secondary AP manager subsecond)

o   Hitless software failover

o   AP load balancing (automatic balancing of all APs across all clustered WLCs in your mobility domain)

o   Cluster configuration - you define your complete wireless configuration once on the seed

Juniper Clustering is great because of the truly hitless failover, the WLC are configured in a A/A cluster and when controllers are clustered each AP maintains connectivity with it's Primary AP Manager (PAM) and Secondary AP Manager (SAM), the PAM propagates client sessions to the SAM. For voice, once a call is setup, local switching would occur to avoid any issues with latency caused by tromboning traffic via a controller. Data can also be locally switched which is great because you can choose how extensively you want to implement local switching choosing when to use either local or central switching. An AP failure is not even considered as 'system failure’, it is seen as a roaming event. The nearby AP taking over the session will not distinguish between ‘nearby AP failure’ or ‘user approaching AP with better signal strength’.

ISSU works in a similar fashion when running a virtual controller cluster. APs without sessions are targeted first and those with sessions take neighbouring APs into consideration allowing session roaming to neighbours before updating the now session free AP.

WCS Unsupported Access Points - 1600/2600/3600

WCS has pretty much reached the end of it's development cycle. It's not currently EOL (March 2013) but the capabilities have been built into Prime Infrastructure and this is where the development and research will go.

WCS does not support the newest 1600/2600/3600 access points, this is because these access points support features (Clean Air, Client Link 2.0) which WCS does not and there is very little development in it going forward.

Cisco 3850 as a Wireless LAN Controller

Using 3850's as WLC is a relatively easy feat you just need the 3850 switch with IP Base or IP Services and finally a number of AP licenses equal to the number of access points. Remember that a single switch can have up to 50 access points, and a switch stack can have up to 50 APs as well.

Example part numbers might be:

WS-C3850-24T-S

LIC-CTIOS-1A

One thing that threw me initially on the data sheet is the below part number:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps12686/data_sheet_c78-720918.html

L-LIC-CT3850-UPG

It bills it as an upgrade license so I assumed it was required to upgrade the switch enabling the WLC. This is not the case. This part is a top level part used to add additional licenses to an existing 3850 switch.

NCS Wireless device licenses

Based on the documents below, WLC do not take up licenses in NCS.

WLCs do not count against NCS license count.

Cisco Prime NCS 1.1 Deployment Guide

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bba943.shtml

For example a deployment comprising of 280 AP's and 6 WLC, just purchase licenses enough to cover the 280 access points. You can either go with 1 instance of the 100 Base license 'R-PI-1.1-100-K9' then choose under Add On option, 2 instances of the 100 Add On licenses to come up with 300 licenses, or go with the 500 user license 'R-PI-1.1-500-K9' to have room for more devices as your network expands.

Other devices which do not take up NCS license count would be: WLCs, Autonomous APs,  and MSE's. These devices are not licensed but they need to be counted on the 'scalability' of the appliance.

WLC Old Licensing

For the longest time before, Cisco had 2 separate SKUs for Base and PLUS licenses on WLC but it all changed with the 6.0.196 code.

"Before 6.0.196, licenses were separated into BASE and PLUS types.—With 6.0.196 and all later code (including 7.0 releases), all features included in a Wireless LAN Controller Wplus license are now included in the base license."

Understanding Cisco 5508 Wireless LAN Controller Licensing

http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b78104.shtml

Thus, the licenses bundled along with the WLC at the initial order; for example, AIR-CT5508-100-K9 which has both the 5508 hardware and the 100- AP count license, already has the 'PLUS' features on it. Removing the additional cost for Plus license for these features:

•Office Extend AP

•Enterprise Mesh

•CAPWAP Data Encryption 

WCS / Prime NCS Location tracking perimeter

WCS doesn't have the feature to locate wireless devices as well as set up a perimeter. For location tracking you need to use the Mobility Service Engine (MSE).

http://www.cisco.com/en/US/prod/collateral/wireless/ps9733/ps9742/data_sheet_c07-473865.html

Prime Infrastructure is exactly the same the MSE is still required for location tracking:

The latest version of Prime Infrastructure, which is 1.3 (28/03/2013), still requires MSE for location services. Refer to the links below for the components of a Cisco Context-Aware Mobility Solution.

“The Location Analytics Service analyzes wireless device location information in a particular network. The Location Analytics Service uses the data provided by the Cisco Mobility Services Engine (MSE) to calculate the location of Wi-Fi devices in the Wireless Local Area Network (WLAN).”

http://www.cisco.com/en/US/docs/wireless/prime_infrastructure/1.3/configuration/guide/mse.html#wp1672289

Q. Which WLC and Prime infrastructure versions do I need for Advanced Location Services?

A. You need 7.2 release or above on your WLAN controller and software version 1.3 or above for Prime infrastructure.

http://www.cisco.com/en/US/prod/collateral/wireless/ps9733/ps9742/qa_c67-726505.html

Cisco Wireless LAN Controller licensing and 2500 / 5500 WLC difference

The 2500 and 5500 series controller don't support shared licensing, so we need to make sure that both controller has the same number of licenses, which will be able to support the required number of APs. I've touched on this previously.

Other than the number of AP's each controller can support some of the differences are:

- Link aggregation group

- Guest services (wired)

- Guest anchor

- Greater number of WLANs

- Greater number of access points groups

- Greater AP scalability

A more complete comparison can be found here:

http://www.cisco.com/en/US/products/hw/wireless/products_category_buyers_guide.html#~controllers

Other than this they are pretty similar and use the same code.