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)

Color coded QoS chart from the Voice over Wireless LAN 4.1 Design Guide

I like the QoS  charts that are in this chapter of the design guide, but the chart runs of the page and isn't color coded like the nice QoS charts from Cisco Live BRKRST-2500 Campus QoS Design.




The LWAPP AP and WLC perform QoS baseline conversion, so that WMM values as shown below are mapped to the appropriate QoS baseline DSCP values, rather than the IEEE values.

From ccie(w)

In cases where the AP is translating CoS values, autonomous APs for example, the translation shown is below:

From ccie(w)

WMM uses the 802.1p classification scheme developed by the IEEE (which is now a part of the 802.1Q-2005 specification).  This classification scheme has eight priorities, which WMM maps to four access categories: AC_BK, AC_BE, AC_VI, and AC_VO. These access categories map to the four queues required by a WMM device.
 

From ccie(w)

... It is generally recommended that the Per-User Bandwidth Contracts settings be left at their default values, and that the IEEE 802.11 WMM features be used to provide differentiated services. For WLANs using a given profile, the IEEE 802.1P classification in that profile controls two important behaviors:

• Determines what class of service (CoS) value is used for packets initiated from the WLC.  The CoS value set in the profile is used to mark the CoS of all LWAPP packets for WLAN using that profile. So a WLAN with a platinum QoS profile, and the IEEE 802.1P mark of 6, will have its LWAPP packets from the ap-manager interface of the controller marked with CoS of 5. The controller adjusts the CoS to be compliant with Cisco QoS baseline recommendations. The reason why it is important to maintain the IEEE CoS marking in the configuration is covered in the next point. If the network is set to trust CoS rather a DSCP at the network connection to the WLC, the CoS value determines the DSCP of the LWAPP packets received by the AP, and eventually the WMM classification and queuing for WLAN traffic, because the WLAN WMM classification of a frame is derived from the DSCP value of the LWAPP packet carrying that frame.

• Determines the maximum CoS value that can be used by clients connected to that WLAN.
  The IEEE 802.1P classification sets the maximum CoS value that is admitted on a WLAN with that profile. WMM voice traffic arrives with a CoS of 6 at the AP, and the AP automatically performs a CoS-to-DSCP mapping for this traffic based on a CoS of 6. If the CoS value in the WLC configuration is set to a value less than 6, this changed value is used by the WLAN QoS profile at the AP to set the maximum CoS marking used and therefore which WMM AC to use. The key point is that with the Unified Wireless Network, you should always think in terms of IEEE 802.11e classifications, and allow the Unified Wireless Network Solution to take responsibility for converting between IEEE classification and the Cisco QoS baseline.

This is the chart from the QoS class at Cisco Live 2009 [QoS on Cisco switches]:

From ccie(w)

There was also a nice colorized chart explaining the packet tagging translation that occurs to and from the client device at the controller.  This image is from BRKAGG-2013 Design and Deployment of Voice over Wireless LAN.

From ccie(w)

Configuring Access Layer QoS for Voice on Cisco Catalyst 6500 with Cisco IOS SW

mls qos
! -- turns QOS on for the whole switch
mls qos map cos-dscp 0 8 16 24 32 46 48 54
! -- maps COS to DSCP using the new standards of CS3 for signaling.
interface fastethernet 5/1
! -- the interface of course
switchport mode access
! -- disable trunking
switchport voice vlan 111
! -- enable trunking when CDP detects a phone. This is called DTP or Dynamic Trunking Protocol.
switchport access vlan 11
! -- set the VLAN for the phones built in switch for the PC on the other side of the phone or for the PC when no phone is detected.
spanning-tree portfast
! -- disable the slow detection of loops with spanning tree. This is a single endpoint and should never have a switch connected to it.
mls qos trust cos
! -- trust the COS of the traffic from the phone
mls qos trust extend cos 0
! -- mark all traffic from the PC to COS 0 no matter what the PC says it should be.

------------------------------

In depth configuration of a "full trust" policy for phones connected to a 6500:

Excerpt below taken from: Configuring Access Layer QoS for Voice on Cisco Catalyst 6500 with Cisco IOS SW

CONFIGURATION OVERVIEW

This sample configuration implements one of several methods to provide QoS at the access layer of an IP Communications deployment. Specifically this configuration is limited to a "full trust" policy on the switch interface. The "full trust" policy assumes a Cisco IP Phone (from Table 3) will be connected to the port to which this policy is applied, as the IP phone is responsible for remarking the PC traffic to CoS = 0. If a PC is instead directly connected to an interface with "full trust" policy, and its traffic is untagged, the switch marks the traffic CoS = 0. However, if the directly connected PC is marking its traffic with a CoS value, the switch accepts it because the port is configured to trust any received CoS. A "conditional trust" policy may be used as an alternative to reduce this possible risk. Though supported on several other Cisco Catalyst switch platforms, Cisco IOS Software for the Cisco Catalyst 6500 does not currently support the mls qos trust device cisco-phone command, which is the simplest method to implement a "conditional-trust" policy. Please see other Cisco documentation for more information regarding "conditional trust" policy configuration.

For the Cisco Catalyst 6500 to act as an access switch for a Cisco 7940/7960/7970 IP phone + PC, using a "full trust" policy, the following is required:

1. Enable switchwide QoS.

2. Configure interfaces used for IP phones:

• Enable trust so the switch accepts the phone class-of-service (CoS) markings.

• Extend the trust boundary to the access port on the IP phone and mark PC traffic as CoS = 0.

• Enable input queue scheduling.

• Configure CoS-to-queue mapping.

• Configure output scheduling.

• Configure CoS-to-differentiated services code point (DSCP) mapping.

• Optionally configure a policy for additional application traffic marking or policing (not covered).

3. Configure the uplink interfaces to the distribution switch:

• Enable trust to accept markings from the distribution switch. This can be either CoS or DSCP trust.

• Enable input queue scheduling.

• Configure CoS-to-queue mapping.

• Configure output scheduling.

• Verify and configure CoS-to-DSCP mapping.

• Optionally configure a policy for additional application traffic marking or policing (not covered).

ENABLING QoS ON THE SWITCH

To enable QoS on the access layer Cisco Catalyst 6500, do the following:

Enable switchwide QoS:

6509-Access(config)#mls qos

CONFIGURING AN INTERFACE FOR IP PHONE + PC

As stated previously, the access port configuration depends on the module in use. All of the 10/100 Ethernet series modules in Tables 1 and 2 have 1Q4T receive and 2Q2T transmit queue architectures. For modules in Table 1 the port is configured to trust the IP phone and not to trust the PC attached to the phone. For modules in Table 2 a workaround is used because these modules are unable to "trust" the CoS of incoming traffic. The workaround consists of using an access-control-list (ACL) policy to retain the CoS of the traffic. An access port also is configured to use output scheduling through multiple transmit queues.

To configure the interface for a module in Table 1,do the following:

Step 1. Select a port to configure.

6509-Access(config)#interface fastethernet 5/1

Step 2. Configure the port as a Layer 2 port in the access mode.

6509-Access(config-if)#switchport

6509-Access(config-if)#switchport mode access

Step 3. Define the voice VLAN.

6509-Access(config-if)#switchport voice vlan 111

Step 4. Define the data VLAN.

6509-Access(config-if)#switchport access vlan 11

Step 5. Configure the port as a host port.

6509-Access(config-if)#spanning-tree portfast

Step 6. Enable inline power.

6509-Access(config-if)#power inline auto

Step 7. Accept the incoming Layer 2 CoS. This lets the switch accept the phone marking of voice traffic at CoS = 5 and voice control traffic at CoS = 3 and enables input scheduling.

6509-Access(config-if)#mls qos trust cos

Step 8. Instruct the IP phone to rewrite the PC traffic to CoS = 0.

6509-Access(config-if)#mls qos trust extend cos 0

Step 9. Place CoS = 1 in queue 1 threshold 1.

6509-Access(config-if)#wrr-queue cos-map 1 1 1

Step 10. Place CoS = 0 in queue 1 threshold 2.

6509-Access(config-if)#wrr-queue cos-map 1 2 0

Step 11. Place CoS = 2, 3, 4, 6, and 7 in queue 2 threshold 1.

6509-Access(config-if)#wrr-queue cos-map 2 1 2 3 4 6 7

Step 12. Place CoS = 5 in queue 2 threshold 2.

6509-Access(config-if)#wrr-queue cos-map 2 2 5

Step 13. Modify the CoS-to-DSCP mapping. The recommended settings are DSCP = CS3 (24) for voice-over-IP (VoIP) control and DSCP = EF (46) for VoIP media traffic. To map the Layer 2 CoS correctly to these DSCP values, you must modify the switch default CoS-to-DSCP mappings. All CoS are shown though only 0, 3, and 5 are directly related to IPT.

6509-Access(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 54

Note: CoS 3 and 5 are the 4th and 6th values, respectively.

To configure an interface on the modules listed in Table 2 do Steps 1 through 13 plus configure the following additional commands:

Step 1. Create an access list to match all traffic.

6509-Access(config)#access-list 100 permit ip any any

Step 2. Create a class for this traffic.

6509-Access(config)#class-map TRUST_COS_CLASS

6509-Access(config-cmap)#match access-group 100

6509-Access(config-cmap)#exit

Step 3. Create a policy to trust the CoS for the traffic in the class.

6509-Access(config)#policy-map TRUST_COS_POLICY

6509-Access(config-pmap)#class TRUST_COS_CLASS

6509-Access(config-pmap-c)#trust cos

6509-Access(config-pmap-c)#exit

Step 4. Apply the policy to the interface.

6509-Access(config)#int fa5/1

6509-Access(config-if)#service-policy input TRUST_COS_POLICY

CONFIGURING THE UPLINK TO THE DISTRIBUTION SWITCH

After you configure the access port queuing, you must also configure the uplink interfaces to the distribution, or core, switch. This involves enabling trust for Ethernet frames coming into the trunk port, enabling output scheduling, and manipulating the CoS-to-queue mapping entrance criteria, mapping the CoS values to the appropriate DSCP value.

This section includes information for two of the six types of queue structures: 1P2Q2T and 2Q2T.

Configuring an Uplink Port

Step 1. Accept incoming DSCP markings if incoming traffic is known to be properly marked at Layer 3. This is the preferred method.

6509-Access(config-if)#mls qos trust dscp

Alternate Step 1. Accept incoming CoS markings if incoming traffic is known to be properly marked at Layer 2 only.

6509-Access(config-if)#mls qos trust cos

Optional Step 2 (required when trusting CoS) Verify CoS-to-DSCP mapping. This should have been set in Step 10 in the interface configuration. Map CoS = 5 to DSCP = EF (46) and CoS = 3 to DSCP = CS3 (24).

6509-Access(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 54

Configuring Transmit Queues

All CoS = 5 traffic (VoIP media) is placed into the egress interface priority queue on 1P2Q2T interfaces and queue 2 threshold 2 on 2Q2T interfaces by default upon enabling switchwide QoS. To follow QoS best practices, additional configuration of the CoS queue admission rules is needed to ensure that all other CoS traffic, and most importantly CoS = 3 (VoIP control), is placed into the correct queue. Separate configurations follow for 1P2Q2T and 2Q2T interfaces. For configuration of different interface queue structures, refer to other Cisco Catalyst 6500 QoS documentation.

CCIE Wireless Lab Exam Topics (Blueprint) (as of 12/9/09)

Exam Sections and Sub-task Objectives   
   
1    Implement network infrastructure to support WLANs
1.01    Implement Catalyst configuration (VLANs, VTP, STP, Trunk, Portchannel,LB..)
1.02    Implement network connectivity in WLC
1.03    Implement network connectivity in LAP (local mode, hreap + local switching)
1.04    Implement network connectivity in AP (multiple vlans, vs single vlan)
1.05    Configure client to connect/authenticate to SSIDs
1.06    Implement DNS, DHCP, NTP
1.07    Implement QoS to support voice services over the switching infrastructure
1.08    Implement basic IP routing
1.09    Troubleshoot network infrastructure to support Wireless

2    Implement Autonomous Infrastructure
2.01    Configure WDS
2.02    Implement local radius
2.03    Implement SSID/MBSSID as needed: Security policies and Bridging groups
2.03    (a) Security policies
2.03    (b) Bridging groups
2.04    Implement radio roles
2.05    Implement antenna settings
2.06    Implement association filters
2.07    Implement and control management access
2.08    Implement MFP
2.09    Implement multicast settings
2.1    Implement QOS
2.11    Implement peer to peer blocking
2.12    Troubleshoot bridge connectivity problems
2.13    Convert Autonomous to LWAP

3    Implement Unified Infrastructure
3.01    Implement Interface settings
3.02    Implement mobility groups
3.03    Implement WLANs
3.04    Implement multicast settings
3.05    Implement and control management access
3.06    Implement controller redundancy/fallback
3.07    Implement discovery mechanisms
3.08    Implement AutoRF to adapt to site requirements
3.09    Check and validate current channel/power settings
3.1    Validate trap generation, notifications in WCS/WLC

4    Implement Unified Controllers and AP's
4.01    Implement peer to peer blocking
4.02    "Implement Security
4.02    (a) WPS settings
4.02    (b) MFP/AP authentication
4.02    (c) AP authorization"
4.03    Implement QOS
4.04    Implement local EAP authentication (against local user list, and external LDAP)
4.05    Implement L3 security policies (Webauth, pass-through)
4.06    Implement wired and wireless Guest
4.07    Implement L2 security policies (802.11i, static dynamic WEP, mac filtering, etc..)
4.08    Implement Local DHCP services for clients
4.09    Implement AAA (WLC to Radius/LDAP)
4.1    Troubleshoot client connectivity problems

5    Implement Unified WCS and Location
5.01    Implement controllers to WCS
5.02    Create and deploy template, template groups
5.03    Prepare building/floor map
5.04    Create floor coverage proposal
5.05    Implement location server
5.06    Tune location services given needs (tag tracking, notifications, timers)
5.07    Validate client connectivity/troubleshoot client via WCS/WLC
5.08    Validate location information in WCS/WLC
5.09    Validate security events with WCS/WLC
5.1    Validate location information in WCS/WLC
5.11    Validate trap generation, notifications in WCS/WLC
5.12    Validate client connectivity/troubleshoot client via WCS/WLC

6    Implement Voice over Wireless
6.01    Implement support for 7920/7921 deployments, for both Unified and Autonomous
6.02    Implement QoS settings:
6.02    (a) Voice/Video
6.02    (b) EDCA
6.03    Audit voice deployment

792X and Client Roaming

[notes]
Client roaming – values are communicated to CCX compliant clients.  may be a little low for a VoWLAN deployment, as VoWLAN cell sizes are usually smaller.

Voice call admission control – default value for Max Bandwidh = 75%

For best performance, the most accurate assessment of call capacity; Load Based AC should be enabled.
    Max RF Reservation should not be greater than 60% - set at 40-60%

Troubleshooting – WCS is best place to start

DHCP option 150 = TFTP server for phone firmware

To reset the phone to factory defaults = **2
To unlock the phone configuration = **#

7921s do not support WPA2 with TKIP
7921s support WPA2 with AES, but CCKM is not supported

ACS must be configured to explicitly support EAP-FAST authentication.  7921g supports only the automatic provisioning of the PAC, so Anonymous In-Band PAC Provisioning must be enabled.

If a 7921 phone has both radios enabled:
-    if default AUTO-RSSI is enabled, the phone will associate to the strongest RSSI on bootup
-    if auto b/g or auto a is enabled, the phone will connect to auto setting and will fall back to non specified frequencies if the specified frequency is unavailable.  If the phone has associated to an AP on a particular band, it will only scan for & roam to APs on the same frequency band.
 

VoWLAN Design Guide 4.1

[notes]
VoWLAN Design Guide 4.1



U-APSD – the primary benefit is that it allows the voice client to synchronize the transmit and receive of voice frames with the AP, thereby allowing the client to go into power-save mode between the transmit and receive of each voice frame tuple.


The use of U-APSD allows the use of long DTIM intervals to maximize standby time without sacrificing call quality (also increases call capacity)

Client in power save detects data waiting for it at the AP via the presence of a TIM in the AP beacon. The client PS-polls the AP to get the data


     There are two major problems with this:
        1. Requiring PS-polls on top of the normal data exchange to go through the standard access delays associated with DCF.
        2. Retrieving the buffered data is dependent on the DTIM, which is a multiple of the beacon interval. Standard beacon intervals are 100ms, DTIM intervals can be integer multiples of this.

The AP sends data to the client as a TXOP burst where only the first frame has the EDCF access delay.
      - timing of the polling is controlled via the client. Jitter introduced is symmetric rather than N x 100ms

TSpec allows an 802.11e client to signal its traffic requirements to the AP. It can also be used to control the use of various ACs in EDCF. The use of EDCF ACs rather than HCCA to meet TSpec requests is possible in many cases because the traffic parameters are sufficiently simple to allow them to be met by allocating capacity rather than creating a specific TXOP to meet the application requirements.

QoS Basis Service Set (QBSS) is an IE element advertised by the Cisco AP. The load field indicates the portion of available bandwidth currently used to transmit data on the AP.


1 octet 1 octet 4 bytes
ELEMENT ID (11) LENGTH LOAD


There are three QBSS IEs that need to be supported in certain situations

• Old QBSS (draft 6 pre-standard)
• New QBSS (draft 13 IEEE 802.11e (standard))
• New distributed cac load IE (a Cisco IE)

**The various QBSS IEs use the same ID, and therefore the three QBSSs are mutually exclusive. For example, the beacons and probe responses can contain only one QBSS IE.


The QBSS used depends on the WMM & 7920 phone settings on the WLAN.
      Client CAC limit – supports legacy 7920 code pre v2.01
      AP CAC limit -7920 settings are learned from the WLAN advertisement

Enabling admission control determines how much AP bandwidth will be set aside for voice clients attempting to roam to the AP. This is based on the APs capacity, not factoring in the possible channel loading impact of other APs in the area. Load Based ac uses channel load in capacity calculations.

TSpec admission control is used to protect high priority resources, not to deny clients access to the WLAN.


L2 LWAPP does not effectively support QoS because the AP does not send the 802.1p/q tags and in L2 LWAPP there is not an outer DSCP on which to fall back because the AP no longer uses NULL VLAN ID
      - APs carry out EDCF-like queuing on radio egress
      - APs do FIFO on the Ethernet egress

Call capacity assuming no competing high priority WLAN traffic & normal background noise:
      - 14 simultaneous call son 2.4ghz
      - 20 simultaneous call son 5ghz

WLAN QoS is performed AFTER the CCA.

Standard office environment – AP client RADIUS of 43 feet, co-channel interference RADIUS of 150 feet using 2db gain antennas and a power output of 16dbm (40mw)

VoWLAN & 5ghz – generally recommended to use the lower 4 channels & upper 4 channels. These channels do not require the use of DFS or TPC.
      UNII-1: 36, 40, 44, 48
      UNII-2: 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140
      UNII-3: 149, 153, 157, 161


show {IEEE 802.11a | IEEE 802.11bg} L2 roam RF-params
show {IEEE 802.11a | IEEE 802.11bg} L2 roam statistics [AP-MAC]
show client roam-history [client-MAC]

EIGRP – two main route summarization ways in campus test architecture = route summarization & stub
      reduce EIGRP hello/dead timers to 1 & 3 seconds (hello = 1 & dead = 3) rather than the default timers of 5 & 15


QoS policing – check on classification using port trust state & policy maps being mutually exclusive in 2970, 3560, and 3750s


Deployment models for Cisco Unified Communication Manager
number of call processing agent clusters
number of IP phones
location of the call processing clusters & IP phones

For voice traffic, it is better to deny network access under congestion conditions that to allow traffic to be dropped or delayed.

QoS protects voice from being overrun by data
CAC protects voice from voice
CAC topology unaware – based on static configuration
CAC topology aware – based on communication between call processing agent & the network about available resources – uses Resource Reservation Protocol (RSVP)

VoWLAN

[notes]
VoWLAN

Recommendation to place all antennas 1 to 2 wavelengths from highly reflective surfaces.
2.4Ghz = 4.92 inches (12.5 cm)

• 5GHz = 2.36 inches (6 cm)

The human head and body attenuates 5db of RF signal
If the antenna is in the body of the phone, the loss ~ 4db – 9db

Handsets do not have diversity antennas due to the length of the 2.4ghz wavelength distance (4.92in)

802.11A handsets do have a diversity antenna solution

DFS, 802.11h

When radar is detected:

• stop packet transmission within 200ms
• stop control transmission within 10 seconds
• avoid transmitting on the channel for 30 minutes
• scan a new channel for 60 seconds before transmitting

Cisco recommends that for voice apps, the cell edge be determined by using the actual phone at the desired data rate.

Voice packets sent between the AP and the phone are generally unicast RTP G711 packets with a typical size of 236 bytes.

Cisco recommends all APs have a maximum transmission power of 13dBm.

A call between two phones associated to the same AP counts as two active voice streams.

Guest anchor WLC – can support EoIP tunnels from 40 WLCs and supports 2500 simultaneous users and has forwarding capacity of 2gbps.

Multicast is not supported over guest tunnels.

One additional port number can be monitored for redirection: network web-auth-port

My trouble spots

From the CCIE Wireless Lab Exam Blueprint v1.0 (login required)

I already know my trouble spots are these:
Implement network infrastructure to support WLANs

• Implement QoS to support voice services over the switching infrastructure

Implment Autonomous Infrastructure

• Configure WDS
• Implement association filters
• Implement multicast settings
• Implement QoS

Implement Unified Infrastructure

• Implement multicast settings

Implement Unified Controllers and APs

• Implement security - WPS settings
• Implement security MFP/AP authentication
• Implement wired and wireless Guest access
• Implement L2 security policies (802.11i, static dynamic WEP, mac filtering etc..)
• Implement AAA (WLC to Radius/LDAP

Implement Unified WCS and Location

• Create and deploy template groups
• Implement loation server
• Tune location services given needs (tag tracking, notifications, timers)

Implement Voice over Wireless

• Implement support for 7920/7921 deployments for both Unified and Autonomous
• Implement QoS settings (voice/video/EDCA)
• Audit voice deployment