LibreQos test scenario #361
-
|
I recently downloaded LibreQos trying to apply the following scenario:
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
|
LibreQoS doesn't do per-port shaping (or even per-destination shaping).
It's designed for use in ISPs or other large networks - where you set an IP
(or subnet) to have a given "plan" (e.g. "bob is paying for 100/100, so
we'll set the Bob household to that speed".
Matching of rules happens in the XDP code in the `src/rust/lqos_sys`
package. The `linux_tc` file is generated when you run `LibreQoS.py`.
…On Wed, May 24, 2023 at 7:58 AM aboodmekky ***@***.***> wrote:
I recently downloaded LibreQos trying to apply the following scenario:
- Flow 1: Source İP address: 10.10.10.1/24, Destination İP address:
10.10.10.2/24 source port 5005
- Flow 2: Source İP address: 10.10.10.1/24, Destination İP address:
10.10.10.2/24 source port 5006
for flow 1 guaranteed traffic 80%, for flow 2 guaranteed traffic 20%
how can we do such a configuration, and where
/opt/libreqos/src/linux_tc.txt configuration file generated from. also how
the traffic rules matches the shaped device.
[image: Screenshot from 2023-05-24 15-56-32]
<https://user-images.githubusercontent.com/121554741/240610960-d8b01411-27aa-43ee-b755-66550ddf538a.png>
—
Reply to this email directly, view it on GitHub
<#361>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRU432ZKUNL6DMOQIBRJL3XHYAY3ANCNFSM6AAAAAAYNLBQF4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@thebracket Thank you so much for your fast answer. |
Beta Was this translation helpful? Give feedback.
-
|
Cake - the underlying shaper in the kernel - reads packet DSCP tags and
allocates them ("video" really means "interactive video", like a Zoom
meeting - rather than streaming video from Netflix/YouTube/etc.). Not
everything sets these tags - most VOIP does, Zoom has a setting to turn it
on. So the majority of traffic winds up as best effort - which is fine.
You can't specifically match by traffic type - again, that's not really the
purpose of the program (and I'd leave any ISP that specifically lowers my
video quality!) - and we take net neutrality pretty seriously.
…On Wed, May 24, 2023 at 8:30 AM aboodmekky ***@***.***> wrote:
@thebracket <https://github.com/thebracket> Thank you so much for your
fast answer.
I have one more question. according to what i see at the LibreQos UI in
shaped devices under All Tins there are 4 classes of traffic
(Bulk,Video,best effort and voice). how libreqos understand the traffic
class. if it support traffic classification or understand traffic tags that
we can provide inside the packet how can we write the rules that mach this
traffic
—
Reply to this email directly, view it on GitHub
<#361 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRU4367HFCTTIMJP2FMCQ3XHYEP7ANCNFSM6AAAAAAYNLBQF4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you again, my main purpose is integrate LibreQos with SD-WAN solution in order to shape SD-WAN user traffic, but traffic shaping will be according to custom classes that administrator creates. in this case LibreQos is not the right application to use. |
Beta Was this translation helpful? Give feedback.
-
|
you can build complicated combinations of qdiscs out of htb+fq_codel to work however you want. Cake´s intent was simplicity, you can easily program things to fit into the 3,4 or 8 diffserv tins, but are stuck with the relative bandwidth limits defined within it. A lot of folk, over the years, have built systems that will do exactly what you want here. So long as fq_codel (or cake) is the terminating qdisc, you can add tc filters to your hearts delight to allocate bandwidth however you want, and what I try to stress is that while doing that, you also MUST control queue depth (as the codel AQM does), as well as FQ competing traffic in whatever bandwidth class you have. Otherwise, especially with a fifo, you end up with REALLY BAD behaviors under stress. I outlined all that can go wrong here with not doing FQ and AQM properly, and cake is just one descendent of trying to give people the tools to make things work here more right. See also: https://www.bufferbloat.net/projects/bloat/wiki/Wondershaper_Must_Die/ |
Beta Was this translation helpful? Give feedback.
-
|
also, see qosify: https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789/221 |
Beta Was this translation helpful? Give feedback.
you can build complicated combinations of qdiscs out of htb+fq_codel to work however you want. Cake´s intent was simplicity, you can easily program things to fit into the 3,4 or 8 diffserv tins, but are stuck with the relative bandwidth limits defined within it. A lot of folk, over the years, have built systems that will do exactly what you want here. So long as fq_codel (or cake) is the terminating qdisc, you can add tc filters to your hearts delight to allocate bandwidth however you want, and what I try to stress is that while doing that, you also MUST control queue depth (as the codel AQM does), as well as FQ competing traffic in whatever bandwidth class you have. Otherwise, especially…