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

Wed Nov 9 11:39:56 EST 2022

On Wed, Nov 9, 2022 at 8:27 AM Herbert Wolverson via LibreQoS
<libreqos at lists.bufferbloat.net> wrote:
>
> I've no idea. We only have a few M2/M5 CPEs left, and all of the access points are running AirMax AC. Since that's neither an open nor standard protocol, I don't think OpenWRT would work for us.

You just update both sides.

>
> I have no doubt that it outperforms the Mx code, though. Elevate (Cambium's "turn CPEs into Cambium SMs" program that turned into lawsuit city) makes them perform really, really well.

I know. They were running "my stuff", inside, on all interfaces.

>
> On Wed, Nov 9, 2022 at 10:23 AM Dave Taht <dave.taht at gmail.com> wrote:
>>
>> does dhcp option 82 work on openwrt?
>>
>> I long ago reflashed all my m2 and m5s to openwrt. outperforms ubnts
>> default build across the board if you tune down the txop size to
>> 2.5ms.
>>
>> On Wed, Nov 9, 2022 at 8:20 AM Herbert Wolverson via LibreQoS
>> <libreqos at lists.bufferbloat.net> wrote:
>> >
>> > We have a bespoke solution to do similar (I keep meaning to make it more generic and open source it). The basic operation is (using our Mimosa devices as an example; it's actually a lot more complicated than that since we have everything from apartment complexes with Ethernet jacks to regular Ubiquiti devices in bridge mode):
>> >
>> > A server contains an instance of FreeRADIUS.
>> > Periodically, a script runs and queries UISP. It finds client sites with a device matching the type "Mimosa C5x" and an "other device" entitled "Service IP".
>> >
>> > A radius record is then added for the CPE (using the MAC and IP from the Mimosa device), placing the Mimosa CPE on the IP address in the "mimosa" record.
>> > A second radius record is added that matches Option 82 headers to see that a request passed through the Mimosa. This will always hand out the IP address from the "Service IP" record.
>> > The radius database is refreshed with this information.
>> >
>> > When a CPE comes online, the DHCP server sends a RADIUS request. If the MAC address matches a RADIUS record, the device is assigned to the CPE address from the RADIUS records.
>> > When a customer's device sends a DHCP request, it passes through the CPE. The CPE's "option 82" support decorates the DHCP request with the CPE's MAC address in a header. This then matches the second rule in Radius, ensuring that no matter what device the customer plugged in - it gets the Service IP.
>> >
>> > This then dovetails into the QoS - because we can be 100% sure that the customer's router has the IP address of the Service IP record in their client site.
>> >
>> > It took about an afternoon to setup, and is really nice. We have additional rules like "place unknown CPEs into a block that is redirected to a page reminding the installer to call in the account for setup", special handling of suspended accounts and similar.
>> >
>> > People have been begging Ubiquiti to a) support option 82 properly on the M5/M2 line (I have a 10 year old request still unanswered!), and b) provide some sort of RADIUS setup baked into UISP. The latter won't happen, because it reduces vendor lock-in. But it's really easy to setup, and use UISP as a "source of truth". (Obviously, when your clients are bridged you need to take precautions - client isolation, switch port isolation and DHCP snooping)
>> >
>> >
>> > On Wed, Nov 9, 2022 at 10:07 AM dan <dandenson at gmail.com> wrote:
>> >>
>> >> 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
>> >>> Dev | LibreQoS.io
>> >>>
>> >>> _______________________________________________
>> >>> LibreQoS mailing list
>> >>> LibreQoS at lists.bufferbloat.net
>> >>> https://lists.bufferbloat.net/listinfo/libreqos
>> >
>> > _______________________________________________
>> > LibreQoS mailing list
>> > LibreQoS at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/libreqos
>>
>>
>>
>> --
>> This song goes out to all the folk that thought Stadia would work:
>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>> Dave Täht CEO, TekLibre, LLC
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC