HI Jason,
Thanks for the quick explanation, totally appreciate this. However, for the
portion where a non-wmm client send data to the AP and then to the wired
side, cisco's documentation doesn't explains so (if you can bear with me):
http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807e9717.shtml
*<<For a WMM disabled FTP client:*
When the FTP server on the wired side sends data to the FTP client on the
wireless side, this sequence of events occurs:
1.
At the FastEthernet interface on Router1, the Marking-For-FTP policy is
applied to the FTP packets and the packets are marked with a
DSCP value of
AF11.
2.
The marked FTP packets pass through the serial interfaces s3/0 on
Router1 and S0/0 on Router2. This is where the drop probability of the
packet are checked against the threshold configured for WRED. When the
average queue length reaches the minimum threshold (30 packets
in this case
for FTP packets), WRED randomly drops some packets with the DSCP
value AF11.
Similarly, when the average queue length exceeds the maximum
threshold (40
packets in this case for FTP packets), WRED drops all packets
with the DSCP
value AF11.
3.
*Once the FTP packets reach the WLC through the fastethernet on
Router2, the WLC translates the DSCP value of the incoming packet to the
AVVID 802.1p UP value and copies the DSCP value from the
incoming packet to
the LWAPP packet as shown here. In this example, the DSCP value AF11 is
translated to the corresponding 802.1p value 1. *
4.
*When the packet reaches the LAP, the LAP places the packet in the
default 802.11 Tx queue for the WLAN QoS policy assigned to that
client. In
this example, the packet is placed in the queue for the Bronze
QoS profile.
*
When a FTP client on the wireless side sends data to the wired side, this
sequence of events occurs:
1.
*When a FTP client on the wireless network sends a packet to the LAP,
the LAP uses the 802.11e UP value for the QoS policy assigned to that
client. Then, the LAP translates the value to the DSCP value and
sends the
packet to the controller. Because the FTP client belongs to QoS profile
bronze IEEE 802.11e UP value 1 is translated to the DSCP value AF11. *
2.
*The controller translates the DSCP value of the incoming LWAPP packet
to the 802.1p UP value as shown and the original DSCP value is also sent
unaltered. The packet is then forwarded to Router2 through the Layer 2
switch.*
3.
The packets with DSCP value AF11 at the fastethernet on Router2 pass
through the serial int >> Of course that's why we don't want to trust
DSCP at the WLC end but the COS because the DSCP is the original
unaltered
value set by the client (if any).
And this is why my previous post relates what this document is trying to
illustrate. Even the documentation on "Voice over Wireless LAN Design Guide"
explains the same treatment to non-wmm clients. Or, am I totally
interpreting this wrongly. Thank you Jason!
Alvin B
Quoting Jason Boyers <[email protected]>:
> Non-WMM traffic doesn't have a UP value (which you all know.) That means
> that it comes in on the default queue on the AP radio. The default queue
> gets mapped to DSCP 0 at the wired side of the AP (even for 7920 phone.)
>
> When going from the wired side, the traffic follows whatever L2/L3
markings
> have been assigned (if it was EF, it it will remain EF, depending on the
> 802.1p settings of the QoS Profile) until it gets to the AP. At the AP,
> since it is a non-WMM device, it will be mapped to the default queue,
> without a UP value.
>
> Hope that clears things up (a bit.)
> Jason Boyers - CCIE #26024 (Wireless)
> Technical Instructor - IPexpert, Inc.
> Mailto: *[email protected]*
>
>
> On Thu, Mar 10, 2011 at 3:02 AM, Phil Priest <[email protected]>
wrote:
>
>> Alvin,
>>
>> I had the same query, and I am still somewhat unclear on the answer.
>>
>> If WMM traffic comes into the AP from the client with a UP value of 6 or
>> 7 and CAC and you have voice CAC enabled in Platimum, then it would be
>> mapped to CoS value of 5 based on the 802.1p value specified in the
>> platinum class.
>> Any WMM traffic coming in with a value of 6 or 7 without CAC would not
>> be accepted as CAC is mandatory on the voice class. Any WMM traffic
>> coming in with 4 or 5 without CAC would be accepted as there is no CAC
>> on the video class.
>> I am unclear however what would happen with a "non WMM" client as stated
>> in the question, as I understood that if its non WMM it would not come
>> in with a UP value. What happens to traffic that comes in without any UP
>> value, is it mapped to 0?? Or does it take the value of the class
>> defined on the controller profile??
>>
>> Regards
>>
>> Phil
>>
>>
>>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of
>> [email protected]
>> Sent: 10 March 2011 04:46
>> To: [email protected]
>> Subject: [CCIE Wireless] 5.6 - WLC Qos
>>
>> Hi all,
>>
>> The 2nd portion of the question where ssid Guest2 is to allow WMM and
>> non-WMM devices to connect. If a non-WMM device connects, it should not
>> be able to use greater than AC Video. (not sure what this really means.
>> quite vague) The DSG shows, the Guest2 WLAN to be configured with the
>> platinum profile with dot1p of 6 (default). Correct me if I'm wrong, but
>> if a non-WMM client gets associated with that WLAN, won't the LWAP
>> upstream packet (to WLC)be mapped with DSCP associated with the QoS
>> profile which is EF? Then later down the chain, the cos of the client's
>> outgoing traffic from the WLC to LAN will be given a COS of 5?
>>
>> OR, is this question talking about the different wireless
>> queueing/contention mechanism related to WMM and the 4 ACs, where
>> non-wmm will be subjected to DCF instead of EDCF?
>>
>> Any input is greatly appreciated.
>>
>> Alvin B.
>>
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training,
>> please visit www.ipexpert.com
>>
>
