CAPWAP QoS Configuration

[jason crockett]

Hello,

We have had several APs disassociating from our controllers. The alerts say, Message: Access Point 'AP-xxxxx' associated to controller '10.x.x.x' on port number '0'. Reason for association 'Dot11g Mode Change. I have read several posts that point out that you should have QoS implemented to prioritize the CAPWAP traffic. I'd like to know if someone has implemented QoS and whether it has been successful in stopping the APs from disassociating. And if it has been successful do you have any configuration examples for the ports attached to the AP and controller as well as the QoS configuration?

We have several sites with AP1142's and 3500's. We have 2 5508 controllers. We are broadcasting 2 SSIDs of which one is in HREAP mode and the other is in local mode. Each of our sites have MPLS circuits.

Here is an example I found on Cisco which I believe can be used for CAPWAP as long as you change the ports to 5246 & 5247 instead of 12222 & 12223. Has anyone tried this or something similar?

Example Router Configurations

This section contains router configuration examples to be used as guides when addressing CS6 remarking or LWAPP control traffic load.

This example uses LWAPP APs on the 192.168.101.0/24 subnet, and two WLCs with ap-managers at 192.168.60.11, and 192.168.62.11.

Remarking Client Generated CS6 Packets

The following shows a sample configuration for remarking LWAPP data packets marked as CS6 to a more appropriate value of CS3. This moves the traffic to a more suitable classification, at the level of call control, rather than at the level of network control.

class-map match-all LWAPPDATACS6

 match access-group 110

 match  dscp cs6 

!

policy-map LWAPPDATACS6

 class LWAPPDATACS6

  set dscp cs3

!

interface FastEthernet0

 ip address 192.168.203.1 255.255.255.252

service-policy input LWAPPDATACS6

!

access-list 110 remark LWAPP Data

access-list 110 permit udp 192.168.101.0 0.0.0.255 host 192.168.60.11 eq 12222

access-list 110 permit udp 192.168.101.0 0.0.0.255 host 192.168.62.11 eq 12222

access-list 111 remark LWAPP Control

access-list 111 permit udp 192.168.101.0 0.0.0.255 host 192.168.60.11 eq 12223

access-list 111 permit udp 192.168.101.0 0.0.0.255 host 192.168.62.11 eq 12223

Thanks!!!

[Justin Kurynny]

Jason,

I haven't implemented CAPWAP QoS, but reading your post has given me some food for thought. It does make sense that you'd want to give it some elevated treatment on the network. I would even go so far as to not remark it to cs3 and leave it at cs6 as I'd rather drop calls than drop whole APs off the network (the result of which could drop multiple calls). The cs6 designation is in line with network control traffic and that is exactly what CAPWAP is. The marking in your environment would largely depend on how mission critical your wireless traffic is.

As for setting this up, end-to-end QoS does require that you evaluate the platform-specific QoS implementation at each network hop along the way, making sure to set up your classification/trusts, maps and queuing properly.

As a side project, I'll need to do some Wireshark sniffs and look at my CAPWAP traffic again as I don't recall off hand if it comes out of the AP/WLC with cs6 marked. In any case, marking should be done as close to the traffic source as possible, so in this case, on the AP (for WLC-bound traffic) and on the WLC (for AP-bound traffic), and if we're not seeing the UWN components doing this for us, you'll want to set up policies (similar to what you've posted) to simply mark the traffic with cs3, cs6 or whatever suits your environment.

Justin

[grabonlee]

If I may add, I noticed the same alert message some days ago but it was as a result of a different matter. I have implemented PEAP/802.1x and integrated the 5508 WLCs with Cisco IPS. Whenever I applied IP source guard, the APs dissociated with the same alert that you mentioned above and later reassociated. However, the clients could no longer authenticate to the domain and had to shift to a PSK SSID that I also enabled.