prakadeesh wrote:
Hi Folks,
Apologies if a duplicate thread.
I know that that there is a show mls qos int stat command on the 3750 that is pretty cool to view the stats. But is there any such commands in 6500.
I am implementing a QOS model based on the dscp so would like to view statistics to just satisfy myself that priority queueing is doing its magic?
to add to it :
show queueing interface g1/1
Interface GigabitEthernet1/1 queueing strategy: Weighted Round-Robin
Port QoS is enabled
Trust state: trust DSCP
Extend trust state: not trusted [COS = 0]
Default COS is 0
Queueing Mode In Tx direction: mode-cos <<< this is worrying
Transmit queues [type = 1p3q8t]:
Queue Id Scheduling Num of thresholds
-----------------------------------------
01 WRR 08
02 WRR 08
03 WRR 08
04 Priority 01
I have implemented the qos model based on dscp trust. But the above o/p shows that queue mode is mode-cos and the default cos is 0, so does this imply that my dscp based QOS queueing cannot be done in 6500 ?
The cos-dscp map is mapping the dscp values properly. but just wondering. Incase of an incoming packet from another switch cos=5,dscp=46. This port will mark cos=0,dscp=46(since no mutation). So the packet will get only normal queueing not priority? So is trust cos the only way to implement mls qos on 6500?
Please let me know your thoughts.
Thanks,
Prakadeesh
Prakadeesh
There are a few things going on here so i'll try and cover some of the more important points.
For the vast majority of linecards in the 6500 egress queueing is based on CoS values and not DSCP values. By this i mean you map CoS values to queues on egress. This doesn't mean you cannot use the DSCP value on ingress to classify the packet, you can, see below for more details. Some linecards allow mapping DSCP values to egress queues such as the WS-6708-10GE module but you aren't using one of them. So the queueing mode in TX = mode-cos is normal and is actually how the 6500 maps packets to queues.
So if you can only use the CoS value for the majority of linecards on the 6500 how can you use the DSCP value in the received packet ? Well obviously you can by using the trust dscp on an ingress port. The key to all of this are the QOS maps
CoS-to-DSCP - used to derive a DSCP value from a CoS packet in a frame arriving on ingress
DSCP-to-DSCP - used to derive a different DSCP value from a DSCP value in a frame arriving on ingress
DSCP-to-CoS - used to derive a CoS value that can then be used to determine which egress queue to put the packet in <--- note the difference here ie. it is concerned with the egress ie. transmit rather than the other 2 which are concerned with ingress ie. received
The last key thing to understand is that catalyst switches use an internal DSCP value when moving the packet through the switch from ingress to egress. This internal DSCP value is never written into the packet.
So if you trust DSCP on ingress unless you have used a DSCP mutation map to change the DSCP value to another DSCP value then the internal DSCP value is the one which was received in the packet.
If you trust CoS then the CoS-to-DSCP map is used to derive the internal DSCP.
If you trust neither then a default CoS value of 0 is used which is then used in the CoS-to-DSCP map to derive an internal DSCP value.
Once the relevant actions have been taken as the packet traverses the switch then the DSCP-to-CoS map is consulted to determine which queue and threshold to place the packet in.
The above is a general overview of how the 6500 does QOS. There are added complications (always are with the 6500 !!) with the linecards as mentioned above and also changes in certain QOS behaviour between IOS releases. But the above is still fairly accurate. And if it's not i'm sure some of the others will let me know
Edit - forgot to mention IP Precedence. You can also trust IP Precedence on an ingress port and there is an IPPrec-to-DSCP map used to derive the internal DSCP value.
Jon
