Troubleshooting OLT Traffic Policing vs Shaping: Configuration, Compatibility & Error Resolving

Overview & Thematic Scope

In passive optical networks (PON), managing upstream and downstream bandwidth effectively is critical for maintaining service level agreements (SLAs) and ensuring a high-quality subscriber experience. Two primary mechanisms—traffic policing and traffic shaping—are used on the Optical Line Terminal (OLT) to control data flow, yet they operate differently. Policing drops excess traffic immediately, while shaping buffers it to smooth bursts. This FAQ addresses the most common technical challenges network engineers face when configuring, troubleshooting, and deploying these QoS tools. We dive deep into configuration syntax, interoperability issues, and performance optimization strategies, providing expert-level answers suitable for Tier 3 support and senior network architects.

Frequently Asked Questions

Q1: What is the fundamental difference between traffic policing and traffic shaping on an OLT?

Direct Answer: Traffic policing drops packets that exceed a configured bandwidth limit, while traffic shaping buffers and queues excess traffic to smooth it out.

Specifically, policing uses a token bucket algorithm to measure incoming traffic. If a packet exceeds the committed information rate (CIR) or peak information rate (PIR), it is either dropped or marked down (e.g., with a lower Differentiated Services Code Point—DSCP value). Shaping, on the other hand, uses a buffer to hold packets that exceed the rate, releasing them at a controlled speed to prevent tail drops downstream. Policing is better suited for ingress interfaces to enforce strict SLAs, whereas shaping is typically applied on egress interfaces to avoid packet loss in congested core networks.

Q2: Why is my OLT policing dropping all traffic even when the CIR seems high enough?

Direct Answer: This is usually caused by a mismatch between the committed burst size (CBS) and the actual traffic burst pattern, or by a dual-token bucket misconfiguration.

In many OLT implementations (e.g., Huawei, Nokia, or ZTE), the policing algorithm uses two parameters: CIR and CBS. If the CBS is set too low, even short, legitimate bursts of data (e.g., TCP window expansions or HTTP/3 downloads) will exceed the bucket depth, causing all packets in that burst to be dropped. To resolve this, calculate the expected maximum burst size based on the maximum transmission unit (MTU) and typical TCP burst window. Increase the CBS value to at least (MTU * 10) to accommodate modern traffic profiles, and verify that the PIR is not set to the same value as the CIR, which prevents any burst allowance.

Q3: Can I use traffic shaping to fix latency spikes caused by policing on my upstream interface?

Direct Answer: No, shaping on the upstream interface will not fix policing-related latency; you must reapply the shaping on the egress interface of the OLT or the source router to prevent the upstream policer from dropping packets.

Latency spikes often occur when a downstream policer (e.g., on a provider edge router) drops packets, triggering TCP retransmissions and back-off algorithms. While shaping can be applied to the OLT’s upstream queue to artificially limit output, this simply shifts the buffering point. To truly solve the issue, configure a hierarchical shaping policy on the OLT’s egress that matches the CIR of the upstream policer, ensuring that the traffic leaves the OLT at a rate that is below the policer’s threshold, thus eliminating drops at the next hop. This is commonly referred to as ‘policer-aware shaping’.

Q4: What are the compatibility risks when configuring policing on a mixed-vendor OLT and ONT environment?

Direct Answer: Compatibility risks primarily involve the interpretation of 802.1p priority bits and the lack of standardization for certain vendor-specific Extended Service Mapping (ESM) fields.

When deploying traffic policing in a multi-vendor PON (e.g., a Nokia OLT with Huawei or Calix ONTs), you may encounter issues where the policer fails to recognize the internal priority markings. This is because some vendors use proprietary T-CONT (Transmission Container) mappings. To mitigate, use standard DiffServ markings and ensure that the policing policy references the outer VLAN priority (P-bit) rather than the inner, as this is universally recognized. Additionally, configure the OLT to fall back to a default policing profile for unrecognized ONT models to avoid service disruption during auto-discovery.

Q5: How do I troubleshoot high CPU utilization on my OLT when enabling traffic shaping on multiple service queues?

Direct Answer: High CPU utilization during shaping is often due to excessive buffer management overhead; move shaping to hardware-based ASIC queues and adjust the queue depth parameters.

Modern OLTs use ASICs for queuing, but if the shaping policy uses a large number of individual queues (e.g., per-subscriber shaping), the control plane can become overwhelmed. First, use the `show shaping statistics` command to identify if the CPU is handling packet reclassification. If so, simplify the policy by using port-level shaping rather than per-queue shaping, and leverage the PON’s inherent dynamic bandwidth assignment (DBA) for subscriber-level granularity. As a best practice, limit the shaping buffer size to 100ms of traffic to prevent bufferbloat, which also reduces CPU cycles spent on buffer management.

Q6: What does the error ‘Token Bucket Underflow’ indicate during OLT policing, and how can I resolve it?

Direct Answer: ‘Token Bucket Underflow’ indicates that the policer’s token bucket is empty, but traffic continues to arrive; this requires an increase to the CIR or CBS in the policer profile.

This error typically occurs in high-speed upstream scenarios (e.g., 2.5 Gbps upstream) where a continuous flow overwhelms the token generation rate. To resolve, recalculate the traffic profile using a traffic meter to determine the 95th percentile of upstream utilization. Increase the CIR to match this value, and set the CBS to 50ms worth of traffic. If the error persists on a specific service port, check for a hardware limitation where the policer shares a token bucket across multiple logical interfaces; you may need to allocate a dedicated policer instance for that port.

Q7: Is it possible to perform traffic shaping on an OLT without impacting the DBA (Dynamic Bandwidth Assignment) cycle?

Direct Answer: Yes, you can perform shaping independently of DBA, but you must synchronize the shaping intervals with the DBA cycle to avoid report inefficiencies.

OLT DBA operates on a 125 microsecond frame cycle. If traffic shaping is applied at a granularity smaller than this cycle (e.g., millisecond-based shaping), it can cause the ONU to report inaccurate buffer occupancy, leading to under-allocation or over-allocation of bandwidth. To avoid this, configure the shaping rate in multiples of the DBA granularity and use a dual-rate, dual-bucket shaper that aligns with the standard G.987.3 recommendation. This ensures that the ONU’s bandwidth map (BWmap) is accurately populated, preventing upstream jitter and synchronization loss.

Q8: How can I verify if policing or shaping is the root cause of packet loss in my OLT network?

Direct Answer: Utilize the OLT’s built-in QoS monitoring counters and perform an end-to-end Iperf test with Differentiated Services Code Point (DSCP) marking to identify where packets are being dropped.

First, check the egress and ingress drop counters on the OLT’s interface. Police drops are typically counted as ‘discarded’ packets, while shaping drops are indicated by ‘tail drops’ or ‘queue full’ counters. If drop counters show no errors on the OLT, the issue likely lies upstream or downstream. In that case, perform an Iperf test using a UDP stream with a fixed bitrate. Increase the rate incrementally and plot the throughput versus the configured CIR. A flat line on the throughput graph indicates policing, while a gradual decrease indicates shaping buffer depletion. Use remote span (R-Span) or packet capture to pinpoint the exact node of loss.