LibreQoS
Toggle navigation menu
Why LibreQoS

Published queue management. Explicit network control.

LibreQoS combines inspectable Linux queue algorithms, a configured shaping hierarchy, and operator-visible evidence from shared capacity down to individual circuits.

Deploy LibreQoSSee the architecture
Inspect each layer of the shaping path

Conceptual hierarchy. The configured tree determines which parents share capacity.

  1. 01Shared links

    Backhaul and site capacity

  2. 02Access parents

    AP, OLT, and configured groups

  3. 03Circuits

    Subscriber plan envelopes

  4. 04Flow queues

    Published CAKE / fq_codel behavior

Inspectable automation

See what changed, why, and which limits apply

Illustrative StormGuard evaluation for a variable-bandwidth WAN. Start with a selected target in dry-run mode; review its decisions before allowing live adjustments.

  1. Set the operating bounds

    Choose the managed node and minimum download/upload floors. StormGuard is intended for variable WAN links or a small number of highly variable access points.

  2. Inspect the proposed response

    In the Network Tree StormGuard tab, review the current limit, bounds, strategy, cooldown, and decision reason as demand and quality signals change.

  3. Confirm the outcome

    Dry-run evaluates decisions without live queue changes. When live, distinguish applied, skipped, and failed outcomes; optional CSV logs retain decision and change telemetry.

Read the StormGuard operating guide

Scope, configuration, dry-run, decision telemetry, and rollout checks.

Engineering reference

Inspect the documented behavior

Read the source and deployment guidance, then validate the configuration and results on your own network.

How are flows isolated?
Every shaped circuit gets its own queue envelope: HTB classes per Site, AP, OLT, and circuit, with CAKE (or fq_codel) as the leaf qdisc providing per-flow queues inside each circuit. Documentation
Does control depend on TCP?
No. Packets are classified by IP 5-tuple hash, so TCP, QUIC, and UDP all receive the same queue discipline. There is no TCP proxy in the path. Documentation
Is application DPI required?
No. Flow identity is resolved through a flow cache and longest-prefix match on addressing data — payload inspection is not part of the design. Documentation
Can it enforce subscriber plans?
Yes. Circuits carry per-circuit min/max rates, synced from billing systems such as Splynx, UISP, Sonar, Powercode, VISP, WISPGate, and Netzur — or from RADIUS accounting for dynamic circuits. Documentation
What about shared capacity?
The network hierarchy is modeled explicitly. Shared capacity at Sites, APs, OLTs, and backhaul links gets its own HTB class, so congestion is contained at the constrained branch instead of degrading everyone upstream. Documentation
How is congestion handled?
Explicit active queue management: CoDel inside fq_codel, and COBALT (CoDel + BLUE) inside CAKE, with fair scheduling between flows. Documentation
How is it deployed?
Inline as a Layer-2 Linux bridge between the edge router and the rest of the network, with a documented bypass path for production. Single-interface mode exists but is advanced and uncommon. Deployment guide
What hardware does it need?
Commodity x86 with an XDP-capable NIC (Intel X520/X710-class or Mellanox ConnectX). The eBPF/XDP fast path handles high throughput on ordinary server hardware — no proprietary appliance. Sizing and requirements
Is the source available?
The packet-processing core is GPL2 open source, so the algorithms shaping your traffic can be inspected. Insight adds commercial analytics. The v2.2 Node API is available at 1,000 or fewer mapped circuits without a subscription; larger mapped-circuit deployments require a valid entitlement. GitHub
What about central visibility?
Insight adds multi-shaper analytics: ASN-level analysis, RTT and retransmit history from 15 minutes to one year, and RTT, retransmit, and capacity heatmaps for every Site, AP, and OLT. Explore Insight
What evidence do operators get?
Per-circuit RTT, retransmits, flow detail, and QoO — an estimate of internet quality based on latency and loss, defined in the IETF IPPM QoO draft. Documentation
Can the result be verified independently?
Yes. The public Internet Quality Test measures idle and loaded latency, loss, throughput, and a QoO grade — anyone can run it against your network before and after deployment. Run the test
See how CAKE handles competing traffic ↗

Operating model

Connect queue control to evidence

Published active queue management makes the queue behavior inspectable. The configured hierarchy gives shared capacity its own explicit limits, while leaf queue disciplines provide fairness within each circuit.

The operator can inspect queue limits, throughput, RTT, retransmits, and circuit context. Insight adds history from 15 minutes to one year and centralized analysis across one or many shapers.

Inspectability is a basis for evaluation. Confirm the result with a representative pilot, the same before-and-after load conditions, and a tested bypass path.

Evaluating specific vendors? Compare LibreQoS and Bequant or compare LibreQoS and Preseem, each cited to the vendors' own published materials.

In Practice

What the architecture looks like in operation

Four design decisions operators notice in day-2 operations, not just in benchmarks.

01

Smallest safe change

The queue engine diffs the desired queue tree against live state and applies the smallest safe delta, so updates land without disrupting the network.

Learn more
02

Pass-through by default

Traffic that is not mapped to a shaped circuit passes through untouched. Unmapped traffic never lands in a catch-all queue.

Open
03

Adaptive queue discipline

TreeGuard moves circuits between CAKE diffserv4 and fq_codel automatically, inside utilization, RTT, and CPU guardrails you control.

Open
04

Honest baselines

Observe mode removes the shaping tree entirely, so you can measure a true before/after on your own network instead of trusting a vendor curve.

Learn more

Verify It Yourself

Don't take the architecture on faith

Run the Internet Quality Test on a busy-hour circuit, deploy LibreQoS on spare hardware or a pilot site, and run it again. The test measures idle and loaded latency, loss, throughput, and a QoO grade — the same evidence your subscribers would feel.

Start 1-Line InstallRun the Internet Quality Test
Deploy

Evaluate the architecture on your own network

Run the 1-line install on a pilot site, point your topology at it, and measure busy-hour latency before and after.

Deploy LibreQoSSee Pricing