Dynamic Circuits - Part 1

When we finished removing the reload penalty, we unblocked a lot of development options - many of them features people have been wanting for a long time. The most recent is dynamic circuits.

Previously, when LibreQoS spotted traffic from an IP address that didn’t appear in ShapedDevices.csv, it listed it as an “Unknown IP” - and didn’t really let you do a lot with it. It was up to you to figure out what it was, what it’s doing. It was subject to traffic shaping, but was put into a big “unknown” bucket - shaped collectively. We’ve offered a few workaround over the years, which can help - but they aren’t really what people want. For example, declaring “Fallback subnets” with a shared “unknown pool” of bandwidth can help a lot. It’s also led to some wasteful design - if you know public WiFi can occupy 254 IP addresses but each needs individual shaping, you might have been tempted to create 254 circuits - whether or not you needed them.

So I set out to fix that.

Mapping Dynamic Ranges

The first decision what to allow users to map dynamic ranges in their configuration. That includes a catch-all “0.0.0.0” for everything - but you can easily map your event wifi to a CIDR range (or multiple ranges) - and specify the plan you want default customers to receive.

Once the user interface and configuration was specified and working, the next step was to use it.

Circuit Overlay Layer

Under the hood, LibreQoS combines topology calculations and keeps an internal list of ShapedDevices.csv. Over the years, access to this had become pretty scattered - it was already a maintenance hotspot, so it made sense to give it a good old refactor. So the first thing we did was to refactor all of the circuit handling code into a single actor - and provide a clean API for access.

That opened up the option to create a “dynamic” layer, and ensure that queries could return dynamic circuits. And - as if by magic (but actually planning!) - the user interface just worked for circuit display. Top X lists, search and other pages link to dynamic circuits.

The Bakery

The next step was to actually make dynamic circuits. Fortunately, we already had most of this; the bakery already tracks IP address existence and time-to-live for dynamic circuit creation. So the “I see IP” logic was extended slightly to perform a longest-prefix-match check on unknown IP addresses. If they matched a defined handler for unknown IP address ranges - the bakery makes the circuit, it is added to the dynamic circuit tracker.

So what can we do with this?

This is the first of several improvements, but it immediately unlocks plenty of scenarios:

• If you offer public wifi (permanently or for an event), you can define a range for the public wifi event and automatically have every device benefit from CAKE. Define a parent node and you can limit the total bandwidth for your event.
• If you have unknown IPs — and let’s face it, it is really easy to forget to put things into your CRM — you can give them a default plan and use the monitoring tools to help figure out who they are.
• For a small office setup, you could easily define a small network with a big dynamic range - and immediately shape every device that shows up. As you grow, you define known devices - and office visitors still get shaped cleanly.

And there’s much more. Future updates will add this to the API, and we’re exploring ways to integrate with dynamic DHCP and RADIUS.