If you've been chasing output drops on a Cataylst devices and you've already ruled out the obvious causes...oversubscribed uplinks, mismatched speeds, an undersized queue design...the next lever worth pulling is the soft queue max buffer. It's a single global knob, qos queue-softmax-multiplier, that can cut microburst-driven drops without touching your existing QoS policy-maps. Here's how it works, how to tune it safely, and when to reach for real QoS design instead. This comes that you at least have a basic understanding of QoS.

Hard buffers vs. soft buffers

Every port on a Catalyst switch draws from a shared pool of memory. On the 9K it's called the Packet Buffer Complex (PBC); on the 3850 the same concept applies under the Dynamic Thresholding & Scaling (DTS) name. Either way, that pool is split two ways:

  • Hard buffers are reserved exclusively for a queue. They're guaranteed, but fixed. A queue with a priority level 1 class gets hard buffer equal to its configured queue-buffers ratio, and that allocation never changes based on system load.
  • Soft buffers are shared. They're what a queue can borrow from the global pool during a burst, on top of any hard allocation. The catch: soft buffer is over-subscribed by design, so how much a queue actually gets depends on what every other port and queue is doing at that instant. Cisco's Dynamic Threshold and Scale (DTS) mechanism on the ASIC rebalances this in real time.

In show platform hardware fed active qos queue config interface, this shows up as the Softmax column. qos queue-softmax-multiplier scales that ceiling.

The command

Switch(config)# qos queue-softmax-multiplier <percent>
  • Global configuration, applies to every non-priority-level-1 queue on every interface.
  • Default is 100 (1x, no scaling).
  • Range depends on platform and software: Catalyst and most platforms top out at 1200 (12x); some newer models on latest code go as high as 4800 (48x).
  • Priority level 1 queues are exempt. Their softmax is locked equal to hardmax by design, so this multiplier only affects best-effort and priority level 2 queues.

Under the hood, softmax is computed as:

Softmax = Base Buffer × (Queue Ratio / 100) × Hidden Multiplier (400%, fixed) × (User Multiplier / 100)

So moving the user multiplier from 100 to 1200 doesn't just triple your buffer headroom. Combined with the fixed 400% hidden multiplier already baked in, it's a 12x jump in the ceiling that queue can borrow up to.

Verifying the effect

Two commands do the verification work. First, the per-interface, per-queue view:

Switch# show platform hardware fed active qos queue config interface <intf>

Look at the Softmax column before and after the change. It should scale with the multiplier you set.

Second, check the global pool itself:

Switch# show platform hardware fed active qos queue stats interface <intf>

GlobalSoftLimit and GlobalHardLimit show how the PBC is currently partitioned. Increasing the softmax multiplier doesn't shrink GlobalHardLimit but it does raise the ceiling any single port/queue can draw from the shared pool.

To actually confirm drops are improving, watch:

Switch# show interfaces <intf> | include drop
Switch# show policy-map interface <intf>

before and after, ideally over a burst-heavy window rather than a quiet one.

Tuning approach

  1. Baseline first. Capture current output drop counts per interface before changing anything. Without a baseline you can't tell if the change helped.
  2. Move incrementally. Jump from 100 to 300, let it run, check drops, then step up (300 → 600 → 900 → 1200) rather than going straight to max. This isn't strictly required by the hardware. It's just good change discipline on a global, always-on setting.
  3. Watch for cross-port contention. Because soft buffer is shared, a burst-heavy port using an aggressive multiplier can, in theory, starve other ports of soft buffer during simultaneous congestion. In practice, engineers running max (1200) in production on 9300 stacks report drop reduction with no observed side effects but "in theory" is still worth monitoring for, especially on switches with many congested ports at once.
  4. Consider queue count as a second lever. The shared pool is divided among however many queues are configured per port. Dropping from eight queues to three or four (if your QoS design allows it depending on hardware/software) hands each remaining queue a proportionally larger slice of the same pool.
  5. Know the queue-limit interaction. If a class already has three queue-limit statements configured (the max supported per class for WTD thresholds), the hidden 400% multiplier is silently disabled for that queue. Only your queue-softmax-multiplier setting still applies. If you've tuned queue-limit heavily and buffer allocation looks lower than your math predicts, this is why.

Where this doesn't help

This setting absorbs microbursts. Short, transient spikes where a queue needs a burst of headroom for tens or hundreds of milliseconds. It does not fix sustained oversubscription. If an interface is consistently running above wire rate for seconds at a time, no amount of soft buffer will prevent drops. That's a bandwidth or QoS policy problem, not a buffer problem. Raising the multiplier on a link that's simply undersized will just delay the drop, not prevent it, and can add latency/jitter to real-time traffic sitting behind the burst.

When to reach for full QoS design instead

queue-softmax-multiplier is a blunt instrument: it's global, it doesn't distinguish between traffic types, and it only changes how much a queue can hold, not how fairly or quickly that queue gets serviced. It's the right first move when drops are transient and traffic is largely undifferentiated. It's the wrong tool in a few specific situations, where you should build out an actual MQC policy-map instead:

  • Latency- or jitter-sensitive traffic is involved. Bigger buffers mean packets sit longer before transmission. That's fine for a bulk file transfer, but bad for voice or video, where added queuing delay shows up as jitter or choppy audio even if drops go to zero. This is the classic bufferbloat trade-off. Real-time traffic belongs in a priority (LLQ) queue with policing or shaping to cap its rate, not in a bigger best-effort buffer.
  • Traffic classes need to be protected from each other. Softmax raises the ceiling for every non-priority queue equally; it doesn't stop one greedy best-effort flow from crowding out another class's fair share of scheduling time. If bulk backup traffic is starving a business-critical app on the same best-effort queue, the fix is classification plus bandwidth remaining percent (WRR) or a separate queue with its own queue-buffers ratio not a bigger shared pool.
  • You need selective, traffic-aware dropping. queue-limit with WTD thresholds (per DSCP or CoS) lets you drop lower-priority markings first as a queue fills, protecting higher-priority traffic in the same class. Softmax has no concept of marking. It grows or shrinks the whole queue's ceiling uniformly.
  • Congestion is sustained, not bursty. If an interface runs at or above line rate for extended periods, you need more bandwidth, shaping/policing to smooth demand, or a policy that guarantees minimum bandwidth per class. No buffer setting fixes a link that's genuinely full.
  • You're already relying on multiple queue-limit statements. Recall that a third queue-limit on a class disables the hidden 400% multiplier for that queue. At that point you're already deep into WTD-based QoS design, and softmax is a secondary lever, not the primary one.

In short: use queue-softmax-multiplier to buy headroom against bursts on an otherwise healthy, largely single-class link. Reach for classification, priority queuing, bandwidth allocation, and queue-limit/WTD when you have multiple traffic types competing for the same port and need to control which traffic gets dropped, delayed, or guaranteed bandwidth. Buffer tuning alone can't make that decision for you.

Conclusion

qos queue-softmax-multiplier is a low-risk, high-leverage change for microburst-driven output drops on Catalyst switches: one global command, no policy-map rewrite, reversible instantly. Baseline your drops, step the multiplier up incrementally toward your platform's max and verify with show platform hardware fed active qos queue config/stats interface at each step rather than assuming the math worked. But if drops trace back to competing traffic classes, latency-sensitive flows, or a genuinely oversubscribed link, don't stop at buffer tuning. That's where classification, priority queuing, and bandwidth allocation should be your next point of focus.