search

LibreQoE / LibreQoS

A Quality of Experience and Smart Queue Management system for ISPs. Leverage CAKE to improve network responsiveness, enforce bandwidth plans, and reduce bufferbloat.
https://libreqos.io/
GNU General Public License v2.0
460 stars 49 forks source link

Would LibreQoS help a small-medium business? #561

Open richb-hanover opened 1 month ago

richb-hanover commented 1 month ago

I know the primary focus of LibreQoS is for ISPs to control their latency, that is, "outbound" to their many, many customers.

Does anyone have experience with (or predictions about) whether LibreQoS would help control latency for a small to medium business with say, 20 to 1,000 employees all "funneled" onto a single ISP link? Many thanks.

syadnom commented 1 month ago

Absolutely. simple to implement as well, probably a flat network, add every IP in the LAN subnet(s) with a top level shaper at ~90% WAN and each IP to <=80% or so, win. More complex designs for campus style networks with bottlenecks.

IMO, excellent use case.

moeller0 commented 1 month ago

There is one challenge with BYOD phones and tablets, these default to randomising their WiFi mac and at least android ones insist on using SLAAC for IPv6. Nothing insurmountable, just one additional cat to herd...

syadnom commented 1 month ago

If you just pre-enter every possibly ipv4 address in the subnet, and then pull MACs from arp and match ND ipv6 entries getting ipv6 addresses is easy.

thebracket commented 1 month ago

I've rolled out LibreQoS boxes a few times for consulting customers in distress (I don't do as much of the "break fix" consulting as I used to - very little nowadays, I can earn 100x more with Rust consulting/teaching). I do have the unfair advantage that I've rolled out so many test LibreQoS setups that it's kinda effortless to build them now!

For <1gbps, I don't really care about the multi-core capabilities (and LibreQoS is serious overkill) - so set the top-level limits appropriately (90% of actual limit is my preference to start) and a 1-line ShapedDevices with the customer's subnet(s) defined. Boom - done, everyone's Caked with the whole pipe fairly shared. Now I can start looking at flows, taking packet captures for analysis and start figuring out an actual plan. (Although it's surprising how often this has been "it's working now, off you go before we burn more hours").

If that isn't doing the job, I'll start setting up some individual hosts in ShapedDevices (for things that have special needs), maybe start labeling some topology in network.json (you can cheat and set the limit to your top-level limit and have it not limit much at all, but it's really handy to gather everyone in one network leg into a section and start analyzing network legs... there's some magic in 2.1 coming for that!).

The smaller businesses, I often wind up fixing some network brokenness and leave a Mikrotik running CAKE or fq_codel and they are improved enough. That's my preference for the customers who don't really have an IT person - keep it simple before someone inevitably "clean it up".

So it can help, but it's not a "drop in" tool quite yet. You do need someone who knows what they're doing to an extent.

Every time, I'm so glad that we support CIDR ranges for devices. So you can have "Everyone, 192.168.0.0/16" and not worry... (IPv6 penetration in Missouri is really, really low).

Edit: Robert was talking about doing this for a customer, too.

thebracket commented 1 month ago

Now, the tricky question is "what could LibreQoS do to support this usage?". Which has to be accompanied by "with the limited resources available". So baking everything down to a plug'n'pray router isn't going to happen, but maybe there are some opportunities for setup steps that fit within our resources?

trendal commented 1 month ago

https://libreqos.io/2023/11/13/success-story-raceway/ There is our experience with a similar situation

syadnom commented 1 month ago

Now, the tricky question is "what could LibreQoS do to support this usage?". Which has to be accompanied by "with the limited resources available". So baking everything down to a plug'n'pray router isn't going to happen, but maybe there are some opportunities for setup steps that fit within our resources?

probably not, however, there might be a side hussle here for implementors that need some 'pro' support from time to time but will do the implementation themselves. Have had some really great conversations with Robert and Frantisek and Trendal. And stirred up lots of ideas for me that I'll throw out you guys in a back channel.

interduo commented 1 month ago

  1. Few of my customers got a problem with users that are sitting on social media instead of working. So alerting about this would be helpful.

  2. Data retention - most companies even IT one got no retention. Log grepper.

  3. Optional VoIP priority, gaming inside userqueue. Does Libre support it?

  4. Blacklisting some IPs (lan/wan side)

  5. DDos/Botnet detector

syadnom commented 1 month ago

^

1 is a DPI thing. I did discuss using some sort of DPI for just charting, not shaping. maybe nTOP to do some light DPI.

My use case here was that an operator might see a chart that said something like "this is a popular service by data volume but latency to this services is above the norm" sort of stuff. Might help make the decision to upgrade the primary connectivity vs order transit to an IX to peer for example.

3 'yes' in that fq_codel and cake already make this fantastic without a special carve out. However, I don't think it'd be remotely difficult to do some dedicated capacity on the WAN via voip vlan subnet also. ie, 1G link, have all the '192.168.1.0/24' users in a 900M htb and then '192.168.2.0/24 aka voip' in a 40M htb.

a 'pro' integrator could pull this off reasonably well.

2 data retention is LTS/LTS2 IMO.

moeller0 commented 1 month ago

My use case here was that an operator might see a chart that said something like "this is a popular service by data volume but latency to this services is above the norm" sort of stuff. Might help make the decision to upgrade the primary connectivity vs order transit to an IX to peer for example.

This is IMHO a much better justification for doing that than to snitch on users... (that is, this is something an ISP could do pro-actively in an attempt to improve the quality of experience for everyone, while the )social media thing is something that might work only after being contracted to do so, at least that is my gut feeling.

3 'yes' in that fq_codel and cake already make this fantastic without a special carve out. However, I don't think it'd be remotely difficult to do some dedicated capacity on the WAN via voip vlan subnet also. ie, 1G link, have all the '192.168.1.0/24' users in a 900M htb and then '192.168.2.0/24 aka voip' in a 40M htb.

Even easier, just keep re-mark all DSCPs that cake would steer into the highest priority class except VoIP (assuming VoIP can be easily identified) and in the diffserv3 diffserv4 or diffserv8 modes cake will give this a bounded priority.

syadnom commented 1 month ago

voip isn't as easy to detect these days if it's not a desk phone speaking direct sip. lots of stuff is tunneled. I tunnel all voip through tunnels and on non-standard ports for example.

much easier if you have a separate subnet for phones.

however, sip inside a tunnel doesn't behave much different than bare sip as far as a shaper is concerned. it's still small steady flows.