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.

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

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.

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.

For a customer we are currently deploying a new wireless network infrastructure with voice over wireless (VoWLAN) as primary use-case. In this deployment we use Flex-connect with 2700 / 3700 AP’s, a virtual WLC and Cisco’s own 7925G wireless phones.

In the testing phase we discovered that the Cisco 7925G phones showed that while making a voice call, the received wireless traffic where received as “best effort”. Usually this means some wrong QoS configuration on the wired side, so we created some traces to see if the QoS values (ToS in this case) of the audio streams where in place and correct. Crazy enough this was the case, so from that point we knew that the problem was really occurring on the wireless side.

We created some wireless traces and we saw that the wireless QoS values (IEEE 802.11e UP) of the downstream audio where “0” (best-effort), while those values really should be “6” (voice) based on the ToS values of the packets. As test we created a new SSID with no encryption at all and things worked fine. In the end we found out that enabling Flexconnect local authentication was the root cause of this problem so we opened a TAC case to get it fixed.

After some mail contact with TAC this problem was being passed on to the escalation guys for the wireless business. They added this input on this bug. Until today it has not been fixed, so watch out if you are running this kind of setup!

Update 8 October: Cisco finally fixed it in AirOS release 8.120.6 🙂

CleanAir

The CleanAir technology in Cisco’s access-point’s comes originally from the Cognio acquisition back in 2007. Cognio had a hardware chip that could do spectrum analysis and recognize non wifi interference. After this acquisition Cisco integrated this hardware capability right into its access-point’s. The first access-point with this technology was the 3500 and since then all the 2×00 and 3×00 access-points have CleanAir support.

An commonly misunderstanding is that the CleanAir makes an access-points change its channel when it discovers a (strong) non-wifi interference on the channel the access-point is currently on. RRM is the part of the WLC that is responsible for the power and channel configuration of your access-point, not CleanAir. CleanAir only detects. However, when you enable event driven RRM (EDRRM), the RRM algorithm will take the CleanAir information into account.

CleanAir Express

CleanAir Express was announced together with the 1600 access-point, but was not usable at the time due to the lack of software support. The only thing that Cisco published about this subject was that “it” was done in software on the access-point’s instead of doing it in hardware. Since than it is chaos around this subject because nobody really knows what to expect from CleanAir Express…

The documentation available today from Cisco on CleanAir Express does not help either. The primary reason for this (which I can think of) is that CleanAir Express has just been implemented since software 8.0, which is still fairly new and the marking people needed something to show earlier than the release of that code. A nice example is this document that states that “Air Qualty Index” is not supported with CleanAir Express, but from my own experience I can tell you that this just does work on 1600 and 1700 AP’s while running 8.0.110 code. See the example below.

(vWLC) >show ap inventory 1602E
NAME: “Cisco AP”    , DESCR: “Cisco Wireless Access Point”
PID: AIR-CAP1602E-E-K9,  VID: V01,  SN: FGL1734xxxxx

(vWLC) >show 802.11b cleanair air-quality 1602E
AQ = Air Quality
DFS = Dynamic Frequency Selection

Channel Avg AQ Min AQ Total Power (dBm) Total Duty Cycle (%) Interferer Power (dBm) Interferer Duty Cycle (%) Interferers DFS
——- —— —— —————– ——————– ———————- ————————- ———– —
1       98     98     -92               1                    -72                    2                         1

Conclusion
So what are the big differences between CleanAir and CleanAir Express? Well, from my experiences and from a functional standpoint there are no significant differences anymore since there is finally software which enables CleanAir Express. Because of it architecture CleanAir Express can only track up to three devices per radio (instead of 10) and it is somewhat a little slower, but for me that is now real deal breaker.

It is a pity that it took Cisco almost 2 years to enable it, but it is here and it does even more than the marketing people did told us upfront..  🙂

When using a WLC it is very easy to turn a access-point into a remote “sniffer” and let it send you captured data for a specify channel. A colleague of my asked if this was also possible for an autonomous access-point. I did not know a method to do this and also Google was not very helpful, so I decided to do some testing and did found a method to get the same results!

Autonomous access-points have a station-role called “scanner” which can be used in conjunction with the obsolete WLSE software. In this mode it sends raw captured data from the wireless spectrum to the WLSE for further analysis. Lucky for us Wireshark can also decode this packets. You have to configure your IPv4 address as destination and configure Wireshark to listen to this port and decode it as “CIWDS” (so not the PEEK type which has to be used with the WLC “sniffer” mode). From here one you can do whatever you want to do with the capture 😀

Int dot X
station-role scanner
monitor frames endpoint ip address 192.168.101.238 port 1337

For the majority of our customers I install Cisco Prime Infrastructure as “enhanced” monitoring tool for the wireless infrastructure. I say “enhanced” because the WLC itself does have a few monitoring features, but all of those are “real time” and not for historical purpose.

However, not all the customers need the features that Prime Infrastructure has to offer or they already have some “basic” network monitoring in place. In those cases it is sometimes handy to add the WLC in that monitoring, which is most of the times SNMP based.

There is always one question when it comes to SNMP; “what OID do I have to use to get information X?”. I wanted to monitor the total number of associated clients on a particular WLC, but found out that it is very hard to find the right OID for doing so. There is some Cisco documentation about SNMP monitoring on a WLC but thats more “advanced” monitoring.

It turned out to be OID .1.3.6.1.4.1.9.9.618.1.8.12.0 which returns the value as a “gauge”, if you also want to monitor the number of joined AP’s you can use OID .1.3.6.1.4.1.9.9.618.1.8.4.0. There you go! 🙂