Tags
In this post we will look at how to configure QoS for a switch port where H-REAP is connected. In this example we are considering H-REAP local switching scenario & normally a switch port is configured as Trunk port to facilitate this. Here is the basic set up for this post.
Here is the switch port configuration of H-REAP & Wireshark PC.
R3750# interface FastEthernet1/0/4 switchport trunk encapsulation dot1q switchport trunk native vlan 50 switchport trunk allowed vlan 50,146 switchport mode trunk spanning-tree portfast trunk ! interface FastEthernet1/0/7 switchport trunk encapsulation dot1q switchport mode trunk ! monitor session 1 source interface Fa1/0/4 monitor session 1 destination interface Fa1/0/7 encapsulation replicate
So what should you trust to give better QoS, CoS or DSCP ? Let’s see what’s best suit in this scenario by looking at the packet capture of H-REAP connected switch port (Fa 1/0/4). Let’s look at two different traffic type (management & user traffic).
Here is CAPWAP control (udp 5246) traffic coming from H-REAP. As you can see there is no layer 2 tag (as Vlan 50 is native vlan on the trunk link) & hence no QoS information in the layer 2 header packet coming from H-REAP (192.168.50.52), though original IP packet is having CS6 DSCP value.
Here is a data packet coming from wireless phone. As you can see that packet include layer 2 tag (VLAN 146) which include CoS (or priority) value for QoS. In this case RTP traffic marked to CoS value 5.
Now, if you considering trusting CoS value for the switch port (Fa 1/0/4) connected to H-REAP all you control traffic marked with default CoS 0 (as no QoS value comes in layer 2). All other tagged vlan traffic will trust CoS value coming in those frames.
On the other hand if you trusting DSCP for Fa 1/0/4, then both management traffic & user traffic will get prioritized based on original packets DSCP value (ignoring AP imposed CoS value for tagged frame).
Therefore you have to trust DSCP if you want to provide QoS for ALL traffic coming from H-REAP which include management traffic & user traffic.
R3750(config-if)#do sh run int fa1/0/4
interface FastEthernet1/0/4
switchport trunk encapsulation dot1q
switchport trunk native vlan 50
switchport trunk allowed vlan 50,146
switchport mode trunk
mls qos trust dscp
spanning-tree portfast trunk
Now we will look how a packet capture with different QoS profile (Platinum, Gold, Silver, Bronze). In the above RFC-3580 WLAN QoS profile was set to Platinum. Let’s change it to Silver & see a packet capture. As expected in this time layer 2 CoS value is capped as per the Silver Profile, even though layer 3 DSCP is EF.
Since we are trusting DSCP packet will get the EF priority irrespective of the layer2 CoS value. So it is very important to understand we cannot keep AP imposed QoS (based on QoS-Profile) preserved in this scenario (trust DSCP) unless you trust CoS on that switch port. If you trust CoS then no way of giving required QoS for management traffic coming from H-REAP(since those are un-tagged).
If you consider H-REAP central switching scenario, still you have to trust DSCP in order to preserve outer CAPWAP information for H-REAP to WLC communication.
So in conclusion what should you trust in H-REAP deployment, answer is IT DEPENDS.
1. If you want to classify ALL traffic (management & user traffic) based on the packet DSCP value then you have to trust DSCP at the switch port. In this case AP imposed QoS (based on WLAN QoS profile value) will be not enforced as switchport is trusting DSCP & not CoS.
2. If you are considering only user traffic & you want to preserve the QoS value impose by AP then you have to trust CoS. In this scenario ONLY user traffic will be classified correctly where 802.1q tag comes with the frame.
Related Posts
1. Understanding Wireless QoS – Part 1
2. Understanding Wireless QoS – Part 2
3. Understanding Wireless QoS – Part 3
4. Understanding Wireless QoS – Part 4
5. Understanding Wireless QoS – Part 5
6. 3750/3560/2960 Wired QoS
7. Who do you trust ? (DSCP or CoS)
8. BYOD with QoS
mrn-cciew 
Reblogged this on ytd2525.
If you hadn’t used the native VLAN though the MGMT traffic would have been tagged and you could have used CoS 🙂
I can’t really see the point in using the native VLAN except where it is actually useful; e.g. – where an interface can’t tag frames or for whatever reason a protocol or piece of software (aIOS seems to fall into this category) has been designed to make use of the native vlan despite being able to tag other frames. It just makes trouble-shooting harder if you only have access to one end of the link and is just another potential issue (ie, someone neglects to configure the native vlan or mis-configures).
Hi Scott,
Thanks for the comment.
In H-REAP deployment AP management should be on native vlan of the trunk (as per the Cisco deployment guide). Therefore we have no choice to use a tagged vlan for that.
It is interesting to test & see what happen if we put H-REAP into a tagged vlan.
Rasika
Happy new year!
When you change the qos profile to silver you get a capped COS value as per silver profile and DSCP EF.
In my captures i see the capped COS value but the DSCP is also capped to CS4..
I used Gold profile.
I’ll send you by mail the capture.
Regards.
Hi Nayarasi
Quick question. If I remark my port 5246 traffic from CS6 to AF42 (for example) over the WAN do I need to remark it back to CS6 before it reaches the WLC?
No, it will go as AF42 in CAPWAP header.
CS6 marking of CAPWAP to give highest priority within the network over any other user traffic
HTH
Rasika
Hi Nayarasi,
There is something that i’m missing & can’t understand. Why trusting DSCP will neglect the QoS profile values?
Is this the case also for OS 8.0 where the QoS profiles on WLC allows to use DSCP values directly which enables us to trust DSCP everywhere?
Thanks.
Since AP management on native vlan their is not L2 QoS field on those control frames. So by default those will get rewrite to DSCP of 0 when trusting CoS.
If you trust DSCP, then QoS profile capped value will not be used.
Since WLC 8.0 onward, behavior is different. see below
HTH
Rasika
The YouTube video at 5:51 says that the DSCP value will be capped to the Gold profile on 7.2 plus versions. The example given is for Central Switching where all traffic is CAPWAP to WLC. Would DSCP be capped for FlexConnect Local Switching mode as traffic enters / leaves the FlexConnect AP on 7.2 onward versions ?
Assuming trust model is DSCP on the switch and WLAN QoS Profile is set to Gold with no Wired 802.10 marking defined. If a packet from the switch enters FlexConnect AP with DSCP 46, AP would cap DSCP to 34 and set UP 5. If a packet from wireless client reaches AP with DSCP 46 and UP 6, AP would cap DSCP to 34 and forward it on to the switch. Is this understanding about FlexConnect DSCP Capping correct ?
Thanks,
Yes, your understanding of capping DSCP value is correct with respect to FlexConnect.
Note that in 8.0 onward QoS behavior has changed.
HTH
Rasika
Still not going to help us with Microsoft Lync environment.
The problem with have with trusting DSCP using old code (and new code), is that we run Lync in our environment and this overall QoS wireless model becomes tricky. Windows does not understand WMM and relies on wireless card drivers to do mapping. In our case Intel maps IPv4 DSCP into WMM UP using CS bits, i.e. IP Precedence. Hence, EF is mapped to UP 5 and this breaks the upstream flow. UP 5 is mapped to DSCP 34 and path between AP and WLC has no valid QoS applied for Voice traffic. For this reason we are marking Lync Voice as DSCP CS6 (using GPO), which is then mapped into UP 6 and translated into DSCP 46 (and CoS 5) by AP on the outer CAPWAP header… it works well with centralized WLC and FlexConnect AP as long as we trust CoS. Will not work if we trust DSCP – have to play with DSCP maps or complex policies (upstream/downstream) which I wanted to avoid at all cost.
New code does not solve this problem.
Because WLC still uses original DSCP value in upstream direction.
CS6 (W10) -> UP6 (AIR) -> DSCP 46 (AP) -> DSCP 46 (WLC) -> DSCP CS6 (DS)
Boom!
I’ve spent ages testing and doing captures to find the unified solution for this problem (without using site specific or complex classification and marking policies) and I’ve failed so far.
What’s the best way to solve this problem?
We’re trusing CoS on FlexConnect APs and WLCs now, but I hate it because management VLAN is untagged and it’s kind of not ideal QoS design.
Thanks
Hi Tim,
I understand your situation. QoS in wireless is tricky. I think there may be some improvement in upcoming versions, but cannot guaranteed it will address all the issues that we face today.
HTH
Rasika
Hello Rasika,
What will FlexConnect AP with local switching SSID use for UP mapping in the air for downstream traffic (to a client) when it receive tagged traffic from a trunk switchport – DSCP or COS? Does “Wired Qos Protocol -> Protocol type” option works here for FlexConnect?
Since 8.0 software releases, it always uses DSCP value. If your AVC rules got some DSCP rewrite, then it will follow those rules, otherwise, simply the original IP packet goes to air, just mapping inner DSCP value to WiFi header UP value.
HTH
Rasika