From: Herbert Wolverson <herberticus@gmail.com>
To: libreqos <libreqos@lists.bufferbloat.net>
Subject: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)
Date: Sat, 5 Nov 2022 08:32:55 -0500 [thread overview]
Message-ID: <CA+erpM4pkNwKFO92tkj-EpfQzh4hQ6=q4mQBPparVi7fyUs4zA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2286 bytes --]
next reply other threads:[~2022-11-05 13:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-05 13:32 Herbert Wolverson [this message]
2022-11-05 16:29 ` Robert Chacón
2022-11-09 16:06 ` dan
2022-11-09 16:20 ` Herbert Wolverson
2022-11-09 16:23 ` Dave Taht
2022-11-09 16:27 ` Herbert Wolverson
2022-11-09 16:39 ` Dave Taht
2022-11-09 17:50 ` [LibreQoS] on building better router software on older routers (cambium/ubnt lawsuit) Dave Taht
2022-11-09 18:46 ` dan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/libreqos.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+erpM4pkNwKFO92tkj-EpfQzh4hQ6=q4mQBPparVi7fyUs4zA@mail.gmail.com' \
--to=herberticus@gmail.com \
--cc=libreqos@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox