Hi jason,
Actually when WMM is disabled in the WLAN, the LWAP packet upstream towards
the WLC from the AP will be assign a dscp value equivalent to the QoS
Profile 802.11e value. If Platinum is used, the LWAP packet will be assigned
EF class, if set to Gold, your get AF41 and even if you set to 802.11e 7,
the DSCP of the lwap will be CS6. This is irregardless of the type of
wireless client or the DSCP marking placed by the client. I've not yet
checked on the final DSCP and COS value of the client packet when it exit
the WLC towards the LAN.
Alvin
Quoting Jason Boyers <[email protected]>:
> Alvin
>
> Good work there. I'm going to spend some more time going through it.
For
> now, one thing that stuck out to me was that when the SSID was set to
*WMM
> Disabled*, you still show 802.11e markings. While the client could still
be
> setting them, the AP will not put those markings in if WMM is disabled.
> Also, was all of this testing in the downstream direction (wired client
to
> wireless client)? And, when you say that the DSCP values "went through,"
> are you talking about both the outer and inner DSCP values, or just the
> inner? Lastly, what version of WLC are you running?
>
> Again, thanks for putting in the time. It will benefit you greatly.
> Jason Boyers - CCIE #26024 (Wireless)
> Technical Instructor - IPexpert, Inc.
> Mailto: *[email protected]*
>
> On Fri, Mar 11, 2011 at 2:43 AM, <[email protected]> wrote:
>
>>
>> Hi Jason,
>>
>> I took a few hrs digging deeper into the topic and setting up a mini
test
>> lab with WLC4404, 3560, 1252, 7921, 7920 and a notebook. I used
wireshark to
>> sniff all packets on the AP's outbound. FOr the phones, I made a proper
call
>> to ensure rtp goes through and for the notebook i pinged some internet
>> sites. And here are my findings:
>>
>> 7921:
>> 1) WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 6: EF
>> 2) WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 3) WMM disabled, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 4) WMM required, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 5) WMM required, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 6) WMM allowed, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 7) WMM allowed, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 8) WMM disabled, no CAC, Gold non 802.1p tag(802.11e): AF41
>> 9) WMM disabled, no CAC, silver non 802.1p tag(802.11e): AF21
>> 10)WMM required, no CAC, silver non 802.1p tag(802.11e): AF21
>> 11)WMM allowed, no CAC, silver non 802.1p tag(802.11e): AF21
>> *12) WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 7: CS6
>> 13)WMM required, no CAC, Platinum 802.1p tag(802.11e) 7: EF
>> 14)WMM allowed, no CAC, Platinum 802.1p tag(802.11e) 7: EF*
>>
>>
>> 7920:
>> 15)WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 6: EF
>> 16)WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 17)WMM disabled, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 18)WMM required, no CAC, Platinum non 802.1p tag(802.11e): 7920 cannot
>> associate
>> 19)WMM allowed, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 20)WMM allowed, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 21)WMM allowed, no CAC, silver non 802.1p tag(802.11e): AF21
>> 22)WMM disabled, no CAC, Gold non 802.1p tag(802.11e): AF41
>> 23)WMM disabled, no CAC, silver non 802.1p tag(802.11e): AF21
>> *24)WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 7: CS6
>> 25)WMM allow, no CAC, Platinum 802.1p tag(802.11e) 7: EF*
>>
>> Lenovo T400s (with WMM disabled on NIC, no DSCP marking):
>> 26)WMM enable, no CAC, Platinum non 802.1p tag(802.11e): Notebook cannot
>> connect
>> 27)WMM disabled, no CAC, Platinum non 802.1p tag(802.11e): EF
>> 28)WMM disabled, no CAC, Platinum 802.1p tag(802.11e) 4: AF31
>> 29)WMM allow, no CAC, Platinum non 802.1p tag(802.11e): DSCP 0
>> 30)WMM allow, no CAC, Silver non 802.1p tag(802.11e): AF21
>>
>> Lenovo T400s (with WMM enabled on NIC, no DSCP marking):
>> 31)WMM allow, no CAC, Platinum non 802.1p tag(802.11e): DSCP 0
>> 32)WMM required, no CAC, Platinum non 802.1p tag(802.11e): DSCP 0
>> 33)WMM disabled, no CAC, Platinum non 802.1p tag(802.11e): EF
>>
>> Lenovo T400s (with WMM enabled on NIC and DSCP marking on outgoing
>> traffic):
>> 34)WMM Required, notebook forced DSCP AF41, Platinum non 802.1p
>> tag(802.11e): AF31
>> 35)WMM Required, notebook forced DSCP AF31, Platinum non 802.1p
>> tag(802.11e): AF21
>> 36)WMM Required, notebook forced DSCP CS7, Platinum non 802.1p
>> tag(802.11e): EF
>> 37)WMM Required, notebook forced DSCP EF, Platinum non 802.1p
tag(802.11e):
>> AF41
>> 38)WMM Required, notebook forced DSCP EF, Platinum 802.1p tag(802.11e)
4:
>> AF31
>> 39)WMM Required, notebook forced DSCP EF, Gold non 802.1p tag(802.11e):
>> AF41
>> 40)WMM disabled, notebook forced DSCP CS7, Platinum non 802.1p
>> tag(802.11e): EF
>> 41)WMM disabled, notebook forced DSCP AF41, Platinum non 802.1p
>> tag(802.11e):EF
>> 42)WMM allowed, notebook forced DSCP AF41, Platinum non 802.1p
>> tag(802.11e): AF31
>> 43)WMM allowed, notebook forced DSCP AF31, Platinum non 802.1p
>> tag(802.11e): AF21
>> 44)WMM allowed, notebook forced DSCP EF, Platinum non 802.1p
tag(802.11e):
>> AF41
>>
>> If you go through every scenario, you'll find that for a non-wmm device
>> with or without DSCP marking on the packet, and with WLAN WMM-Disabled,
the
>> DSCP on the LWAPP will be equivalent to the QoS Policy set
802.1p/802.11e
>> tag regardless of the DSCP value set in the client packet(when
translated
>> from DSCP to COS). This applies to my notebook and maybe so for the
phones
>> since I can't set a lower than EF priority for the phones to test. But
the
>> most interesting setting is when WLAN WMM is set to allow. When this is
set,
>> the DSCP of the 7920/7921 went through. As we know 7920 don't support
WMM,
>> hence by Jason's finding, it should become DSCP 0, but it didn't, the EF
>> class went through. Even when i set the 802.1p tag value to 7, the EF
class
>> of the 7920 still when thru (item 24, 25). For a notebook without DSCP
>> marking, the LWAP dscp became 0. But i will also assume that the DSCP of
my
>> notebook will go thru.
>>
>> Now comes the puzzling part. When i used qos policy within Win 7 (WMM
>> enabled) to force all outgoing packets with a dscp value, things become
>> weird. 1st of all, to verify that my notebook was indeed sending out the
>> correct dscp, i used wireshark to sniff my nic, and true enough the dscp
>> matched what i set. But when the AP receives it, it automatically mark
the
>> dscp down on the LWAP packet. This applies for WMM-required and
WMM-allow
>> mode. For WMM-disabled, the QoS class on the WLAN gets applied.
>>
>> For some reason, after i setup the qos policy into my notebook, even
when I
>> disable dscp WMM on the nic, the notebook will still be able to connect
to
>> the WLAN when the mode is set to "required" which gave me the assumption
>> that with DSCP attached to the outgoing packets of the NIC, the AP
thinks
>> that my notebook is wmm compliant. Hence i can't perform a fair test
with my
>> notebook set with DSCP but without wmm-enabled.
>>
>> In conclusion, i observed that for non-wmm clients, dscp information is
>> sent across to the AP and the AP do translate to some LWAP dscp value
when
>> the WLAN WMM mode is set to wmm-allow (proven with 7920). If you reduce
the
>> 802.1p value in the Qos profile, it set as the maximum dscp value of the
>> WLC-bound lwap packet, assuming the client dscp is equal or higher than
the
>> set 802.1p value. With this, i assume that if you send a DSCP packet
with
>> dscp lower than the qos 802.1p set value in the WLAN, it will go thru to
and
>> the lwap packet will reuse the same DSCP value. But when wmm mode is set
to
>> disable, everything gets map to the qos profile applied to the WLAN.
>>
>> Regardless of wmm or non-wmm clients:
>>
>> WMM-Disable: Maps to applied QoS Profile
>>
>> WMM-Allow: DSCP pass through
>>
>> WMM-Required: DSCP pass through
>>
>> I will figure out the WLC to LAN packets as well as the WLC to AP lwap
>> packets and feedback later.
>>
>> Alvin B
>> Quoting Jason Boyers <[email protected]>:
>>
>> > I understand that it makes for a somewhat difficult situation. In
>> reality,
>> > it is more of an issue during the studying, when you are verifying
>> different
>> > configurations and not receiving the results you would expect. Also,
>> it's
>> > helpful to know for real life.
>> >
>> > There was a very good Cisco Ask the Expert discussion on the CCIE
>> Wireless
>> > at https://supportforums.cisco.com/message/3070908.
>> > While it is almost a year old, it is still applicable from what I've
>> heard.
>> > One of the things that Javier (who helped write the lab) says is, "The
>> exam
>> > design requirements are that every possible answer is based on
documents
>> > available on cisco.com. All answers are tracked back to
documentation."
>> So,
>> > know the documentation (especially the Design Guides written in 2009.)
>> But,
>> > know how things work so that you can troubleshoot adequately as well.
>> > Jason Boyers - CCIE #26024 (Wireless)
>> > Technical Instructor - IPexpert, Inc.
>> > Mailto: *[email protected]*
>> >
>> >
>> > On Thu, Mar 10, 2011 at 6:39 PM, <[email protected]> wrote:
>> >
>> >> Now that you have said all these, we have a pretty sticky situation
>> here.
>> >> If questions of such nature do appear in the lab,
>> >> a) we can either think and agree to Cisco's literature and this would
>> mean
>> >> that the answer here would not apply since cisco's reading say
>> otherwise, or
>> >> b) we press on with this answer which is proven in our own labs.
>> >> c) we check with the proctor and if he is kind enough, hint us about
>> a)he
>> >> stands by Cisco readings and our answer is not what he is looking for
or
>> b)
>> >> exactly what he wants us do and we should have figure this out by
>> ourselves
>> >> when we r studying.
>> >>
>> >> ANyway, today with my own setup, I'll figure this our by sniffing all
>> >> relevant packets (notebook, 7921 and 7920). I'll report my findings
>> here if
>> >> i find anything significant.
>> >>
>> >>
>> >>
>> >> Alvin
>> >>
>> >>
>> >>
>> >>
>> >> Quoting Jason Boyers <[email protected]>:
>> >>
>> >> 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
>> >>>> >>
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>
