What changed in Cisco AireOS 8.10?

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.

Cisco’s “Enterprise Networks Core and WAN Exam”

Cisco’s partner program currently contains four specializations. Besides having multiple individuals owning certain “regular” certifications like a CCNP or CCIE, also additional exams are required to fulfill certain roles and achieve the specialization.

One of those additional exams is called “Enterprise Networks Core and WAN Exam (ENCWE)” with number 500-452. Besides the blueprint itself and a full-blown training Cisco does not provide specific content for this exam.

I have recently passed this exam and, without breaking the NDA, I highly recommend you to watch and study the materials presented in the following two Cisco Live sessions:
BRKCRS-2002 IWAN Design and Deployment Workshop
BRKARC-2091 Emerging Trends in Branch Office Architectures

Doing so, in addition to a quick refresher on the CCDP content, was sufficient for me to pass this exam. Good luck with your studies!

Cisco 3702 on (regular) PoE

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.

Input power Antennas Channel Max. EIRP PL1 PL2 PL3 PL4 PL5 PL6 PL7 PL8
PoE Rx: 3, Tx: 3 36 23 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm
132 30 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm
PoE+ Rx: 4, Tx: 4 36 23 dBm 18 dBm 15 dBm 12 dBm 9 dBm 6 dBm 3 dBm
132 30 dBm 23 dBm 20 dBm 17 dBm 14 dBm 11 dBm 8 dBm 5 dBm 2 dBm

Deny traffic on autonomous APs

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.

Use case Configuration
Deny wireless client to associate with AP access-list 700 deny 1c1d.862c.70f0 0000.0000.0000
access-list 700 permit 0000.0000.0000 ffff.ffff.ffffdot11 association mac-list 700
Deny wireless client to associate with specific SSID access-list 700 deny 1c1d.862c.70f0 0000.0000.0000
access-list 700 permit 0000.0000.0000 ffff.ffff.ffffinterface Dot11RadioX.X
bridge-group x input-address-list 700
Deny wireless client to client traffic interface Dot11RadioX.X
bridge-group x port-protected
Deny wireless to wired IPv4 traffic ip access-list extended ACL-IPV4-DENY
deny icmp any any
permit ip any anyinterface Dot11RadioX.X
ip access-group ACL-IPV4-DENY in
Deny wireless to wired IPv6 traffic ipv6 access-list ACL-IPV6-DENY
deny icmp any any
permit ipv6 any anyinterface Dot11RadioX
ipv6 traffic-filter ACL-IPV6-DENY in

Note: it is possible to apply this ACL on a sub interface as well (just as with IPv4), however this does not have any effect on the traffic. See also bug CSCva17063.

Deny wired to wireless IPv4 traffic ip access-list extended ACL-IPV4-DENY
deny icmp any any
permit ip any anyinterface gigabitEthernetX.X
ip access-group ACL-IPV4-DENY in
Deny wired to wireless IPv6 traffic ipv6 access-list ACL-IPV6-DENY
deny icmp any any
permit ipv6 any anyinterface gigabitEthernetX
ipv6 traffic-filter ACL-IPV6-DENY in

Note: it is possible to apply this ACL on a sub interface as well (just as with IPv4), however this does not have any effect on the traffic. See also bug CSCva17063.

WLC management authentication based on RADIUS

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

Platform RADIUS server configuration
AirOS Protocol: PAP_ASCII
Match on: Radius Service-Type equals “Nas Prompt”
Return back: Radius Service-Type = Administrative (full access)
Return back: Radius Service-Type = Nas Prompt (read-only access)
Return back: Radius Service-Type = Call-Back Administrative (lobby admin)
IOS & IOS-XE Protocol: PAP_ASCII
Match on: Radius NAS Port id contains “tty” (for CLI)
Match on: Radius NAS Port Type “Virtual” (for GUI)
Return back: Cisco cisco-av-pair = shell:priv-lvl=15

Cisco ONE licensing and 5508 WLC

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 🙂

Advanced roaming features

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.

Feature Client support required Description
Rx SOP No Force clients to roam or leave the WiFi network by ignoring frames on the radio level with a certain signal strength.

Rx SOP Configurations are supported on AP1600, AP2600, AP2700, AP3500, AP3600, AP3700 and AP1550 only.

RSSI Low Check No Motivate clients to use another access-point or leave the WiFi network by denying clients with a certain signal strength to associate.
Optimized roaming No Motivate clients to use another access-point by disassociate clients with a certain signal strength.

Optimized roaming uses some of the values configured within the coverage hole detection mechanism.

Aggressive load balancing* No Clients are being motivated to use another access-point.

APs in local mode will send a code 17 (AP busy) message, with Flexconnect APs the client is being de-authenticated.

Band select No Motivate dual-band clients to use 5 Ghz instead of 2.4 Ghz by delaying probe responses on the 2.4 GHz.
Assisted roaming (802.11k)* Yes Inform clients about alternative APs to limit the need for active and passive scanning on the client when it wants to roam. After a certain amount of denied association responses the client will be allowed.

The prediction part of the Cisco implementation is not based on 802.11k and does not require client support.

Fast Transition (802.11r) Yes Introduces a concept of roaming where the initial handshake with the new AP is done even before the client roams to the target AP.
CCX Client Roaming Yes Provide CCXv4 enabled clients with roaming configuration parameters to direct influence the roaming behavior.

*: 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.

Cisco access-point authorization

Besides doing (traditional) dot1X on the wired switchport on which a access-point is connected, it is also possible to let the wireless controller authorize access-points within the join process. This post gives the necessary configuration for the use of a external AAA RADIUS server (ISE) within this process for AirOS and IOS-XE wireless controllers.

1. AirOS
(2504) >config radius auth add 1 192.168.208.51 1812 ascii Pr3sh@r3dk3y
(2504) >config radius auth network 1 enable
(2504) >config macfilter radius-compat cisco
(2504) >config auth-list ap-policy authorize-ap username ap-mac
(2504) >config auth-list ap-policy authorize-ap enable

2. IOS-XE
CAT1(config)#aaa new-model
CAT1(config)#radius server AAA-RADIUS-ISE01
CAT1(config-radius-server)#address ipv4 192.168.208.51 auth-port 1812 acct-port 1813
CAT1(config-radius-server)#key 0 Pr3sh@r3dk3y
CAT1(config)#aaa group server radius AAA-GRP-ISE
CAT1(config-sg-radius)#server name AAA-RADIUS-ISE01
CAT1(config-sg-radius)#subscriber mac-filtering security-mode mac
CAT1(config)#ap auth-list ap-policy authorize-ap
CAT1(config)#aaa authorization network default group AAA-GRP-ISE

3. ISE
While I was performing some testing there where two things which caught my attention on the ISE logging:
1) By default IOS-XE will send a blank password which ISE does not understand (fix for this is the “subscriber mac-filtering security-mode mac” command)
2) In ISE the AirOS authentication requests showed up as MAB method, while the requests from IOS-XE used the PAP_ASCII method. Despite some research I was unable to find a way to change this on the IOS-XE side. I ended up with the following configuration to support both platforms within the same set of rules:

Allowed protocols
ISE
Authentication policy
ISE
Authorization policy
ISE

Cisco Converged Access multicast configurations

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.

Wireshark

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.

Wireshark

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