[LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[dan]

How are you linking UISP to RADIUS?

On Sat, Nov 5, 2022 at 10:29 AM Robert Chacón via LibreQoS <
libreqos at lists.bufferbloat.net> wrote:

> In our particular case we use RADIUS tied to UISP so we don't have the
> immediate need, but I think it's an important feature to add.
>
> Perhaps cpumap-pping can have a feature to define "shaped subnets" during
> the filter setup, and then we could query cpumap-pping for a JSON output of
> IPs detected in traffic that are in the "shaped subnets" groups, but not
> defined in the hash map.
>
> Curious to hear what others think here. Would others need this in order to
> adopt LibreQoS?
>
>
> On Sat, Nov 5, 2022 at 7:33 AM Herbert Wolverson via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
>
>> As we approach the v1.3 pre-release feature freeze, I've been thinking a
>> little bit about nice things to have. One thing I found useful in both
>> BracketQoS and Preseem was the ability to grab a list of IP addresses that
>> had been through the shaper, but weren't mapped to a queue (obviously, only
>> from within the "allowed IP" range - we're not trying to map the Internet!).
>>
>> In Preseem, there's a link to download a CSV file containing all the
>> unmapped IP addresses and how much traffic they have consumed. BracketQoS
>> (pre cpumap-pping) has a report showing the IPs (no traffic).
>>
>> *Why is this useful?*
>>
>> Knowing which local IP addresses were processed but not mapped lets you
>> find:
>>
>> * the times that a device was installed, but the on-boarding process
>> wasn't completed. Yes, that shouldn't happen. And - unfortunately - it
>> occasionally does. If you're using RADIUS-based authentication, it's really
>> difficult for this to happen - but not everyone is.
>> * If there's a bug in your shaper integration, it's helpful to see "oops,
>> I put X on the default"
>> * Just occasionally, you get a customer who needs a special setup; it's
>> helpful to see that it worked.
>>
>> *Current Status*
>>
>> Before cpumap-pping, Bracket was grabbing them by reading the pping
>> output and listing addresses that didn't match a shaping rule. That doesn't
>> work now:
>>
>> * xdp_pping is spitting out TC handles, rather than IP addresses.
>> * With a default rule in place, and handling for IPv6 and IPv4 subnets,
>> an IP address might not exactly match an entry (requires an LPM trie
>> lookup) - and IPs matching a default rule (::/0 or 0.0.0.0/0) will
>> always come back with the "default" handle.
>>
>> It's currently pretty tricky to do.
>>
>> So I'm curious; would others like to see this? I have a few ideas for how
>> to make it work, but don't want to start serious planning/design if I'm the
>> only one who wants the feature.
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
>
>
> --
> Robert Chacón
> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
> Dev | LibreQoS.io
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221109/e12a6382/attachment-0001.html>