@fegauthier Maybe it’s just an easy confusion. You say you are showing your “download policy”, but I see you are applying an outbound policy to your WAN interface. So your outgoing traffic is the one that will be shaped, and normally that traffic is considered “Upload”, not “Download”. Maybe that is the reason?
@falkowich I get it now, thank you, it’s not any strange use case at all.
Did you adjust ceiling for class 10 of EGRESS-LAB?
I think that is just what you needed. Did you test it?
Maybe you also want to apply shaping to inbound traffic?
Yes my bad. It was for UPLOAD. Still no shaping…
set traffic-policy shaper UPLOAD bandwidth '10mbit'
set traffic-policy shaper UPLOAD class 12 bandwidth '5mbit'
set traffic-policy shaper UPLOAD class 12 ceiling '5mbit'
set traffic-policy shaper UPLOAD class 12 match LAN ip source address '192.168.1.0/24'
set traffic-policy shaper UPLOAD default bandwidth '1kbit'
set traffic-policy shaper UPLOAD default ceiling '100%'
@fegauthier Can you please show how you apply the policy to the interface?
Maybe the problem is there.
Like this
set interfaces ethernet eth0 traffic-policy out 'UPLOAD'
Hi @fegauthier,
Is it ok with you if we go back to your currently active thread and I answer you from there?
Maybe it’ll be better, so that we don’t get confused.
1 Like
A quick little map how the “lab” is set up.
And the text over the clients is the goal, the red text are what is happening with the below config
I can get the “default policy” on OUTSIDE to get my upload to limit 100Mbit.
But I can’t get the CL10 to match the subnet…
interfaces {
ethernet eth0 {
address dhcp
description OUTSIDE
duplex auto
hw-id 52:54:00:ed:ee:f1
smp-affinity auto
speed auto
traffic-policy {
out EGRESS-LAB
}
}
ethernet eth1 {
address 172.25.1.1/24
description INSIDE
duplex auto
hw-id 52:54:00:cc:06:f7
smp-affinity auto
speed auto
}
loopback lo {
}
}
traffic-policy {
shaper EGRESS-LAB {
bandwidth 1gbit # Default bandwidth on the uplink
class 10 {
bandwidth 5mbit # A unique value to see of matched
burst 15kb
ceiling 2% # A unique value to see of matched
match CL10 {
ip {
source {
address 172.25.1.0/25 # Here I try to match the first subnet?
}
source {
}
}
}
queue-type fq-codel
}
default {
bandwidth 50mbit # A unique value just to see if I hit this default policy
burst 15kb
ceiling 10% # A unique value just to see if I hit this default policy
queue-type fq-codel
}
}
}
I know the bandwidth and ceiling values are wrong, but I used unique values just to see what I matched.
Any ideas what I am doing wrong 
–
Regards Falk
Yes, it seems you are not matching the criteria of the class and you are getting into default.
Why does your configuration show a second empty source for matching class 10?
I’m not sure if that has anything to do…
In the diagram, I also see the addresses of your two clients are in the same subnet. I guess that’s just in the diagram, but telling you just in case something is mixed in your tests too.
Yes, it seems you are not matching the criteria of the class and you are getting into
default.
Why does your configuration show a second empty source for matching class 10?
I’m not sure if that has anything to do…
Humm, that was a cut’n paste error. A good old Pebkac 
In the diagram, I also see the addresses of your two clients are in the same subnet. I guess that’s just in the diagram, but telling you just in case something is mixed in your tests too.
A documentation error, There are only two times I feel stress
It should be:
172.25.1.0/25
172.25.1.128/25
Can’t I match on ‘ip source address’ on an out rule on outbound interface?
Or is there a better way to get that match?
–
Regards Falk
Sure, you can. That’s probably the most common case.
What problem are you facing?
I can’t get the host with ip 172.25.1.10 to match the below config.
traffic-policy {
shaper EGRESS-LAB {
bandwidth 1gbit # Default bandwidth on the uplink
class 10 {
bandwidth 5mbit
burst 15kb
ceiling 2% # 172.25.1.10 should have 2% of 1gbit with the match below?
match CL10 {
ip {
source {
address 172.25.1.0/25 # Should not 172.25.1.10 match this rule?
}
}
}
queue-type fq-codel
}
default { # this is the rule I seem to match when trying from 172.25.1.10, instead of the CL10 match?
bandwidth 50mbit
burst 15kb
ceiling 10%
queue-type fq-codel
}
}
}
I’m really sorry that I’m sorta slow
–
MvH Falk
Hi, I apply it as the example below.
interfaces {
ethernet eth0 {
address dhcp
description OUTSIDE
duplex auto
hw-id 52:54:00:ed:ee:f1
smp-affinity auto
speed auto
traffic-policy {
out EGRESS-LAB
}
}
ethernet eth1 {
address 172.25.1.1/24
description INSIDE
duplex auto
hw-id 52:54:00:cc:06:f7
smp-affinity auto
speed auto
}
loopback lo {
}
}
Are you doing Source NAT?
Yes,
nat {
source {
rule 100 {
outbound-interface eth0
source {
address 172.25.1.0/24
}
translation {
address masquerade
}
}
}
}
–
Regards Falk
If there is SNAT, when traffic-policy is executed it will not see the original addresses any more. The solution is to mark packets so that traffic-policy recognizes them.
Have a look here.
Thanks,
Now I can match the traffic on both in and out.
But it seems that the ceiling throttle isn’t per user / per ip.
Perhaps that’s not doable?
–
Regards Falk
[EDITED beq pebkac]
@falkowich As far as I know, that cannot be completely correct. Your outbound traffic-policy can perfectly work when applied to a SNAT outbound interface using fwmark, but an inbound traffic-policy won’t be able to match addresses when using SNAT. Well, it is possible to make it happen, but I don’t think it is possible through VyOS CLI, at least for the time being (we have an open Phabricator task for it).
Currently, with VyOS CLI, if you are applying an ingress shaping policy to a SNATed interface, you won’t be able to match addresses of your inbound traffic, everything will be falling into default. If you just want to shape without classifying (all traffic going to default), everything will be good.
You can subscribe to the Phabricator task to get updated when there are any news.
In the meantime, you may want to consider applying a Shaper outbound policy to your INSIDE interface as a workaround, or configuring everything through the non-VyOS commands as in the provided link.
Regarding your question on ceiling: it is applied per class (being default a class too).
My last question, and a huge thanks for taking your time to help me out here
Using a “per” ip / “per host” bandwidth limiting isn’t doable with this type of config?
–
Regards Falk
You are welcome. No problem, you can ask as many questions as you want! Answers are not guaranteed, but there is always a chance that someone could answer.
A common use of per-IP-shaping is the one done by PPPoE Server, but it could also be done without PPPoE, just by manually configuring a /32 address match per class in a normal traffic-policy.
But I’m not sure if I understood what you meant by “this type of config”? Did I answer your question? Otherwise, please elaborate.