Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Statistics on 6500 for QOS

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

5 REPLIES
New Member

Re: Statistics on 6500 for QOS

Just to add to it.

When I give a command

show mls qos
  QoS is enabled globally
  Microflow policing is enabled globally
  QoS ip packet dscp rewrite disabled globally

  Qos trust state is DSCP on the following interfaces:
    Gi1/1 Gi1/2 Gi1/3 Gi1/4 Gi1/17 Gi1/18 Gi1/19 Gi1/20 Gi1/21 Gi1/22
    Gi1/23 Gi1/24 Gi4/48
  Vlan or Portchannel(Multi-Earl) policies supported: Yes
  Egress policies supported: Yes


----- Module [5] -----
  QoS global counters:
    Total packets: 4163509
    IP shortcut packets: 0
    Packets dropped by policing: 0
    IP packets with TOS changed by policing: 0
    IP packets with COS changed by policing: 19642 <<<<<<<
    Non-IP packets with COS changed by policing: 0
    MPLS packets with EXP changed by policing: 0

I see the IP packets with cos changed by policing. I have not configured any policers. I assume that this is the internal policer. Have I hit any buffer limits becos this value keeps incrementing? I have disabled mutation too. Please help,

Hall of Fame Super Blue

Re: Statistics on 6500 for QOS

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

New Member

Re: Statistics on 6500 for QOS

Hi Jon,

            Thank u very much for the detailed reply. That did help a lot. All the maps are correct, so I hope that the queueing should be proper, as per your explanation. Should the IP packets cos changed counter be given any importance? Because I think its due to a policing issue, but how can I checked that some IP packets are getting their COS changed? Is there any show command.

May be the signalling IP packets are sent with a cos value that is different to the dscp-cos map at the egress.

Thanks,

Prakadeesh

Hall of Fame Super Blue

Re: Statistics on 6500 for QOS

prakadeesh wrote:

Hi Jon,

            Thank u very much for the detailed reply. That did help a lot. All the maps are correct, so I hope that the queueing should be proper, as per your explanation. Should the IP packets cos changed counter be given any importance? Because I think its due to a policing issue, but how can I checked that some IP packets are getting their COS changed? Is there any show command.

May be the signalling IP packets are sent with a cos value that is different to the dscp-cos map at the egress.

Thanks,

Prakadeesh

Prakadeesh

Short answer is i don't know. You are not dropping any packets ie.


Packets dropped by policing: 0

so that's one thing to be thankful for. I haven't come across an internal policer that is not user configured in any of the 6500 QOS documentation so i shall revisit the docs to see if anything stands out.

Jon

New Member

Re: Statistics on 6500 for QOS

Sorry for the delay Jon, Yes I was also not sure of what this behaviour was. I have not configured any policers on the system. I will also try to check for some docs though. Not much info on this o/p cmnd, i could find.

-deesh

1865
Views
5
Helpful
5
Replies
CreatePlease to create content