Welcome to the LibreQoS Development Blog

I’m Herbert, lead developer of LibreQoS. I joined not long after Robert and Dave got the ball rolling, added IPv6 support, and created most of the Rust parts, C parts, etc.

One thing we’ve heard from people is that Insight looks great, but they ask, “How do I use this thing?” and, more importantly, “How does this help me?” We use Insight daily; it’s become our one-stop shop for finding network issues and understanding what’s going on. However, we’re all developers and have decades of experience as internet service providers. So we set out to demystify the experience.

A huge thank you to NLnet foundation for sponsoring this development.

Acabamos de lanzar la versión 0 (Alpha) de la API de Insight. Los shapers/reguladores de LibreQoS también tienen una API, pero ese será el tema de futuras publicaciones. En esta ocasión, hablaremos exclusivamente de la API de Insight.

We just launched version 0 (Alpha) of the Insight API. LibreQoS shapers have an API, too — and that’ll be the topic of future posts. This one is all about the Insight API.

Let’s start by understanding the path taken by packets through the Linux kernel, and how LibreQoS interacts with them.

In this (long) article, I’m going to walk through the problem and the multi-year process of tackling it.

Prior to version 1.5-RC1, LibreQoS read ShapedDevices.csv and network.json (in the LibreQoS.py script) to determine network hierarchy, device configuration and design the traffic control (TC) setup. Once the files were validated, the script would create a big set of tc commands, clear the current TC state, and apply the new configuration.

Antes de la versión 1.5-RC1, LibreQoS leía ShapedDevices.csv y network.json (en el script LibreQoS.py) para determinar la jerarquía de red, configuración de dispositivos y diseñar la configuración de control de tráfico (TC). Una vez validados los archivos, el script creaba un gran conjunto de comandos tc, limpiaba el estado actual de TC y aplicaba la nueva configuración.