QoS: Understanding packet counters.

[NetworkingGeek1]

Hello experts,

I have some confusion with packet counters from "show policy-map interface". I don't understand, where counters just showing the hits on class and where actually packets which were processes by policy-map. Below is example of the show command from the router and I don't understand if policy-map is actually working or not. There is an article form Cisco, but it's quite old and looks like it's not 100% relevant anymore, because for example, I didn't find "pkts matched/bytes matched" field in my output. Article: https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-avoidance/10107-showpolicy.html

show policy-map interface GigabitEthernet0/1/2
GigabitEthernet0/1/2

Service-policy output: parent

Class-map: class-default (match-any)
492370 packets, 212703840 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 1250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 300000000, bc 1200000, be 1200000
target shape rate 300000000

Service-policy : child

queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0

Class-map: voice (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp ef (46)
Priority: 15% (60000 kbps), burst bytes 1500000, b/w exceed drops: 0

Class-map: video (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp af41 (34)
Queueing
queue limit 1250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth remaining 10%

Class-map: data (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp af21 (18)
Queueing
queue limit 1250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth remaining 35%

Class-map: SCAVENGER (match-any)
0 packets, 0 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: ip dscp af11 (10)
Match: access-group name scavenger
Queueing
queue limit 1250 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
bandwidth remaining 5%

Class-map: class-default (match-any)
492370 packets, 212703840 bytes
30 second offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 1250 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
(pkts output/bytes output) 0/0
bandwidth remaining 50%
Fair-queue: per-flow queue limit 312 packets

[NetworkingGeek1]

Especially I confused with this field: "(pkts output/bytes output)". What does represent? Packets which match the criteria of class-map regardless if interface is congested or packets which match actual policy map when interface is congested?

[NetworkingGeek1]

Anyone can help with it, please? @Joseph W. Doherty  maybe you can help please?

[Joseph W. Doherty]

"pkts matched/bytes matched"  ==>> (pkts output/bytes output) in your output

With the forgoing "translation", why/when the different counters are updates, still holds.

BTW, further briefly reviewing that reference, I agree with Cisco on the causes of congestions, but disagree that congestion is when the tx-ring overflows.  Further, I disagree that waiting until the class counter and match counter, when nearly equal, should be investigated.  Not saying they shouldn't, but waiting until that happens, may lead to detecting an issue "late".

Also BTW, congestion, is typical within almost any data network.  The question, though, is your congestion adverse to your traffic service needs?

Lastly, as to whether your service policy is working correctly, often Cisco software does work correct, although, of course, you can bump into a bug.  Your policy stats show your traffic is not triggering the shaper and it's not matching any defined class.  Insufficient information to determine if that's actually correct processing.

[NetworkingGeek1]

Hello @Joseph W. Doherty  Thank you for the reply. Regarding my policy, I think I know why it doesn't work. Config "source interface" under DMVPN tunnel refers to interface vlan, not the physical interface where QoS is applied to. Most of the traffic is going through the tunnel and that's why we don't see any match in that policy map. But what I still don't understand, why traffic going to the Internet, which are going through that physical interface wasn't shaped to 300 Mbps.

Regarding counters: In that Cisco's article, which I shared, it's stated that "pkts matched/bytes matched" means packets which not only matched the class-map, but also were processed by policy-map. So, if "pkts matched/bytes matched"  = "pkts output/bytes output", then "pkts output/bytes output" shows packets which were processed by policy map during congestion.

[Joseph W. Doherty]

Ah, with tunnels with policy on physical interface, by default, QoS only "sees" the tunnel packet.  Also, unless you're using really very old Cisco equipment (and IOS), tunnel packets do copy original packet's ToS byte, so you can match on that.

To deal with tunnel packets on a physical interface, beyond matching on ToS alone, you can use the pre-classify command on the tunnel interface, and then the physical interface can "see" more of the original packet's contents (a shadow copy), but not all.  (I believe packet header and maybe [?] UDP/TCP header.)  Or, you apply policy on tunnel, which "sees" all of packet's contents before encapsulation.

As to why your getting above 300 Mbps, again, as with your prior posting, I'm still not clear exactly how you're configured.  I still suspect, somehow traffic is bypassing your policy.

I haven't reread the Cisco article, but I think your confusion (?) may be due to you not, yet, grasping matching a class-map vs. being processed by the policy map and what Cisco means by congestion (again different from how I define it).

There's a reason, even with modern educational media, some education still benefits from having an instructor/teacher that you can interact with, when stumbling with some concept.