On MX304 (AFT/Trio6), removing an output-traffic-control-profile (TCP) from an IFL while a sibling IFL on the same AE interface still has an active TCP with a guaranteed-rate causes egress traffic on the unshapen IFL to collapse instead of reverting to line rate.

Not observed on EA-based platforms (MX480/MX960).

- Egress throughput collapses after TCP removal (~195 Mbps on 23.4; ~13.4 Gbpson 24.4, the latter matching the guaranteed-rate of the deleted profile).

- Queue drop rates of 80–88% on affected IFL queues.

- Sibling IFLs with active TCPs are unaffected.

- Re-applying the TCP immediately restores normal throughput.

- No COSD errors, no FPC crashes, no aftd-trio errors in logs.

This is expected H-QoS behavior on AFT platforms, not a software regression.

When any IFL on the AE has a TCP with guaranteed-rate configured, the IFD scheduler operates in PIR-CIR mode. In this mode, IFD remaining queues (which handle traffic not covered by an active IFL TCP) inherit their delay-buffer-rate from the IFD-level remaining-traffic-profile.

If no remaining-traffic-profile is configured at the IFD level, the delay-buffer-rate for remaining queues defaults to zero — causing near-total tail drops on any traffic that falls through to those queues.

On EA-based platforms, the ASIC incidentally allocated minimal buffer even at zero computed size, masking this condition. The AFT implementation is correct.

Configure a remaining-traffic-control-profile at the IFD level with an explicit guaranteed-rate. This ensures IFD remaining queues always have valid buffer allocation regardless of which IFL TCPs are active.

set class-of-service traffic-control-profiles <ifd-remaining-profile>

scheduler-map <your-scheduler-map>

shaping-rate <line-rate>

guaranteed-rate <line-rate

set class-of-service interfaces ae10 output-traffic-control-profile-remaining <ifd-remaining-profile>

BEST PRACTICE: On AFT-based H-QoS deployments, configure traffic profiles at every level of the scheduling hierarchy (IFD, IFL, queue). Leaving the IFD without a remaining-traffic-profile will trigger this condition whenever any IFL TCP with guaranteed-rate is present.

Reference:

https://www.juniper.net/documentation/us/en/software/junos/cos/topics/concept/hierarchical-scheduler-pir-cir-mode-cos-config-guide.html

After applying the fix, confirm at PFE VTY:

show class-of-service interface scheduler root-node-params <node-id>

Verify "Remaining Bandwidth" reflects expected line rate and "Mode" is correct.

Confirm TCP removal from any IFL no longer causes throughput collapse.