Thanks Jason, I mixed up a little and your logic makes perfect sense. Now I gotta go back and veryify what my switches are trusting between each other.
Darby 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] > -- Darby Weaver Network Engineer [email protected]
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
