show policy-map interface

When using 'show policy-map interface' for troubleshooting, the first step is to understand what healthy output looks like. For a class with a 'priority' command (low-latency queue), you expect to see 'priority queueing' and counters for 'packets matched' and 'bytes'. The 'drop rate' should be zero or very low if the priority traffic is within the allocated bandwidth. For classes with 'bandwidth' or 'shape', you expect to see queue depths that are not consistently high, and 'total drops' should be minimal. For policing, the 'conform' and 'exceed' counters indicate how much traffic is within or above the policed rate; a high 'exceed' count with drops indicates that traffic is being dropped.

Key fields to focus on: - 'packets matched' and 'bytes': Shows how much traffic has been classified into each class. If this is zero for a class that should have traffic, the classification (match criteria) may be incorrect. - 'offered rate' and 'drop rate': The offered rate is the actual traffic rate; the drop rate is the rate at which packets are being dropped (by policing or shaping). A high drop rate relative to offered rate indicates congestion or overly restrictive policies. - 'queue depth' and 'total drops': For queuing actions, queue depth shows how many packets are waiting; if it is consistently near the queue limit, the queue is congested and drops may occur. - 'conformed' and 'exceeded' (policing): These show how many packets met the policed rate (conformed) and how many exceeded it. If exceeded packets are dropped, that explains packet loss.

Common symptoms this command helps diagnose: - Voice quality issues: Check the priority class for drops. If the priority class is dropping packets, the voice traffic may be exceeding the allocated bandwidth, or there may be a misconfiguration (e.g., priority not set correctly). - Slow data transfers: Check the best-effort class for shaping or policing drops. If the shaping rate is too low, traffic will be delayed or dropped. - Unexpected packet loss: Look at all classes for 'drop' counters. If a class has drops but the interface itself (show interfaces) has no errors, the drops are likely due to QoS policing or queue limits.

Step-by-step diagnostic flow: 1. Identify the interface experiencing issues (e.g., slow throughput, high latency). 2. Run 'show policy-map interface <interface>' to see the applied policy and statistics. 3. Check if the policy is applied in the correct direction (input/output). 4. Look at each class: verify that traffic is being matched (packets matched > 0). 5. For classes with policing, compare offered rate to CIR. If offered rate > CIR and exceed drops are high, the policer is too restrictive. 6. For classes with shaping, check queue depth. If queue depth is consistently high, consider increasing the shaping rate or queue limit. 7. For priority classes, ensure the priority bandwidth is not oversubscribed. If drops occur, either increase the priority bandwidth or reduce the amount of priority traffic. 8. Correlate with 'show interfaces' to see if there are any interface errors (CRC, collisions) that could also cause drops. 9. Use 'show queueing <interface>' to see detailed queue statistics (e.g., weighted fair queueing). 10. If the problem persists, consider using 'debug policy-map' (with caution) to see real-time packet matching and actions.

Correlating with other commands: 'show interfaces' gives overall interface statistics including output drops, which may be due to QoS. 'show queueing' provides per-queue details. 'show class-map' and 'show policy-map' show the configuration. 'show access-lists' verifies the match criteria. By combining these, you can pinpoint whether the issue is classification, policing, shaping, or queuing.