[LibreQoS] Integration system, aka fun with graph theory

[dan]

we're pretty similar in that we've made UISP a mess.  Multiple paths to a
pop.  multiple pops on the network.  failover between pops.  Lots of
'other' devices. handing out /29 etc to customers.

Some sort of discovery would be nice.  Ideally though, pulling something
from SNMP or router APIs etc to build the paths, but having a 'network
elements' list with each of the links described.  ie, backhaul 12 has MACs
..01 and ...02 at 300x100 and then build the topology around that from
discovery.

I've also thought about doing routine trace routes or watching TTLs or
something like that to get some indication that topology has changed and
then do another discovery and potential tree rebuild.

On Thu, Oct 27, 2022 at 3:48 PM Robert Chacón via LibreQoS <
libreqos at lists.bufferbloat.net> wrote:

> This is awesome! Way to go here. Thank you for contributing this.
> Being able to map out these complex integrations will help ISPs a ton, and
> I really like that it is sharing common features between the Splynx and
> UISP integrations.
>
> Thanks,
> Robert
>
> On Thu, Oct 27, 2022 at 3:33 PM Herbert Wolverson via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
>
>> So I've been doing some work on getting UISP integration (and
>> integrations in general) to work a bit more smoothly.
>>
>> I started by implementing a graph structure that mirrors both the
>> networks and sites system. It's not done yet, but the basics are coming
>> together nicely. You can see my progress so far at:
>> https://github.com/thebracket/LibreQoS/tree/integration-common-graph
>>
>> Our UISP instance is a *great* testcase for torturing the system. I even
>> found a case of UISP somehow auto-generating a circular portion of the
>> tree. We have:
>>
>>    - Non Ubiquiti devices as "other devices"
>>    - Sections that need shaping by subnet (e.g. "all of 192.168.1.0/24
>>    shared 100 mbit")
>>    - Bridge mode devices using Option 82 to always allocate the same IP,
>>    with a "service IP" entry
>>    - Various bits of infrastructure mapped
>>    - Sites that go to client sites, which go to other client sites
>>
>> In other words, over the years we've unleashed a bit of a monster.
>> Cleaning it up is a useful talk, but I wanted the integration to be able to
>> handle pathological cases like us!
>>
>> So I fed our network into the current graph generator, and used graphviz
>> to spit out a directed graph:
>> [image: image.png]
>> That doesn't include client sites! Legend:
>>
>>
>>    - Green = the root site.
>>    - Red = a site
>>    - Blue = an access point
>>    - Magenta = a client site that has children
>>
>> So the part in "common" is designed heavily to reduce repetition. When
>> it's done, you should be able to feed in sites, APs, clients, devices, etc.
>> in a pretty flexible manner. Given how much code is shared between the UISP
>> and Splynx integration code, I'm pretty sure both will be cut to a tiny
>> fraction of the total code. :-)
>>
>> I can't post the full tree, it's full of client names.
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
>
>
> --
> Robert Chacón
> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
> _______________________________________________
> 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/20221027/57c78815/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 573568 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221027/57c78815/attachment-0001.png>