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)
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 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

CAT1(config)#aaa new-model
CAT1(config)#radius server AAA-RADIUS-ISE01
CAT1(config-radius-server)#address ipv4 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
Authentication policy
Authorization policy

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
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

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     5247    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          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 – and MA (CAT2 –

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

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 and multicast group 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 :

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 ( and CAT2 ( 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
CAT1(config)#wireless mobility group member ip group MC2
CAT1(config)#wireless mobility group multicast-address MC2 ip
CAT2(config)#wireless mobility controller
CAT2(config)#wireless mobility group name MC2
CAT2(config)#wireless mobility multicast ip
CAT2(config)#wireless mobility group member ip group MC1
CAT2(config)#wireless mobility group multicast-address MC1 ip

Cisco WLC rate limiting

This time a short post about rate limiting on an Cisco AirOS WLC. Under the QoS tab of the SSID configuration you can find two categories of rate-limiting settings; per user and per SSID. For both categories you can specific UDP and TCP rates, however those settings are being applied on the specific radios of the access-point and not on the controller! Below two examples to illustrate what this means.

Two clients on the same AP and on the same radio
3Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 3359000 bits/sec, 300 packets/sec

6Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 6346000 bits/sec, 581 packets/sec

Two clients on the same AP and on different radios
3Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 6391000 bits/sec, 576 packets/sec

6Mbit policy:
AP#show int gigabitEthernet 0 | i input rate
30 second input rate 12325000 bits/sec, 1108 packets/sec

So if you expect an “global maximum per SSID” you will find that the configured value will not work with multiple access-points and clients. You have to really dive deep in the documentation from Cisco to find this. I guess Cisco had some complains about this as well because since software version 8.0 the related footnote (number 16) for this configuration item got changed. The added “Override Bandwidth Contracts parameters are specific to per Radio of AP.” Yeah, about time…

A better location for your traffic engineering is in my opinion somewhere on the next-hop router or firewall, the WLC is really not the device to do this. The (re)marking of traffic is fine, enforcing policies is another story.

Simple IOS-XE mDNS configuration for AppleTV

This post is a small “tech note” about how to configure mDNS in IOS-XE to support AppleTV. In this example the AppleTV is located in VLAN 101 and the client in VLAN 107.

First enable mDNS and configure the switch to query for AirPlay and AirTunes services (AirTunes is necessary for AppleTV to work as well).
service-list mdns-sd MDNS-QUERY query
service-type _airplay._tcp.local
service-type _raop._tcp.local
service-routing mdns-sd
service-policy-query MDNS-QUERY 60

Configure service lists so that only AirPlay and AirTunes announcements will be accepted on the VLAN101 interfaces.
service-list mdns-sd MDNS-VLAN101-IN permit 10
match message-type announcement
match service-type _airplay._tcp.local
service-list mdns-sd MDNS-VLAN101-IN permit 20
match message-type announcement
match service-type _raop._tcp.local
service-list mdns-sd MDNS-VLAN101-IN deny 30

From the client side we only process AirPlay and AirTunes queries.
service-list mdns-sd MDNS-VLAN107-IN permit 10
match message-type query
match service-type _airplay._tcp.local
service-list mdns-sd MDNS-VLAN107-IN permit 20
match message-type query
match service-type _raop._tcp.local
service-list mdns-sd MDNS-VLAN107-IN deny 30

Because we apply the filtering on the inbound side, outbound filtering is not required.
service-list mdns-sd MDNS-VLAN101-OUT permit 10
service-list mdns-sd MDNS-VLAN107-OUT permit 10

Apply the service lists on the interfaces.
interface Vlan101
service-routing mdns-sd
service-policy MDNS-VLAN101-IN IN
service-policy MDNS-VLAN101-OUT OUT
interface Vlan107
service-routing mdns-sd
service-policy MDNS-VLAN107-IN IN
service-policy MDNS-VLAN107-OUT OUT

Validate that records are visible.
CAT3650# show mdns cache
_airplay._tcp.local PTR IN 4500/4496 0 Vl101 a431.3514.b907
_raop._tcp.local PTR IN 4500/4496 1 Vl101 a431.3514.b907
AppleTV._airplay._tcp.local SRV IN 4500/4496 1 Vl101 a431.3514.b907

Cisco IOS / IOS-XE and DHCPv6 option 52 (RFC 5417)

First post in the year 2016! Will this be “the” year for IPv6? Who knows, but at least this post will be about IPv6 which is a start right? 🙂

If you have 3500’s or newer type of access-points with AirOS 8.x software on your WLC’s you can use native IPv6 as protocol for the CAPWAP traffic. The way that AP’s initially try to discover WLC’s with IPv6 is not that different comparing with IPv4:
1. DHCPv6 Option 52
2. Multicast Discovery (L2)
3. DNS
4. Static AP priming

More than once I have used Cisco’s native DHCP server in IOS/IOS-XE to supply AP’s with information about the WLC’s (with DHCPv4 this is option 43). I wanted the same with IPv6 so I configured the following:

ipv6 dhcp pool IPV6-DHCP-VLAN106
address prefix 2002:1234:CC1E:106::/64
vendor-specific 52
suboption 1 address 2002:1234:CC1E:105::11

On the AP side something strange was happening. Instead of showing “CAPWAP Access controller: <IPv6 address> ” it showed the following output:

AP#show ipv6 dhcp interface
Vendor-specific Information options:
Enterprise-ID: 52

After more than one hour of fiddling with the configuration and troubleshooting I reached out to TAC. It turns out that the current DHCPv6 implementation on IOS and IOS-XE simply don’t support DHCPv6 option 52 (RFC 5417). Because of this TAC filled the feature enhancement CSCux73480. More information about DHCPv6 option 52 configuration for other DHCPv6 servers can be found in this document.

Cisco’s converged access and (in)directly connected access-points

In every document you can find about Cisco’s converged access you will read that with 3650 and 3850 switches access-points need to be directly connected. I understand the reasons why Cisco requires that, but the nerd in me wanted to know how that it works and if the switch can be tricked in the process. So what happens if you connect an access-point on another layer 2 switch and build a dot1Q trunk between that switch and the 3650/3850?

Nov 18 00:58:18.893: %CAPWAP-3-AP_PORT_CFG: AP connected port Gi1/0/24 is not an access port.

Busted! But what happens when we make it an access port? Great success! Sadly this only works for just the first access-point. So to summarize the requirements if you really need/want to do this:
1. The access-point needs to be in the same VLAN as the wireless management interface of the 3650/3850 switch
2. The interface where the access-point is being located on/after needs to be in access mode
3. Only one access-point per interface.

Note: I tested this on an 3650 with IOS-XE 03.06.00E, but I do not believe that this is something what will change in newer software versions.