Its an area I am still investigating and trying to get my head around all of the QoS mechanisms. Nightmare.
However for Eric lists the default values and Daniel the values discussed in documents, however there is no suggestion as to a need to change these values.
Its definitely an area that I would really like to get to the bottom of.
I am ploughing through all of the above at the moment focusing on the voice side and understanding QoS plus all of the other specific add on parts. Not started to deviate yet from Cisco 7921/5. Think I am getting there though, just sometimes someone might have a real gem of a doc thats as easy as A B C but I dont think thats the case with QoS
Also plan on doing some labs with a QoS generator and packet sniffing so I can see the interactions.
Doing my own research on QoS so thought I would look into this as a real world example. Now lets say both are correct 0 8 16 24(26) 32 46 48 56 and 0 10 18 26 34 46 48 56.
Now bare in mind this is still not crystal clear to me but COS uses a 3 bit field at layer 2 and groups the categories into Class Selector Code Points or CS classes. From CS0 – CS7.
However DSCP works at layer 3 and uses a 6 bit field (technically 8 but the last 2 bits are not really used) creating 64 different QoS values. The first 3 bits to the left of the dscp field can group directly to the CS class the same as COS. Bits 4 and 5 define the drop probability.
When we look at the class map (I have only included a few lines)
Background (Cisco AVVID Gold Background)
Background (Cisco AVVID Silver Background)
If there are no drop probability bits it translates to a CS class so 8 is CS1, however 10 is also CS1 but with drop probability. From my understanding 10 will have a higher drop probability than 8.
Again that’s from just a few hours thrashing around and a little background reading over the last few days.
I have not put the whole table in as its something I need to fully understand I am throwing this out there for everyone.
Maybe I could actually pull all the WLAN QoS bits into a unified doc that makes sense? Well makes sense to me.
I await to get flamed!
The CS values dont use the drop probability so if it makes sense CS1 is CS1 and thats it, the AF values are the ones which use the drop probability bits from my understanding.
See the DSCP to binary/decimal table in this document and it explains that CS values always end with xxx000.
In your example 8 is CS1 and 10 is AF11 you have gone up a class
I will try and dig out the DSCP to COS table map, you will find multiple DSCP values mapped to CoS values just purely becasue there is more of them.
Its probably a weak point because you dont really have to use it generally, QOS only comes into play if there is congestion (wired). Only need it if you feel there is not enough bandwidth available and in most case these days it is 1Gb uplinks to APs etc....
The Jermone stuff is good on QOS however if you can get hold of the old QOS course books or Nuggets for CCVP or CCIP it does a great job of explaining. QOS for wireless is not that in depth really.
Hey Pete, sorry its a little crazy here.
Default CAPWAP Control (5246) marking is CS6 .. CAPWAP Data (5247) is dependent on wireless users User Priority (UP) values and WLC QoS profile 802.1q settings.
Note: cos values exist in 802.1Q header so untagged vlan = cos value 0.
I can't recall who did the CCVP nuggets however if it's Jeremy Cairo it must be good
Bryn, nice link mate.
Hope this helps.
thx for the comments.
The switch makes a mapping on the ap-port from dscp (regarding the wlan-qos-profile) to cos , but this mapping is not influence from the cos to dscp mapping.
On the trunk to wlc is "qos trust cos" and management vlan is tagged. CAPWAP-Data is tagged with dscp and cos-tag (regarding WLAN-Qos-Profil.
The mapping from cos to dscp ocours between two Layer3-Infrastructures ? The mapping has any influence on the network ?
Nachricht geändert durch daniel-schmidt