{{ result.summaryTitle }}
{{ result.primaryDisplay }}
{{ result.secondaryText }}
{{ result.statusText }} {{ result.classBadge }} {{ result.parentBadge }} {{ result.bestEffortBadge }}
Class allocation rows:
List every explicitly reserved class. Unallocated capacity is reported as best-effort headroom.
Class Share Behavior Priority Note Remove
%
Use this for provider overhead or a deliberate under-shape below line rate.
%
Keep 1.0 for strict reserved rates; raise it when planning max-limit or burst ceilings.
x
Default 33% keeps latency-sensitive reservations visible without changing allocation math.
%
ClassBehaviorShareReserved rateBurst ceilingNoteCopy
{{ row.className }}{{ row.behaviorLabel }}{{ row.percentDisplay }}{{ row.reservedDisplay }}{{ row.burstDisplay }}{{ row.note }}
CheckStatusActionReasonCopy
{{ row.check }}{{ row.status }}{{ row.action }}{{ row.reason }}
Tags: Devops, Diagnostics, Networking
Export to PDF Fullscreen
Customize
Advanced
:

Quality of service bandwidth allocation is the work of dividing a constrained link into traffic classes before congestion decides for you. Voice, live video, business systems, backups, default traffic, and background sync often share the same WAN or campus uplink, but they do not fail in the same way. Voice suffers when delay and jitter rise, while bulk transfer usually survives delay better than packet loss or starvation.

A useful QoS plan starts with the actual parent rate that the policy controls. That may be the shaped egress rate, the provider handoff, or a smaller under-shaped value chosen to avoid queueing in the wrong device. Class percentages then reserve slices of that usable parent rate. The leftover share still matters because unmatched traffic, control traffic, retransmissions, and default queues need room after named classes have taken their minimums.

QoS allocation sketch showing parent bandwidth reduced by headroom, then divided into reserved classes and best-effort capacity.

Bandwidth allocation is not the same as proving an application will perform well. It does not verify packet marking, queue hardware limits, provider treatment, loss behavior, or whether a vendor platform uses the same scheduler terms. It is a planning view for the numbers that will go into a class-based policy, and it is most useful when the same parent rate, class names, and reservation rules are kept consistent while alternatives are compared.

Strict and priority traffic deserves special review because it can protect delay-sensitive packets while also harming other classes if the protected share is too large for the link. A reservation plan should leave enough best-effort headroom for traffic that was not explicitly matched and should be checked against live interface counters before production changes are treated as complete.

Technical Details:

Class-based QoS usually begins by classifying packets and assigning forwarding treatment to traffic aggregates. DiffServ describes this as per-hop behavior selected by packet markings and enforced by policies such as shaping, policing, queueing, and dropping. The allocation math here focuses on the queueing budget after classification already exists: a parent rate is converted to Mbps, optional headroom is removed, and class percentages are converted into reserved rates.

The behavior label affects interpretation more than arithmetic. A strict priority or priority class is still assigned a percentage of the usable parent rate, but those classes are also summed for the priority review threshold. Guaranteed, weighted, limited, and best-effort behaviors use the same reserved-rate formula and then appear separately in the ledger, guidance rows, and charts.

Formula Core:

The primary calculation turns a parent rate into usable capacity, then multiplies each class share by that usable rate.

PMbps = Pentered×Uunit Pusable = PMbps×(1-Hpct100) Rclass = Pusable×Sclass100 Bclass = Rclass×M Sremaining = 100-∑Sclass

P is parent bandwidth, H is shaping headroom, S is class share percentage, R is reserved class rate, B is the planning burst ceiling, and M is the burst ceiling multiplier. Unit conversion uses Kbps = 0.001 Mbps, Mbps = 1 Mbps, and Gbps = 1000 Mbps.

Behavior and Review Rules:

Behavior How it is calculated How it is reviewed
Strict priority Share percent times usable parent bandwidth. Included in strict/priority total for the priority review threshold.
Priority class Same reserved-rate formula as other classes. Included with strict priority when checking the cap.
Guaranteed minimum Receives the entered share of usable parent bandwidth. Does not count toward the strict/priority threshold.
Weighted share Receives the entered share of usable parent bandwidth. Useful for ordinary data classes that still need planned capacity.
Scavenger / limited Receives the entered share, often a small percentage. Useful for background or bulk work that should not crowd priority traffic.
Best effort The unallocated share is added as a remaining-capacity row. Shows whether default and unmatched traffic still has capacity.

Validation and Boundaries:

Input or check Supported rule Result cue
Parent bandwidth Must be greater than zero. check inputs appears when the parent rate is missing or zero.
Class allocation rows At least one row is required. The input warning asks for a QoS class row when none is available.
Share Each row is clamped to 0% through 100%. Input audit reports adjusted rows.
Shaping headroom Clamped to 0% through 50%. Removed before class rates are calculated.
Burst ceiling multiplier Clamped to 1x through 10x. Changes the burst ceiling column only.
Priority review threshold Clamped to 0% through 100%. priority review appears when strict and priority shares exceed it.
Priority number Rounded and clamped from 1 through 8. Priority 1 is the highest row value in the editor.

Everyday Use & Decision Guide:

Use the shaped egress rate or provider handoff rate for Parent bandwidth. If the policy is applied below line rate to avoid upstream buffering, enter that smaller rate or use Shaping headroom to remove a deliberate reserve before the class math starts.

Start with the rows that will exist in the real policy. Give delay-sensitive voice and live media small, defensible strict or priority shares; put business-critical application traffic in guaranteed or weighted classes; keep background work in limited or scavenger classes. The sample rows are useful as a pattern, but the class names and notes should match the traffic selectors and operational language used by the team that will maintain the policy.

  • Check Total class reservation first. It tells you whether the named classes fit inside the usable parent rate.
  • Keep Best-effort headroom positive unless the policy is intentionally closed to unmatched traffic.
  • Use Priority review threshold as a planning alarm for strict and priority classes, not as a hidden change to the reserved-rate formula.
  • Set Burst ceiling multiplier above 1.0 only when you need a planning column for a max limit or burst value.
  • Review Input audit before copying results, because clamped shares or bounded advanced values can make a policy look cleaner than the raw entry was.

This is a good fit for pre-change review, WAN refresh planning, campus uplink policy sizing, and comparing alternative class mixes under the same parent rate. It is a poor fit for proving live queue behavior, because scheduler details, queue depth, platform limits, DSCP trust boundaries, and provider treatment still need device configuration and telemetry checks.

After the numbers look right, compare Allocation Ledger with the proposed policy and use Policy Guidance to decide what needs adjustment. If the status is overallocated or priority review, fix that before using the chart images or exported tables in a change record.

Step-by-Step Guide:

Work from the parent rate to class shares, then use the ledger and guidance rows to catch policy mistakes.

  1. Enter Parent bandwidth and choose Kbps, Mbps, or Gbps. The summary badge updates with the converted parent rate.
  2. Use Class allocation rows to add each reserved class. Fill in Class, Share, Behavior, Priority, and a short Note that identifies the traffic.
  3. Open Advanced when the parent rate needs Shaping headroom, a Burst ceiling multiplier, or a different Priority review threshold.
  4. Read the summary status. allocation ready means class shares fit and strict/priority share is inside the threshold; priority review or overallocated needs adjustment.
  5. Open Allocation Ledger to compare each class share with its reserved rate and burst ceiling. The final best-effort row shows what remains for default traffic.
  6. Open Policy Guidance for checks on total reservation, best-effort capacity, strict/priority share, parent headroom, burst planning, and input audit notes.
  7. Use QoS Share Stack and Class Rate Ladder when a visual review helps catch a class that is too large or a parent rate that was entered in the wrong unit.
  8. Use the CSV, DOCX, chart, or JSON exports after validation, not before. The exported values include the same class names, notes, rates, warnings, and totals shown in the result panel.

Interpreting Results:

The headline result is either reserved bandwidth or the fact that the policy is over 100% of usable capacity. Read it with the best-effort badge and Policy Guidance. A high reserved total with no best-effort headroom can block ordinary default traffic even when every named class looks reasonable by itself.

The burst ceiling is not additional reserved bandwidth. It is a planning value derived from the multiplier. Use it when a platform policy has a separate maximum or burst concept, and leave the multiplier at 1.0 when the policy should show only committed class rates.

Status or output Meaning Useful follow-up
allocation ready Class shares fit inside the usable parent rate and strict/priority share is inside the threshold. Compare the ledger with the actual policy syntax and class-map matches.
priority review Strict and priority class shares are above the configured review threshold. Lower priority shares, police priority traffic, or raise the threshold only with a clear platform reason.
overallocated Named class shares add up to more than 100% of usable parent bandwidth. Reduce the entered shares by the overage before using the policy numbers.
Best-effort headroom Unallocated capacity remains for unmatched and default traffic. Keep it positive unless every default queue consequence has been reviewed.
Input audit One or more entered values were clamped to supported bounds. Review the original entries and correct the source values if the bound changed intent.

Do not treat a clean allocation as a full QoS deployment check. It does not confirm packet marking, queue attachment, hardware queue mapping, drop policy, or provider class treatment. Use the output as the bandwidth plan, then validate device counters and traffic classification after the change.

Worked Examples:

Default gigabit WAN mix:

A 1000 Mbps parent with the sample rows reserves 10% for voice, 25% for video, 30% for critical data, and 5% for scavenger traffic. Allocation Ledger shows 100.00 Mbps, 250.00 Mbps, 300.00 Mbps, and 50.00 Mbps, with 300.00 Mbps remaining for best effort. The strict and priority classes total 35.0%, so the default 33% threshold produces priority review.

Under-shaped branch link:

A 500 Mbps parent with 5% shaping headroom leaves 475.00 Mbps usable bandwidth. If voice is 8%, video is 12%, critical data is 35%, and backup is 10%, the named classes reserve 308.75 Mbps and best effort keeps 166.25 Mbps. Policy Guidance should show the total reservation inside the parent and the headroom row marked as reserved.

Overallocated change draft:

A 100 Mbps policy with three classes at 40%, 35%, and 30% adds up to 105%. The summary switches to overallocated, the best-effort row drops to 0.0%, and Total class reservation tells you to reduce reserved shares by 5.0%. The right fix is to lower class shares, not to copy the table and hope the platform scheduler resolves the conflict.

FAQ:

Which parent bandwidth should I enter?

Use the bandwidth controlled by the parent policy. For a WAN edge, that is often the shaped egress rate or provider handoff rather than the physical interface speed. If you enter line rate while the real bottleneck is smaller, every class rate will be too high.

Why does the result say priority review?

priority review appears when rows marked Strict priority or Priority class exceed the Priority review threshold. The warning does not change the reserved-rate math; it tells you to review whether latency queues could crowd other classes.

Does the burst multiplier reserve more bandwidth?

No. Burst ceiling multiplier only changes the Burst ceiling value in the ledger. The reserved share total, best-effort headroom, and overallocated check still use the entered class percentages.

What should I do when shares exceed 100%?

Reduce one or more class shares until Total class reservation is within the parent. The best-effort row is forced to zero when the total is over 100%, so a copied policy at that point would hide the default-traffic problem.

Are class rows uploaded for calculation?

The allocation updates in the browser and the tool has no upload control or server-side calculation path for the class rows. Treat class notes as export content, because copied tables and JSON include those notes exactly as entered.

Glossary:

QoS
Quality of service, the policy framework used to classify traffic and apply different forwarding treatment.
Parent bandwidth
The rate controlled by the QoS policy before class percentages are applied.
Usable parent
Parent bandwidth after optional shaping headroom has been removed.
Strict priority
A latency-focused class behavior that should be kept small enough to avoid starving other traffic.
Best-effort headroom
Capacity left after explicitly reserved classes have taken their shares.
Burst ceiling
A planning value made by multiplying the reserved class rate by the burst ceiling multiplier.
Priority review threshold
The percentage cap used to flag strict and priority classes for closer review.

References: