Wired and Wireless QoS translations

It has been difficult for me to locate good QoS references in the past...  So at some point, I put together the following cheat sheet which will hopefully help others as well.  It's based on my interpretation of the current Cisco best practices, and since I do not work directly for Cisco - it's a bit of conjecture on my part.  Still, it seems to line up well and has not yet steered me wrong.

So, without further ado:

Wired to Wireless QoS Mappings

Cisco AVVID 802.1p UP-Based Traffic Type	Cisco AVVID IP DSCP	Cisco AVVID 802.1p UP	IEEE 802.11e UP (WMM AC)	Notes
Network Control	-	7	-	Reserved for network control only
Inter-Network Control	54	6	7 (AC_VO)	CAPWAP control WLC: Platinum QoS profile
Voice	46 (EF)	5	6 (AC_VO)	WLC: Platinum QoS profile
Video	32 (CS4)	4	5 (AC_VI)	WLC: Gold QoS profile
Voice Control	24 (CS3)	3	4 (AC_VI)	WLC: Gold QoS profile
Best Effort	0 (BE)	0	3 (AC_BE)	WLC: Silver QoS profile
			0 (AC_BE)
Background (Cisco AVVID Gold Background)	16 (CS2)	2	2 (AC_BK)	WLC: Bronze QoS profile
Background (Cisco AVVID Silver Background)	8 (CS1)	1	1 (AC_BK)	WLC: Bronze QoS profile

When APs don't register to a controller and have a static IP

I ran into an interesting problem last Monday (02/01/10) at work - someone had deployed APs at a remote location and configured them as autonomous APs. I performed a quick lightweight upgrade on them, and made the mistake of leaving static IPs on them.

The upgrade tool asks for your WLC address so I thought that would prime the APs with that address for the controller... Wrong. As soon as the APs booted to their lightweight IOS (the standard recovery image) I lost connectivity with them (no DHCP so option 43/60 is not available. APs are on a different domain than the switch - why it kept this but not snmp and passwords is irritating - so controller DNS didn't work). Passwords were of course reset, so telnet/ssh responded with "password required but none set." SNMP was also reset... I thought I had lost connectivity to them and would be required to ship out new APs!

In reviewing some of the Cisco literature, though, I found a cool little workaround. You can set the IP helper-address to the IP address of the controller, and then use the "forward protocol" command to forward all CAPWAP/LWAPP traffic to the IP helper-address, i.e. the controller (protocols 12222, 12223 for LWAPP and 5246, 5247 for CAPWAP)! Once connectivity was re-established to the APs, I set them to DHCP and removed the forward protocol commands and set the IP helper-address back to the DHCP server. Problem solved without sending new APs!