Your question's pretty broad. There's a lot of different commands you can use to troubleshoot and monitor QoS, so I'll focus on the primary question you have, which is how to reasonably verify your QoS configuration is working and how to read the policy-map interface output.
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 your provided:
Class-map: VOICE (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 NEC-PBX
0 packets, 0 bytes
5 minute rate 0 bps
Priority: 40% (340 kbps), burst bytes 8500, b/w exceed drops: 5
You can see that you're seeing packets under SIP and RTP, but not NEC-PBX. If you know you're getting SIP and RTP traffic across a link, you should see the packet counts increment and that's a reasonable way to know that your configuration is basically working.
Yes, the restrict and protect modes can be violated any number of times without shutting down the port since they are not designed to do that; they will drop packets with unknown source addresses:
See Configuring the Port Security Violation Mode on a Port on page 62-6:
- protect—Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the
maximum value.
- restrict—Drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the
maximum value and causes the SecurityViolation counter to increment.
- shutdown—Puts the interface into the error-disabled state immediately and sends an SNMP trap notification.
Best Answer
It really depends on your philosophy and resources. You can quickly fill a switch log with violations, making it hard to troubleshoot real problems (switch logs can only be so big). You really need to use a separate logging server with something like this.
You want to log violations. To some people it is enough to just drop the traffic. In some cases, the extra overhead and traffic of logging a lot of violations is too much, or they may not have the logging infrastructure necessary to take advantage of it. The three different modes give you the flexibility to choose.