Any command to verify QoS is working properly as configured?

[getaway51]

What can be monitored in the router tht QoS is working? 

[cmarva]

with no specific information other than you mention router, you can issue the command 

sho policy-map interface

and you will see the hits per class of your policy

[WARRENMEECH3690]

My solution is to record a summary and compare again later.
For input policies I use command:
WS-C3850-24XU#sh policy-map int te1/0/18 | i Class|packet
Class-map: in-Voip-Data-Class (match-any)
8515 packets
Class-map: Critical-RNZ-Apps-Class (match-any)
0 packets
Class-map: in-Voip-Signal-Class (match-any)
45201 packets
Class-map: in-Multimedia-Class (match-any)
1013578099 packets
Class-map: in-Bulk-Data-Class (match-any)
553072 packets
Class-map: in-Trans-Data-Class (match-any)
507 packets
Class-map: in-Scavanger-Class (match-any)
12212 packets
Class-map: in-Signaling-Class (match-any)
0 packets
Class-map: in-Default-Class (match-any)
0 packets
Class-map: class-default (match-any)
4060366301 packets

For output policies I use command:
WS-C3850-24XU#sh policy-map int te1/0/11 | i Class|drop|output
Service-policy output: QoS-Voda-Output-Policy
(total drops) 1082641
(bytes output) 52152591953
Class-map: Output-Priority-Queue (match-any)
Class-map: Output-Control-Mgmt-Queue (match-any)
(total drops) 0
(bytes output) 20706433691
Class-map: Output-Multimedia-Queue (match-any)
(total drops) 44208441
(bytes output) 306700245380
Class-map: Output-Trans-Data-Queue (match-any)
(total drops) 0
(bytes output) 38204424880
Class-map: Output-Bulk-Data-Queue (match-any)
(total drops) 0
(bytes output) 4210323454
Class-map: Output-Scavenger-Queue (match-any)
(total drops) 0
(bytes output) 12016600079
Class-map: Output-Multimedia-Strm-Queue (match-any)
(total drops) 0
(bytes output) 244853
Class-map: class-default (match-any)
(total drops) 180926591
(bytes output) 2388730249043

These commands allow a quick and easy view of which classes are being hit.

[Patrick.Williams]

The only true way to verify that QoS is working is to hook up a traffic generator and monitor your drop rate in various queues. Since that isn't typically feasible, particularly in a production environment, all you can really do is verify that the traffic is being marked and classified properly.

What you're really looking for, when it comes to verifying if your QoS configuration is working, is for the counters in the policy-map interface command to increment.

So, for example, in the output below you can see that you're seeing packets under SIP and RTP

Class-map: VOIP (match-any)
  3860628 packets, 1070196895 bytes
  5 minute offered rate 0 bps, drop rate 0 bps
  Match: protocol sip
    97348 packets, 49867304 bytes
    5 minute rate 0 bps
  Match: protocol rtp
    3763280 packets, 1020329591 bytes
    5 minute rate 0 bps
  Match: access-group name MGNT
    0 packets, 0 bytes
    5 minute rate 0 bps
  Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5

 ****Please make sure to rate this comment****

Thank You.

[getaway51]

"sh policy-map interface gi0/1"

shows number of packets in each class-map

How to reset the counters to zero ? will affect traffic?

[cmarva]

in my experience, if you clear the counters on the interface where the service policy is applied, that will clear the counters in the service policy also.

[getaway51]

What is the right command?

[paul driver]

Hello

Using the show policy-map interface xx already stated - You could also create a MOC policy on a receiving rtr/switch to capture your expected traffic and see if qos is actually being processed as you expect it to be.

example:
Class-Map  DSCP0
match ip dscp 0

Class-Map  DSCP10
match ip dscp 10

Class-Map  DSCP22
match ip dscp 22
etc..

policy-map QOS
class DSCP0
class DSCP10
class DSCP20

int x/x
description receiving qos traffic
load interval 30
service-policy input QOS

[Joseph W. Doherty]

Generally, on Cisco devices, QoS does work as configured, and depending on the devices, you can often get some statistics such as match counts or drops. Some devices will even show counts of packets within a queue and/or even show (part) of the packet's contents in the queue(s).

That said, if you're getting results that appear that QoS isn't working as well as expected, one major gotcha, some Cisco devices have hardware interface FIFO buffers that take precedence over QoS queues. Only when the such a queue "overfllows", the overflow is directed to QoS queues.

You cannot bypass such interface buffers but you can minimize/mitigate their impact to your QoS policy by setting its size smaller (even to minimum values). This whitepaper, https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html?dtid=osscdc000283, discusses the tx-ring-limit with regard to ATM, but I believe the issue isn't limited to just ATM interfaces (or the noted hardware).

BTW, on some routers, I've "wondered" how QoS shapers actually work with nested CBWFQ policies. I suspect some device manage a shaper's queues separate from the defined CBWFQ policy queues.

[Georg Pauwen]

Hello,

in addition to the other posts, the document below lists most of the available MLS/MQC show commands (and examples):

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/118629-technote-qos-00.html