v1.4

LibreQoS v1.4 Change Summary

Version 1.4 is a huge milestone. A whole new back-end, new GUI, 30%+ performance improvements, support for single-interface mode.

Some Statistics

• 1,097 Commits since 1.3.1
• 43,282 Lines of Code
  • 16,917 lines of Rust
  • 16,508 lines of HTML & JavaScript
  • 7,087 lines of Python
  • 2,770 lines of C

Peak Performance (So Far)

• Tested single-stream performance of just under 10 gbit/s on a 16-core Xeon Gold (single interface architecture, using 8 cores for each direction). The flow was shaped with Cake, and retained good (<10 ms RTT latency) performance.
• Tested 25 gbit/s total throughput on the same system. CPU was not saturated---we didn't have a bigger network to test!
• Running live at ISPs with 11 gbit/s of real customer performance and plenty of room to grow.

New Architecture

• Rust-based back-end provides:
  • lqosd - a daemon that manages:
    • Loading/setup/unloading eBPF programs.
    • Gathers statistics directly from eBPF.
    • Provides a local "bus" for transporting data between components.
    • Sets "tunables", replacing the need for a separate offloading service.
  • lqtop - a console-based utility for viewing current activity.
  • lqos_node_manager - a web-based GUI that:
    • Monitors current activity.
    • Monitors system status.
    • Provides "best/worst" summaries of RTT.
    • Provides visibility into the working of queues.
    • Categorizes traffic to match your network hierarchy, letting you quickly find the bottlenecks.
    • Let's you browse and search your shaped devices.
    • Lists "unknown IP addresses" that are passing through the shaper but do not have a rule associated.
    • Allows you to view and edit the LibreQoS configuration.
  • lqos_python - provides Python access to the bus system.
  • lqos_setup - builds enough configuration files to get you started.
  • lqos_users - authentication for the GUIs.
• High-performance Python script:
  • Batches TC commands for fast execution.
  • Batches bus-transactions to associate IP subnets with users for fast execution.
  • Improved scheduler for InfluxDB graphing.

High Performance Bridge (Bifrost)

• Optionally replace the Linux bridge system with an XDP-based bridge accelerator.
• Throughput is 30% higher in this mode.

Packet and Flow Analysis (Heimdall)

• Viewing a circuit in the web UI displays a summary of IP traffic flows for that circuit.
• A "capture" button will capture packet headers, and allow nanosecond-level analysis of traffic data.
• You can download the packet captures in libpcap format, for analysis in Wireshark and similar tools.
• Configure the capture delay in /etc/lqos.conf

Single-interface Mode

• Operate with a single network interface and VLANs for "in" and "out".

Graphs

• Graph current throughput, shaped and unshaped.
• Graph CPU and RAM performance.
• Graph individual Cake shaper tins, backlog, delays.
• TCP "round trip time" histogram showing overall network latency performance.
• Per-network node traffic graph.
• Per-network node RTT latency histogram, to let you zero-in on troublespots.

Integration Improvements

• UISP integration now uses a full cost-based spanning tree (Dijkstra) to determine node placement in topology. #328

Miscellaneous

• build_rust.sh builds the entire package from a Git update, with minimal (<1 second) downtime.
• build_dpkg.sh assembles the entire system into an Ubuntu/Debian .deb installer.
• Sample .service files for systemd integration.
• Real-time adjustment to tunables.
• Redact text into Klingon to allow screenshots without sharing customer data.
• Preliminary support for reading IP data inside MPLS packets, as long as they are ordered "VLAN->MPLS->VPLS" and not the other way around.
• Automatically trim network trees that exceed 9 levels deep.
• Very accurate timing functions for better statistics.
• Greatly improved documentation.
• Improved rejection of TCP round-trip-time outliers (from long-polled connections).
• Improved Spylnx and UISP integrations.

Better Distribution

This is in alpha testing. It has worked on some test setups, but needs production testing.

Installation via apt-get and LibreQoS's own repo. Add the libreqos repo, and you can use apt-get to install/update the traffic shaper. This doesn't get you the development toolchain.

sudo echo "deb http://stats.libreqos.io/ubuntu jammy main" > /etc/apt/sources.list.d/libreqos.list
wget -O - -q http://stats.libreqos.io/repo.asc | apt-key add -
apt-get update
apt-get install libreqos

You will be asked some questions about your configuration, and the management daemon and webserver will automatically start. Go to http://<your_ip>:9123/ to finish installation.

Gallery

Node Manager - Dashboard

The node manager displays current activity on your network

Node Manager - Circuit View

Find out exactly what's going on inside each circuit, monitoring all of the queue stats - you can even view the details of each category tin

Node Manager - Flow Analysis

Analyze what's going on for a specific client, viewing real-time traffic flow data. No need to run torch or equivalent on their router. Ideal for finding connectivity problems.

Node Manager - Packet Capture

Capture traffic and analyze per-packet in an intuitive, zoomable traffic analysis system. You can view down to nanosecond granularity to find performance problems, and see what's really going on with your traffic. Click "Download PCAP Dump" to analyze the same data in Wireshark.

Long Term Statistics (LTS)

LibreQoS' new Long Term Stats (LTS) system aggregates and graphs LibreQoS statistics for fast, efficient troubleshooting and network analysis. There is a free 30-day trial, after which the rate is $0.30 USD per shaped subscriber. You can enroll in the 30-day free trial by clicking "Start Stats Free Trial" in the top-right corner of the local LibreQoS GUI.

Long Term Statistics - Dashboard

Long Term Statistics - Report - All APs

Long Term Statistics - Report - All Sites

Long Term Statistics - Shaper Node

v1.3.1

v1.3.1 (IPv4 + IPv6)

Features

Fast TCP Latency Tracking

@thebracket has created cpumap-pping which merges the functionality of the xdp-cpumap-tc and ePPing projects, while keeping CPU use within ~1% of xdp-cpumap-tc.

Integrations

• Added Splynx integration
• UISP integration overhaul by @thebracket
• LMS integation for Polish ISPs by @interduo

Partial Queue Reload

In v1.2 and prior, the the entire queue structure had to be reloaded to make any changes. This led to a few milliseconds of packet loss for some clients each time that reload happened. The scheduled.py was set to reload all queues each morning at 4AM to avoid any potential disruptions that could theoretically cause.

Starting with v1.3 - LibreQoS tracks the state of the queues, and can do incremental changes without a full reload of all queues. Every 30 minutes - scheduler.py runs the CRM import, and runs a partial reload affecting just the queues that have changed. It still runs a full reload at 4AM.

v1.3 Improvements to help scale

HTB major:minor handle

HTB uses a hex handle for classes. It is two 16-bit hex values joined by a colon - major:minor (:). In LibreQoS, each CPU core uses a different major handle.

In v1.2 and prior, the minor handle was unique across all CPUs, meaning only 30k subscribers could be added total.

Starting with LibreQoS v1.3 - minor handles are counted independently by CPU core. With this change, the maximum possible subscriber qdiscs/classes goes from a hard limit of 30k to instead be 30k x CPU core count. So for a higher end system with a 64 core processor such as the AMD EPYC™ 7713P, that would mean ~1.9 million possible subscriber classes. Of course CPU use will be the bottleneck well before class handles are in that scenario. But at least we have that arbitrary 30k limit out of the way.

"Circuit ID" Unique Identifier

In order to improve queue reload time in v1.3, it was necessary to use a unique identifier for each circuit. We went with Circuit ID. It can be a number or string, it just needs to be unique between circuits, and the same for multiple devices in the same circuit. This allows us to avoid costly lookups when sorting through the queue structure.

If you have your own script creating ShapedDevices.csv - you could use your CRM's unique identifier for customer services / circuits to serve as this Circuit ID. The UISP and Splynx integrations already do this automatically.

Compatability Notes

The most major changes are the renaming of the fqorCake variable to "sqm",
and the addition of the Circuit identifier field.

Also after upgrading to LibreQos v1.3, a reboot is required to clear out the
old ebpf code.