Radio Downstream QoS - Traffic leaving the AP and traveling to the WLAN Clients.
Radio Upstream QoS - Traffic leaving the WLAN clients and traveling to the AP. WMM provides upstream QoS for the WLAN clients supporting WMM Network Downstream - Traffic leaving the WLV traveling to the AP. QoS can be applied at this point ro prioritize and rate-limit traffic to the the AP. Network Upstream - Traffic leaving the AP and traveling to the WLV. The AP classifies traffic from the AP to the upstream network according to the traffic classification rules of the AP. The theory is harder than the implementation on the WLC. You do need to understand where to trust DSCP and where to trust CoS in the network topology. The WLC performs the DSCP to CoS Mappings and vice versa, and thus why we trust CoS on the Controller, DSCP on the AP, and DSCP on point in between. We classify the traffic / mark traffic on the ingress ports of a given switch. This means we can mark the traffic with another value aside from the value the packet was originally marked by the device. Note we might trust a Cisco Phone for example. Let's see... once we have marked the traffic we might want to do something else with it with an MQC policy, we might want to police it, etc. Of course, we can also configure queueing on the port and then there is also SRR queues too that is a little different but helpful to know about while we are on the topic of queueing. The QoS SRND 3.3. is the bible for this kind of information on QoS and its where I fall back to for reference. Just remember, aside from LLQ - itself a form of priority queueing, most QoS features are not going to be as visible on a lightly congested network. That's where queueing is nice and why we tell people it is important even if the immediate affects of a given policy are not immediately visible. Especially where Voice, Video, and Control Plane traffic are concerned. Always nice to see they are not being starved. Hmm... no one even asked about DCF at all. I was watching one of the videos on from the share and noticed the speaker going over the topics and some of them he didn't seem as well versed with. I'd guess that has been a while back and everyone on the list is a little better prepared. Darby I hope I have most of this VoWLAN and QoS worked out. I just scheduled that exam for next week. :) 2010/11/5 George Stefanick <[email protected]> > Looking at the profiles, one thing is for sure. QoS is the topic most > obscure for most of us, myself included. This is very helpful... Jason do > you care to comment on upstream and downstream QoS and the WLC. Please, > correct me if i am wrong but QoS policing from the WLC can only happen "down > stream". Normally a QoS policy on the switch is added for upstream policing > ... > > Thanks for your time and answering these ... WE ALL appreciate it ! > > George > > 2010/11/2 Jason Boyers <[email protected]> > >> Great post. I would just add the following: >> >> >> >> 1) Building on #2 from Darby, if it is an access port, there are no >> CoS values in the frame and hence you can’t trust CoS. CoS values are >> specified in the Prioritization part of the VLAN tag in the 802.1Q header. >> This also means that there are no CoS values in untagged native VLAN >> frames. >> >> 2) If you do use auto qos, note that it will configure *mls qos >> trust cos* by default, even on an access port. Which in turn means that >> nothing will be trusted on that access port. It’s good to know what auto >> qos will configure, but it’s better to know how to configure without it. >> >> 3) For APs, it depends on the mode of the AP. For example, if you >> have an H-REAP AP with local switching, you **may** want to trust CoS. >> Or, if you have an autonomous AP/bridge that is trunking, you may want to >> trust CoS as well. That would depend on what was being done on the AP for >> setting CoS values. >> >> 4) The switch always does an external CoS or DSCP to internal DSCP >> mapping on ingress, depending on what was trusted. The mapping depends on >> the CoS to DSCP map or the DSCP Mutation map. And, it uses the internal >> DSCP and the DSCP to CoS map for placing frames into the appropriate egress >> queues. >> >> 5) In general, trust DSCP between switches, even if there is a layer >> 2 trunk connection between them. This goes back to #3. If you have set >> your CoS to DSCP mapping appropriately (if it needed to be changed from the >> default), there is no need to do another mapping on another switch. >> >> 6) For the 6500, you can use the *show queueing interface Gix/y *command >> to see the input and output queue configuration available for a specific >> port. It will show the output queues parameters first, then the input >> queues. >> >> >> >> Jason Boyers - CCIE #26024 (Wireless) >> >> Technical Instructor - IPexpert, Inc. >> Mailto: *[email protected]* >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Darby Weaver >> *Sent:* Monday, November 01, 2010 10:38 PM >> *To:* Kristján Ólafur Eðvarðsson >> *Cc:* [email protected] >> *Subject:* Re: [CCIE Wireless] end to end QOS >> >> >> >> Kristjan. >> >> >> >> The main points fo QoS are this: >> >> >> >> 1. Mark as close to the edge as possible. >> >> >> >> 2. In the case of cisco devices we trust as follows: >> >> >> >> - Trust DSCP from APs (edge L3 notice they are typically on access ports >> themselves). >> >> - Trust CoS on controllers from the switch itself (notice it is a trunk >> and L2) >> >> >> >> So far we have CoS = L2 and DSCP = L3 >> >> >> >> - In between switches we have trust boundaries so we may or may not need >> to set up CoS to DSCP or DSCP to CoS or re-mark traffic, but if we do it >> will be between the switches like the 6500 and the 3750 for example. You >> can view the Mutation Maps on each device, copy them to notepad if needed, >> and then configure your mutation map accordingly. >> >> >> >> - Sometimes in a CCIE Lab we might be asked to "remark traffic" or assign >> a different value or even apply SRR/WRR values to the port in question. In >> these questions, we normally just do precisely what is asked. >> >> >> >> - As for Platinum, Gold, Silver, and Copper - Basically 4 service >> policies. The trick is to review these policies in the Enterprise Mobility >> Guide. Apply as required by the requirements of the lab. >> >> >> >> - You may be asked to police as certain value so you'd take a look at the >> requirements and ask yourself whether it is a policer or a shaper and then >> on what condition should it either drop, apply a policy, or allow to >> continue. You'd set the policy action in global mode on the switch. >> >> >> >> - The 6500 is fun, you see each blade model of the 6500 switch has >> different QoS capabilities, so it assumes you have knowledge of how to find >> these values - say in the QoS SRND or in the hardware configuration guide of >> the CCO documentation. >> >> >> >> - The MQC and Priority Queueing are assumed knowledge. >> >> >> >> - Creating access-list of one sort or another is also an assumed skillset >> for QoS. Imagine marking on packet size or fragments for example. >> Interesting? Very possible. How big did we we say VoIP packets are? >> >> >> >> - Interleaving and Fragmentation is also fun and probably fair game in >> the lab as well. I'd use it if I were a proctor, since it is commonly >> misunderstood. >> >> >> >> - Don't forget to enable QoS and then to apply it to your intefaces as >> required. Simply enabling QoS and nothing more actually re-marks packets to >> a value of 0 and that is probably not what will ever be intended in any CCIE >> Lab. - Agreed? >> >> >> >> You can do flips with QoS. >> >> >> >> Diagram 5-1 in the Enterprise Mobility Guide version 4.1 kind of >> illustrates most of my points in one single visual representation. >> >> >> >> Radio Upstram and Downstream / Network Upstream and Downsteam are valuable >> considerations in figuring out which way to apply QoS. >> >> >> >> Table 5.2 Explains Precedence / 802.1P >> >> >> >> The last paragraph on page 5-17 is very important and needs to be well >> understood. >> >> >> >> Take a look at Diagram 5-22 for a spot check on where various QoS >> boundaries are set in a CUWN. >> >> >> >> >> >> Here's a config for the AP for example trusting DSCP: >> >> >> >> int g1/0/1 >> >> spanning-tree portfase >> >> sw m a >> >> sw a v 10 >> >> mls qos trust dscp >> >> >> >> >> >> Another example for the WLC interface of the switch: >> >> interface GigabitEthernet1/0/13 >> switchport trunk encapsulation dot1q >> switchport trunk allowed vlan 11-13,60,61 >> switchport mode trunk >> mls qos trust cos >> >> >> >> >> >> Hope this helps a little. >> >> >> >> The diagrams I referred to should help as to where to apply QoS. QoS is >> really brief in the guide by comparison of a more mature understanding of >> the topic and make no mention of how to test QoS either to verify that you >> are applying the policy and getting the results you want to see. >> >> >> >> Darby >> >> >> >> >> >> >> >> >> >> >> >> 2010/11/1 Kristján Ólafur Eðvarðsson <[email protected]> >> >> Hi guys, awfully quiet here last days :) >> >> I am working on QOS now. I sense that it is >> essential to learn all mappings between wifi client site 802.11e to AP >> DSCP and WLC COS markings. >> Know what happens for a packet when marked with the Platinum profiles in >> WLC and when it ends >> on the upstream to client. And vice versa. Jeromes Videos are very good >> and help you to understand that. >> But it is essential in my mind to know all DSCP and COS mappings back and >> forth. >> >> It is very well explained how the marking is done and controlled in the >> Wireless consept. >> >> There is one thing bugging me. I need to have a end-to-end configuration >> including the switches part. >> I know about the trust DSCP from APS and trust COS from WLC's. And the COS >> to DSCP markings and back. >> >> I saw this document in the dropbox called qos-wlc-lap.pdf which is rather >> good. And all >> the documents from that folder ConfigurationGuideexamples folder on >> Dropbox. >> >> But that document only gives weigted round robin QOS method that doesn't >> seem to be supported on 3560 >> or 3750 I am using in my own lab. >> >> Has anyone a good end-to-end configuration with L2 switches, L3 switches, >> WLCs, LAPs and Aps ? >> with say some prioritation for voice traffic for example ? >> >> Somebody want to share their strong points !? >> >> regards. Kristjan >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> >> >> >> -- >> Darby Weaver >> Network Engineer >> >> >> [email protected] >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > > > -- > George M. Stefanick Jr., CCNA, CWNA, CQS-CWLANSS Sr. Wireless Engineer > (717) > 471 - 6186 Mobile (717) 798 - 8255 Skype > -- Darby Weaver Network Engineer [email protected]
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
