First, Cisco's documentation is wrong for several points.  That doesn't make
it easy when that's what you should use in studying.

Second, I may reword 5.6, bullet two.  It was written that way to cause
thinking, which it apparently is doing.  However, I understand that it is
confusing.  Technically, the way that it is worded would not require any CAC
whatsoever.  And, actually, any QoS Profile would do.  I'll think about how
to word it differently to try to get the same effect I'm looking for.  Now,
on to the specifics.
#3 for example 1 is (mostly) correct.  However, #4 is not right.  A non-WMM
client CANNOT understand an 802.11e UP value.  Because of that, the AP DOES
NOT mark an 802.11e value.  Therefore, it is put in the default radio
queue.  I do need to test the 7920 some more, since it is a non-WMM client,
but the example seems to address an laptop situation.

For example 2, it is correct, in that the received UP value (in this case,
null) is translated to the appropriate DSCP value (which would be 0 for a
null UP value.)  AF11 never comes into play in that case.

One more thing - even though the documentation states that the DSCP value
passes through unchanged, this is not correct.  The received CoS value
(which was based on the DSCP-CoS map on the switch) is translated to the
equivalent DSCP Class Selector value on the transmit side of the WLC.  The
only exception to this is EF, since CoS 5 could be translated to CS5 or to
EF.

With all of that said, what do you do on the lab?  You do what the
requirements state.  And, if there is one that could be configured two
different ways (one correct and the other according to the docs,) go to the
proctor and explain the situation.

Jason Boyers - CCIE #26024 (Wireless)
Technical Instructor - IPexpert, Inc.
Mailto: *[email protected]*


On Thu, Mar 10, 2011 at 9:20 AM, <[email protected]> wrote:

> 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
> >>
> >
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to