This weekend I was able to make the time (and got the required service window 🙂 ) to migrate the home Wi-Fi network from AireOS 8.5.161.0 towards a new vWLC based on AireOS 8.10.121.0. In this post I list the things that stood out for me with the new software.

Security:
– Specifying the AP username and password is now part of the installation wizard. In case you upgrade an existing installation and haven’t configured this account, you will no longer have console access with the default credentials once the AP has joined the controller.
– The default (and thus very insecure) SNMP settings are removed.

Interface:
– The SSH login “doesn’t ask twice” for an username anymore (Note: changed since AireOS 8.6).
– When an AP is in downloading status, you now see the IP address of the AP in the GUI.
– The level of access the logged-in user has, is now being displayed in the GUI:

– To make the “Authentication Key Management” list with all the check boxes more intuitive, you now have to specify if your WLAN is a “Enterprise” or “Personal” one:

– A new section has come up under the security tab of the WLAN called “RADIUS Authentication Survivability”. During the writing of this post I was unable to find documentation regarding this feature, but if the name implies what it does it might be worth the effort to create another post dedicated to this feature 🙂

– AP (group) NTP server settings in the GUI.
– “Assisted Roaming Prediction Optimization” (e.q. 802.11k for non 802.11k clients) has made it back on the GUI after being removed in 8.5.
(Note: you don’t want this feature enabled, especially when you have to support Android clients.)

Changed default settings:
– “Flexconnect Arp-Cache” is now enabled by default.
– When you create a WLAN, the “Over the DS functionality” part of the 802.11r configuration, is now disabled by default.
– The “fast-ssid-change” feature is now enabled by default. (Note: this setting doesn’t exists on the new IOS-XE based Catalyst 9800 wireless controllers anymore since it is the default behavior for this platform anyway.)

Despite that the AireOS based platforms are almost at the end of there era, it is good to see some long awaited changes/features are being implemented. Check for additional information the corresponding release notes and the AireOS Feature List Per Release document.

It has almost been one year since my last post, so it is really time to write something again 🙂 .

The transmit power of a radio within an access-point is being represented based on power-levels within the Cisco controller world. I have already written a post about these power-levels and how the configured gain of the antenna is related in the past. But did you know that besides the gain, the regulatory domain and specific channel also the input power of the access-point itself might influence the actual transmit power?

With the 3800 serie access-points the radios cannot be enabled when the run on regular PoE, this behavior is different with the 3700 serie. The 3700 access-point will work, but with one receive and one transmit antenna disabled. Besides that also the transmit power changes. Below some calculation examples based on an 3702I-E access-point. So, my advice is to always verify on the cli of the controller with the “show advanced 802.11x txpower” so you can, besides the power-levels, also see the dBm values which the represent.

There are quite a few methods to filter certain kinds of traffic on Cisco’s autonomous access-points. This post gives a overview of the different methods and how to use them based on use cases.

This post is a quick reference for configuring management authentication with RADIUS for AirOS and IOS-XE based WLCs.

When new licensing models are being published the first thing that vendors release are the marketing brochures. Due to this is selling the new “stuff” usually not the biggest problem (except when certain features have been moved to another “level”, but how often does that happen.. right?..). The more difficult part is finding out how the new process works and which codes, files and/or commands need to be entered on the box to get it running. This post is about Cisco ONE licensing in conjunction with the 5508 WLC to help fellow engineers 🙂 .

Regular licensing for the 5508 WLC is pretty straightforward: you buy a 5508 with a certain amount of AP licenses on it and you can upgrade this amount if needed up to 500 AP licenses. It gets a little more complicated if you add HA SSO in the mix: the primary 5508 needs to have a permanent license (12 AP licenses is enough), the secondary 5508 needs to be at least licensed with 50 AP licenses or needs to be a dedicated HA SKU unit (which is just as expensive as a regular 5508 with 50 AP licenses).

With Cisco ONE the idea is that you always buy controllers (C1-AIR-CT5508-K9) with zero AP licenses and depending on your needs you buy a certain amount of C1 licenses. The nice part with those C1 licenses is that also node licenses for Prime Infrastructure, MSE and ISE are included so you don’t need to order them separately anymore. When you order the controllers and C1 licenses you will receive a eDelivery link to download the PAK codes. Those PAK codes can be registered on the Cisco website and will give you for the 5508 controller regular LIC files which you need to upload to the controller. Nice detail: the C1-AIR-CT5508-K9 controller without any licenses can function as a HA SKU as well, which is a much cheaper solution comparing to the regular licensing.

What about mixing this new license model with install base? This is the tricky part. The official statement that I received from Cisco is that mixing the old and new licensing model is not supported and the install base should be migrated to the new form of licensing. From my own testing I can say that you can pair a regular licensed 5508 with an C1 controller as secondary unit in HA SSO setup without any problems. Same goes for upgrading the AP licenses of regular licensed controllers with C1 licenses. Official documentation regarding this is simply not available but I don’t think that Cisco wants you do to that…

Hopefully this information helps with your first Cisco ONE implementation 🙂

Disclaimer: I did not test all the below described features in a production network. Some features require support/feedback from the client itself which is not always there or clients are getting confused by enabling this features with a bad user experience as result. Always make sure to monitor the impact of your changes and test upfront as much as possible. Keep in mind that a good wireless infrastructure starts with a good RF design and multiple validation site surveys. These features can only help to further optimize.

There are quite a few features available on the AirOS controllers and access-points which are (indirect) related to roaming. Some of them are Cisco proprietary and some are based on industry standards, but all of them share the goal to use the RF as efficient as possible and positive influence the user experience.

For my CCIEW studies I created the list below with relevant features based on 8.0 version of AirOS code.

*: Because both load balancing and assisted roaming are designed to influence the AP that a client associates with, it is not possible to enable both the options at the same time on a WLAN.

Within the Converged Access platform there are a few features which can benefit from the use of multicast traffic flows. In this post I discuss which these features are and how they need to be configured.

1. Generic multicast configuration
First of all some generic multicast configuration needs to be in place on which the other features rely. For this post I use two 3650 switches (CAT1 and CAT2) which are directly connected to each other. The wireless management interface is VLAN 601 for both switches. IP multicast routing will be enabled globally and for both switches one switch will be statically configured as as RP for PIM.

CAT1(config)#ip multicast-routing
CAT1(config)#ip pim rp-address 10.60.1.254
CAT1(config)#int vlan 601
CAT1(config-if)#ip pim sparse-mode


2. “Multicast-multicast” mode for client multicast traffic
To distribute the client multicast (and broadcast) traffic as efficient as possible between the switches and the access-points, we can use “multicast-multicast” mode. In this configuration the client traffic will be send to the access-points with multicast as well.

CAT1(config)#wireless multicast
CAT1(config)#ap capwap multicast 239.44.44.44

Once enabled you can see that a dedicated Capwap interface is being created, which is “Ca1” in this scenario with the SVI of the CAT1 switch as source IPv4 address.

CAT1#show capwap summary
Name   APName                           Type PhyPortIf Mode      McastIf
------ -------------------------------- ---- --------- --------- -------
Ca1    -                                mcas -         unicast   -
Ca2    3502I                            data Gi1/0/2   multicast Ca1
Ca3    2602E                            data Gi1/0/3   multicast Ca1

Name   SrcIP           SrcPort DestIP          DstPort DtlsEn MTU   Xact
------ --------------- ------- --------------- ------- ------ ----- ----
Ca1    10.60.1.254     5247    239.44.44.44    5247    No     1449  1

On layer 2 level we see that IGMP snooping is active for the two ports on which the access-points are connected.

CAT1#show ip igmp snooping groups
Vlan      Group                 Type        Version     Port List
------------------------------------------------------------------------
601       239.44.44.44          igmp        v2          Gi1/0/2, Gi1/0/3

So how does this looks like on the wire? In the red box in the picture below you see the actual multicast packet, the orange box is the encapsulated client (broadcast) traffic.

3. Multicast traffic within Switch Peer Group
Converged Access works with Mobility Controller (MC) and Mobility Agent (MA) roles in certain Switch Peer Groups (SPG). Those SPG should be designed around areas where extensive roaming is going to happen like one building or floors. Within a SPG you only have one MC but you can have multiple MAs which all need to communicate with each other. Some communication can be done with multicast as well which can be more efficient if you have a few MAs within the SPG. Below the configuration for the MC (CAT1 – 10.60.1.254) and MA (CAT2 – 10.60.1.250).

CAT1(config)#wireless mobility co peer-group MA
CAT1(config)#wireless mobility co peer-group MA member ip 10.60.1.250
CAT1(config)#wireless mobility co peer-group MA multicast ip 239.33.33.33
CAT2(config)#wireless mobility co ip 10.60.1.254

The multicast address configuration is being pushed by the MC to the MA:

CAT2#*Mar 19 21:33:30.843: *%MM-6-SOCK_SET_ADDRESS_OPTION: 1 wcm: Setting membership for interface IP 10.60.1.250 and multicast group 239.33.33.33 on the mobility sockets.

CAT2#show wireless mobility summary
Mobility Agent Summary:
Mobility Role : Mobility Agent
Mobility Protocol Port : 16666
Mobility Switch Peer Group Name : MA
Multicast IP Address : 239.33.33.33

So how does this looks like on the wire? Below you can see the messages being send by the MA when one clients roams between APs connected on CAT1 and CAT2.

4. Multicast traffic between MCs (in different mobility domains)
In this scenario both CAT1 (10.60.1.254) and CAT2 (10.60.1.250) are MCs and belong to different mobility domains. Again the use multicast to communicate with each other. Note: from my own testing I have seen that it is not required to use different multicast address for this.

CAT1(config)#wireless mobility controller
CAT1(config)#wireless mobility group name MC1
CAT1(config)#wireless mobility multicast ip 239.33.33.35
CAT1(config)#wireless mobility group member ip 10.60.1.250 group MC2
CAT1(config)#wireless mobility group multicast-address MC2 ip 239.33.33.36
CAT2(config)#wireless mobility controller
CAT2(config)#wireless mobility group name MC2
CAT2(config)#wireless mobility multicast ip 239.33.33.36
CAT2(config)#wireless mobility group member ip 10.60.1.254 group MC1
CAT2(config)#wireless mobility group multicast-address MC1 ip 239.33.33.35