Wireless Quality of Service Deployment Guide [©2003]

Cisco's "Wireless Quality-of-Service Deployment Guide" ©2003 [I've never seen this doc before!]


I stumbled across this crazy old document from 2003 outlining using QoS on VxWorks APs! I don't think much has changed in the way of WLAN QoS - at least not the fundamentals.  I'm hoping this will help make the QoS grooves in my brain deeper and more permanent.

Nice [old] graphics of 7921 and call admission control

I found this preso today when I was looking for more background info on ADDTS/TSPEC and the 7921

From ccie(w)

From ccie(w)

From ccie(w)

QoS Policies on Autonomous APs

So after some digging, I think I might have this figured out.

The AP config guide has a section on giving priority to Voice traffic, but it doesn't show the CLI alternative to the GUI configuration section in the guide:
Cisco IOS Software Configuration Guide for Cisco Aironet Access Points, 12.2(13)JA
Giving Priority to Voice Traffic
The 7921 Deployment guide only gives you the CLI commands "best practices" for the 7921, but doesn't say which to which interface(s) the service-policy should be applied:

Cisco Unified Wireless IP Phone 7921G Deployment Guide
Configuring QoS Policies for the Network (page 19)

class-map match-all RTP
 match ip dscp ef
class-map match-all SCCP
 match ip dscp cs3
policy-map Voice
 class RTP
 set cos 6
class SCCP
 set cos 3
interface X
 service-policy input Voice
 service-policy output voice

Putting both config guides together results in this:

class-map match-all RTP
 match ip dscp ef

class-map match-all SCCP

 match ip dscp cs3

policy-map Voice

 class RTP

 set cos 6

class SCCP

 set cos 3
!
interface Dot11Radio1.150 <-this is the radio sub-interface for the Voice SSID/VLAN

 encapsulation dot1Q 150
 service-policy input Voice

 service-policy output Voice
 no ip route-cache
 bridge-group 150
 bridge-group 150 spanning-disabled
!
interface FastEthernet0.150 <-this is the ethernet sub-interface for the Voice SSID/VLAN
 encapsulation dot1Q 150
 service-policy input Voice
 no ip route-cache
 bridge-group 150
 bridge-group 150 spanning-disabled
------------------------

QoS Policy on switch/router with AP needing Voice prioritzation connected:
ip access e SCCP
  p t any eq 2000 any
  p t any any eq 2000
ip access e RTP
  p u ay range 16384 32767 any
  p u any any range 16384 32767
class-map match-all SCCP
  match acc name SCCP
class-map match-all RTP
  match acc name RTP
policy-map voice
  class RTP
   set dscp ef
  class SCCP
   set dscp cs3
int <-interface with IOS AP (no LWAPP traffic)
service-policy input voice
---------------------------------------
dot11 ssid voice
vlan 150
auth op eap eap_methods
auth ne eap_methods
auth ke wpa
admit-traffic <-shown in 7921 guide "Call Admission Control Settings"

QoS Example LAN Switch Configuration (from Enterprise Mobility 4.1 Design Guide)

QoS Example LAN Switch Configuration

AP Switch Configuration

The QoS configuration of the AP switch is relatively trivial because the switch must trust the DSCP of the LWAPP packets that are passed to it from the AP. There is no CoS marking on the LWAPP frames coming from the AP. The following is an example of this configuration. Note that this configuration addresses only the classification, and that queueing commands may be added, depending on local QoS policy.

interface GigabitEthernet1/0/1

switchport access vlan 100

switchport mode access

mls qos trust dscp

spanning-tree portfast

end

In trusting the AP DSCP values, the access switch is simply trusting the policy set for that AP by the WLC. The maximum DSCP value assigned to client traffic is based on the QoS policy applied to the WLANs on that AP.

WLC Switch Configuration

The QoS classification decision at the WLC-connected switch is a bit more complicated than at the AP-connected switch, because the choice can be to either trust the DSCP or the CoS of traffic coming from the WLC. In this decision there are a number of points to consider:

•Traffic leaving the WLC can be either upstream (to the WLC or network) or downstream (the AP and WLAN client). The downstream traffic is LWAPP encapsulated, and the upstream traffic is from AP and WLAN clients, either LWAPP encapsulated or decapsulated WLAN client traffic, leaving the WLC.

•DSCP values of LWAPP packets are controlled by the QoS policies on the WLC; the DSCP values set on the WLAN client traffic encapsulated by the LWAPP tunnel header has not been altered from those set by the WLAN client.

•CoS values of frames leaving the WLC are set by the WLC QoS policies, regardless of whether they are upstream, downstream, encapsulated, or decapsulated.

The following example chooses to trust the CoS of settings of the WLC, because this allows a central location for the management of WLAN QoS, rather than having to manage the WLC configuration and an additional policy at the WLC switch connection. Other customers wishing to have a more precise degree of control may wish to implement QoS classification policies on the WLAN-client VLANs.

interface GigabitEthernet1/0/13

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 11-13,60,61

switchport mode trunk

mls qos trust cos

end

 

Voice over Wireless LAN 4.1 Design Guide - auto-qos notes

Infrastructure QoS Configuration

"This section shows sample QoS configurations for switch interfaces used in the campus network. More configuration details for all the switches and routers used in this design guide is available in theAppendix , "Voice over WLAN Campus Test Architecture," testing section of this guide.

Table 10-2 shows interface commands on a Cisco 3750G access-layer switch used to connect an IP Phone. The Auto-QoS configuration statement is shown in red and the statements generated by Auto-QoS follow it."

From ccie(w)

Table 10-3 shows interface commands on a Cisco 4503 access-layer switch used to connect an AP. The Auto-QoS configuration statement is shown in red and the statements generated by Auto-QoS follow it.

From ccie(w)

Table 10-4 shows interface commands on a Cisco 4503 access-layer switch used as an uplink port to a distribution-layer switch. The Auto-QoS configuration statement is shown in red and the statements generated by Auto QoS follow it.

From ccie(w)

QoS commands from the 7921 deployment guide

QoS Commands for Autonomous Access Points

class-map match-all RTP
 match ip dscp ef
class-map match-all SCCP
 match ip dscp cs3

policy-map Voice
 class RTP
 set cos 6
class SCCP
 set cos 3

interface X
 service-policy input Voice
 service-policy output voice

IOS Router inerface to map RTP and SCCP correctly

ip access-list extended SCCP
 permit tcp any eq 2000 any
 permit tcp any any eq 2000

ip access-list extended RTP
 permit udp any range 16384 32767 any
 permit udp any any range 16384 32767

class-map match-all SCCP
 match access-group name SCCP
class-map match-all RTP
 match access-group name RTP

policy-map Voice
 class RTP
 set dscp ef

 class SCCP
 set dscp cs3

interface X
 service-policy input Voice
 service-policy output Voice

WLW 013 – CWNP Program / RFID WLAN Designs

http://wlanpros.com/wlw013

additional links to complement episode 13..  I realized that I'd left a lot out when I played back what I'd said about the project I was working on..


The Cisco LBS accuracy is stated as being within 10 meters 90 percent of the time
Wi-Fi Location-Based Services 4.1 Design Guide
Recommendation for re-calibration semi-annually in an active logistics shipping & receiving area
Minimum signal level thresholds
Access point placement
Tips for successful (client) calibrations

"First and foremost, it should be clearly understood that 802.11b asset tags that transmit tag messages using Layer 2 multicasts (and do not attempt to associate to any WLANs) will not cause the initiation of any 802.11g protection modes under any circumstances. This includes asset tags operating in strict compliance with version 1 of the Cisco Compatible Extensions"

WiSM Configuration steps

So it has been a while since I setup a WiSM from scratch.  I was trying to do it strictly from memory.. and I totally forgot that each of the WLCs on the WiSM need to be put into their own port channel.

If you put all the giX/X interfaces into one great big port channel, neither management interface will be "pingable" by the 6500 that the WiSMs are in, but that vlan interface will be up/up and all other devices in that vlan will be reachable.  Even "show wism status" doesn't show that there is a problem..

Word to the wise - re-read all the configuration guides & quick start guides for WiSMs and WLCs.

Troubleshoot and Configure Initial Wireless Services Module (WiSM) Setup

The difference between L2 and L3 Roaming Events

Taken from the Deployment Guide for Cisco Guest Access Using the Cisco Wireless LAN Controller, Release 4.1

Layer 2 Roam:

A Layer 2 roam occurs when a client leaves one AP and re-associates with a new AP, in the same client subnet. In most cases, the 'roamed to' AP is connected to the same WLC as the original AP.  The description above represents the simplest roaming scenario because a single WLC database maintains all information about the client. Network elements upstream from the WLC are unaffected by the client moving from one AP to another.
Layer 2 Roam Illustration:

 L3 Roam - WLC to WLC Roaming Across Client Subnets:

In cases where a client roams between APs that are connected to different WLCs and the client subnet/VLAN is not the same between the WLCs, then a Layer 3 roam is performed. A mobility announcement is exchanged between the 'roamed to' (foreign) WLC's mobility database and the home (anchor) WLC's mobility database.

A Layer 3 roam is more complex because the wireless client is moving from one VLAN/subnet to another. Unless the WLAN system takes action to make the client subnet change transparent, the Layer 3 roam event has an adverse impact on client communication with upstream services. Existing client sessions will either hang or eventually timeout and disconnect. The Cisco Unified Wireless solution uses mobility tunnels to facilitate Layer 3 roaming that is transparent to the upstream network There are two types of mobility tunnels:

•Asymmetrical (default behavior - WLC Releases 4.0 and earlier)

•Symmetrical (new option beginning with WLC Release 4.1 and later)

Note In WLC Release 4.1, asymmetrical tunneling is still the default behavior. Administrators must explicitly configure symmetrical tunnel behavior.
L3 Roam Across Subnets Illustration:

Layer 3 Roam—Symmetrical Mobility Tunnel:

Beginning with WLC Release 4.1 and later, the WLCs can be configured to support dynamic, bi-directional tunneling between the foreign AP/WLC and the anchor WLC.  The WLC's Layer 3 mobility handoff procedure remains unchanged. However, WLC Release 4.1 makes use of existing capabilities associated with the solution's auto anchor tunneling mechanism to create a dynamic symmetrical tunnel when a client performs a Layer 3 roam. Symmetrical tunneling is not enabled by default. It must be explicitly configured either through the controller's web configuration interface, WCS template or the controller's CLI. Symmetrical mobility tunnel operation must be enabled for each controller that is a member of a given mobility group, otherwise unpredictable behavior can occur.

L3 Symmetric Mobility Roam Illustration: