cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
998
Views
5
Helpful
4
Replies
Adam Swindell
Beginner

Wireless QoS - CAPWAP getting tagged DSCP 26 while inner packet is DSCP 24.

Hello,

I'm facing an issue regarding QoS and wireless. I've attached a drawing of my set up as well. 

My set up consists of a Cisco wireless 7925 phone, a 3702i access point, and a WISM2 controller (running newest 7.6 code). 

My access point is connected to a 3750 switch, the switchport is in access mode, and is trusting the dscp values from the access point (mls qos trust dscp). QoS is also enabled on the switch (mls qos). 

Please see my attached picture of a visual representation to what I'm going to describe. 

In my particular scenario I'm looking at SKINNY traffic between the phone and the call manager. Per our Wired QoS design SKINNY traffic is tagged with DSCP 24 or CS3.  Traffic from the call manager to the phone is being tagged correctly all the way through (from the wired segment, to the controller and from the controller to the access point) the inner packet and the CAPWAP header is tagged correctly with DSCP 24. 

Return traffic from the phone to the call manager is a different story. The phone is clearly tagging the SKINNY traffic with DSCP 24 as well, this is evident by looking at the inner packet in captures. However, the CAPWAP header is being tagged DSCP 26 for some reason. Basically it looks like the access point is building the CAPWAP header with the value of 26 despite the fact that the original packet is marked 24. 

I'd like to further understand why this is happening in only one direction (from AP to the controller) and if there is any way to change the behavior. 

One thing I might have stumbled on is how the 802.11e values map to DSCP values. Looking at the binary representations of 24 and 26, they both end up mapping back to the 802.11e value 3. My current thinking is the access point just sees this 802.11e value #3 and then tags it to 26 automatically instead of 24. I'm not sure why the access point can't read the correct DSCP value of the inner packet (being tagged by the phone) and simply map that same value to the CAPWAP header. 

 

Any help or further insight into this would be greatly appreciated. 

Thanks! 

1 ACCEPTED SOLUTION

Accepted Solutions
Rasika Nayanajith
VIP Mentor

Return traffic from the phone to the call manager is a different story. The phone is clearly tagging the SKINNY traffic with DSCP 24 as well, this is evident by looking at the inner packet in captures. However, the CAPWAP header is being tagged DSCP 26 for some reason. Basically it looks like the access point is building the CAPWAP header with the value of 26 despite the fact that the original packet is marked 24.

Note that when AP receives packet, it will only see the wireless header UP (user prioroity) value & not inner IP packet DSCP header. So all mapping of outer CAPWAP DSCP is based on UP value.  Refer this table & UP3 will map to AF31 (DSCP value 26)

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob73dg/emob73/ch5_QoS.html#_Ref167257742

I'd like to further understand why this is happening in only one direction (from AP to the controller) and if there is any way to change the behavior. 

When it comes from UCCM side, signaling traffic already marked with CS3. So when WLC map that to CAPWAP, it will simply use that IP packet DSCP value to derive the outer CAPWAP DSCP. So packet goes as CS3 in that direction.

If you want to change this behavior (client to AP-> WLC), you can apply a qos service policy to re-write DSCP26 to CS3 on your 3750 switch where AP connects.

http://mrncciew.com/2012/11/30/understanding-wireless-qos-part-2/

Refer this post from Jerome to see background of this AF31 or CS3 debate when classifying voice control traffic.

http://wirelessccie.blogspot.com.au/2011/02/wired-qos-for-voice-control-af31-dscp.html

 

HTH

Rasika

**** Pls rate all useful responses ****

View solution in original post

4 REPLIES 4
Rasika Nayanajith
VIP Mentor

Return traffic from the phone to the call manager is a different story. The phone is clearly tagging the SKINNY traffic with DSCP 24 as well, this is evident by looking at the inner packet in captures. However, the CAPWAP header is being tagged DSCP 26 for some reason. Basically it looks like the access point is building the CAPWAP header with the value of 26 despite the fact that the original packet is marked 24.

Note that when AP receives packet, it will only see the wireless header UP (user prioroity) value & not inner IP packet DSCP header. So all mapping of outer CAPWAP DSCP is based on UP value.  Refer this table & UP3 will map to AF31 (DSCP value 26)

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob73dg/emob73/ch5_QoS.html#_Ref167257742

I'd like to further understand why this is happening in only one direction (from AP to the controller) and if there is any way to change the behavior. 

When it comes from UCCM side, signaling traffic already marked with CS3. So when WLC map that to CAPWAP, it will simply use that IP packet DSCP value to derive the outer CAPWAP DSCP. So packet goes as CS3 in that direction.

If you want to change this behavior (client to AP-> WLC), you can apply a qos service policy to re-write DSCP26 to CS3 on your 3750 switch where AP connects.

http://mrncciew.com/2012/11/30/understanding-wireless-qos-part-2/

Refer this post from Jerome to see background of this AF31 or CS3 debate when classifying voice control traffic.

http://wirelessccie.blogspot.com.au/2011/02/wired-qos-for-voice-control-af31-dscp.html

 

HTH

Rasika

**** Pls rate all useful responses ****

View solution in original post

Great response Ras .. Looks like I still have endorsement ! +5

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

Thanks George,

Good to see you still get time to read our responses (even 1-2 weeks old post) & see some value in it (even in situations where originator of the post does not see that)

Good you still have that entitlement as well.

Rasika

Ive learn a lot from you my friend. A lot of your post are keepers. 

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________
Content for Community-Ad