From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8463D3B29D for ; Sat, 5 Nov 2022 09:33:06 -0400 (EDT) Received: by mail-pg1-x534.google.com with SMTP id v3so6647932pgh.4 for ; Sat, 05 Nov 2022 06:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IEk+Dq8/JHU8CHn9871co2hkwT1K3kmmSwT/6fBIqcE=; b=K2J3dFpWZJzGKh2m+FkOa6J1CW4ehuLmxuufOmDwb9qLOhEWFoCHJ2GUTbf981qa5D HYI6DWuRPw1LiMNKc9KdCKLc/8uCw6koEv9kAgGmgTE1ObiufDNiF4IOhXww6vtNTpLd JtGD6Mufe3unGL2eNEGQbnOiWpQQfDZBaI8S7IrzenA+SrwnS3vNop4PGUPgCMn6fQ4a nKI2jOWunln+dPKaB06Hj0PAbn7N0+cdKeqWpegD21K9TkzkKHGU5YlXdhJ77Zcj2rjl Om0x8gm4NHO1gMRhFUnKrZhEfJa+yYdK6aVlrYIqot/uRA7uqcaUe/SZp/eAuySudCyd C0bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IEk+Dq8/JHU8CHn9871co2hkwT1K3kmmSwT/6fBIqcE=; b=n/EGCf6fNr0UpR6lR3FrjGadSvebwDuLjw7vqMfKpZpdEM/VeHKNzZ2n9ci7rbVDK9 v146IrCGrLKiNcVB+o5KSmCL9ZVmHTLtmWiF2XROm6NFi2eQZKYq1+/ZvfZJycfpRKEd pfmCF0Hhw/b0tsa2jdkVzIvZNcLbcRK+BvaKjfY6/STOSqWoBxEnY8W6x92qcooM+elH pf6gm4X1pC+wsPvJ/2ZZux5KACidQhHaep+T1c+CCK92LbVswR141xftszxCZw6lJyXV QF7vciaMQle0w+5JOX73o2Yac/4oHo+DfgECfxaMeOidTCVPF16CkvSSfMq+XwDv7CIH VuIA== X-Gm-Message-State: ACrzQf1ziBiyvZ0a4+CzE+1gc+gHcUUViq9kJwyDk44CE36z3bJkeADh 3FUFGlCBHu6+eYRzXI9pc/GgvZtXJmz9rHSV1UMDPBJs X-Google-Smtp-Source: AMsMyM6QhtfY/e5x+ZJrdW7Hfl+abkIyDyq8AWXPTFY4UfumPReGjP5hSmOSIGsHVUspkkL6lUxSWnZiMChPc35ijqs= X-Received: by 2002:a65:6e0e:0:b0:434:59e0:27d3 with SMTP id bd14-20020a656e0e000000b0043459e027d3mr33637517pgb.185.1667655185220; Sat, 05 Nov 2022 06:33:05 -0700 (PDT) MIME-Version: 1.0 From: Herbert Wolverson Date: Sat, 5 Nov 2022 08:32:55 -0500 Message-ID: To: libreqos Content-Type: multipart/alternative; boundary="000000000000ec47be05ecb93ae1" Subject: [LibreQoS] Tracking unknown IPs (maybe for 1.4?) X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2022 13:33:06 -0000 --000000000000ec47be05ecb93ae1 Content-Type: text/plain; charset="UTF-8" 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. --000000000000ec47be05ecb93ae1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 f= ound useful in both BracketQoS and Preseem was the ability to grab a list o= f IP addresses that had been through the shaper, but weren't mapped to = a queue (obviously, only from within the "allowed IP" range - we&= #39;re not trying to map the Internet!).

In Presee= m, 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).

<= div>*Why is this useful?*

Knowing which local IP a= ddresses were processed but not mapped lets you find:

<= div>* the times that a device was installed, but the on-boarding process wa= sn't completed. Yes, that shouldn't happen. And - unfortunately - i= t occasionally does. If you're using RADIUS-based authentication, it= 9;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 &q= uot;oops, I put X on the default"
* Just occasionally, you g= et a customer who needs a special setup; it's helpful to see that it wo= rked.

*Current Status*

Before cpumap-pping, Bracket was grabbing them by reading the pping o= utput and listing addresses that didn't match a shaping rule. That does= n't work now:

* xdp_pping is spitting out TC h= andles, rather than IP addresses.
* With a default rule in place,= and handling for IPv6 and IPv4 subnets, an IP address might not exactly ma= tch an entry (requires an LPM trie lookup) - and IPs matching a default rul= e (::/0 or 0.0.0.0/0) will always come bac= k with the "default" handle.

It's cu= rrently pretty tricky to do.

So I'm curious; w= ould others like to see this? I have a few ideas for how to make it work, b= ut don't want to start serious planning/design if I'm the only one = who wants the feature.
--000000000000ec47be05ecb93ae1--