Qos on single ip

guys what is the easiest way to do a codel queue on per ip basis???

So in Mikrotik one has simple queues how would one do the same in Vyos?

Q1 192.168.1.20 codelq 4m/4m
Q2 192.168.1.21 codelq 2m2m

Edit…
Got it to work with 2 ips on one queue. Now the question is do i have to create a class for each queue??? how many classes can one have.

set traffic-policy shaper EGRESS_QOS bandwidth ‘1800kbit’

set traffic-policy shaper EGRESS_QOS class 100 bandwidth ‘35%’
set traffic-policy shaper EGRESS_QOS class 100 burst ‘2kb’
set traffic-policy shaper EGRESS_QOS class 100 ceiling ‘100%’
set traffic-policy shaper EGRESS_QOS class 100 match CLIENT1 ip source address ‘192.168.4.70/24’
set traffic-policy shaper EGRESS_QOS class 100 queue-type ‘fq-codel’
set traffic-policy shaper EGRESS_QOS default bandwidth ‘65%’
set traffic-policy shaper EGRESS_QOS default burst ‘2kb’
set traffic-policy shaper EGRESS_QOS default ceiling ‘100%’
set traffic-policy shaper EGRESS_QOS default queue-type ‘fq-codel’

set interfaces ethernet eth0 traffic-policy out ‘EGRESS_QOS’

Hi skoenman,

You can have many classes in one queueing discipline (in VyOS we say a traffic policy instead of a qdisc).
Does that help you? I’m not sure I understand what you are trying to achieve nor what your question is.
I don’t see any mistake in your configuration, but again, I’m not sure I understand what your goal is.

So in mikrotik we have simple queues which is a queue that is just for one ip or a range of ips.

So if i have 50 clients and the all need to have a queue of 2m/2m then that is what im trying to do.

Will i then have a traffic-policy client1 class 100
Then traffic-policy client2 class 100 ?

Hope you understand now ?

You can only have one queue per interface and direction (one outbound queue and one inbound queue per interface). However, some queues allow you to have classes which can also have their own queue. Have a look at our QoS documentation, it is all explained there, and let us know if there is any doubt.

But it looks like you are trying to do shaping per client through [PPPoE Server](PPPoE Server — VyOS 1.4.x (sagitta) documentation. If that’s your case, check this.

ok so how would i give my clients each there own codel queue then???
How does other wisps do it??
I like the Codel queue because it works better than fair queue.

How taxing are the pppoe-server on hardware??? something like Edgemax…

.EDIT…
set traffic-policy shaper MY-HTB bandwidth ‘50mbit’
set traffic-policy shaper MY-HTB class 10 bandwidth ‘10%’
set traffic-policy shaper MY-HTB class 10 match ip source address ‘192.168.1.100/24’
set traffic-policy shaper MY-HTB class 10 queue-type ‘fq-codel’

set traffic-policy shaper MY-HTB class 11 bandwidth ‘10%’
set traffic-policy shaper MY-HTB class 11 match ip source address ‘192.168.1.101/24’
set traffic-policy shaper MY-HTB class 11 queue-type ‘fq-codel’

set traffic-policy shaper MY-HTB class 12 bandwidth ‘10%’
set traffic-policy shaper MY-HTB class 12 match ip source address ‘192.168.1.102/24’
set traffic-policy shaper MY-HTB class 12 queue-type ‘fq-codel’

set traffic-policy shaper MY-HTB class 13 bandwidth ‘10%’
set traffic-policy shaper MY-HTB class 13 match ip source address ‘192.168.1.103/24’
set traffic-policy shaper MY-HTB class 13 queue-type ‘fq-codel’

That way its one Queue but diffrent classes.

Yes, that way you have one policy with an fq_codel embedded queue per class, and each class has a filter to match one IP address. That is all correct. Just remember to add the default class.

Last question… how many queues can one run off vyos? Is there a way to work out how much power one needs?

You can have one outbound queue and one inbound queue per interface. Those are parent queues.

Some policies allow you to embed one queue into a class, and some policies allow you to have thousands of classes. So, in some policies, you could have thousands of different children queues, one per class. Those are children queues.

VyOS CLI, in order to make things easier, does not allow to have deeper levels in the hierarchy of classful qdiscs as the native tc tool does.

CPU and memory consumption depends on many factors, you should run the test under your own hardware, configuration and traffic conditions to check the effects. My tests have always showed me that it is nearly always worth it to use QoS, as I found a very low impact on CPU and memory, but I have never tested having hundreds of queues.

ok thanks im going to do the test and give some feedback …should be interesting…

1 Like

To be honest - i don’t understand what you’re trying to achieve either and i have the feeling that you might got some basic concepts wrong. Please try to rephrase your goal in high-level terms - e.g.:
“Total available bandwidth is 50MBit and each of the 20 clients should be guaranteed a minimum bandwidth of 2mbit”.

@foxit-eu if you look at the example … you will see that we are a service provider.
So we need a Queue for each client whether its a 2mbps or 10mbps queue …so total is 500Mbps but each client cant go and use 50mbps if he is only paying for 2mbps.
So when you have 500 clients you need 500 queues and with vyos only allowing one queue per interface…see the problem??
Yes and PPPoe-server is a option but my system at the moment has a server so it wont work in my setup.

Ok, already suspected that you try to LIMIT traffic on an uncongested link - that’s exactly the opposite of what most of the advanced queue disciplines try to solve (=granting as much bandwidth as possible on a congested link without affecting competing flows/applications). The qdisc (aka “traffic policy” in vyos-lingo) to go for is probably the limiter policy with a class for each client/ip (4090 classes allowed according to manual). Read the limiter policy + ingress shaping sections in the manual.

Can one have a Fc_codel Shaper??
Do i still have to assign it to a interface???

FQ_CoDel does not shape.
But you can embed an FQ_CoDel queue into a Shaper policy.
It is explained here, showing exactly that example.

In that example, the user chose the name “FQ-SHAPER” for their Shaper policy because they are embedding an FQ_CoDel queue into a Shaper (HTB) policy. So that’s just an arbitrary name chosen by the user.