OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: marunjar on February 11, 2022, 11:19:51 pm
-
I just started to tinker around a little bit with traffic shaping for guest net.
But i didn't get it to limit upload when following https://docs.opnsense.org/manual/how-tos/shaper_guestnet.html
Can anybody confirm this? Or am i missing something?
1. my rules are defined as in attached pictures
2. the result is upload not beeing limited :(
3. when looking on the status page, there are also no counters shown for upload rule --> is there a rule not matching?
4. this is output of ipfw show:
60007 48 7501 pipe 10004 ip from any to any recv igb0 xmit igb1_vlan20 // da1cda49-cfd1-44a5-9509-8381855800ba wan -> opt4: Full Bandwidth Down
60008 0 0 pipe 10005 ip from any to any xmit igb1_vlan20 recv igb0 // 21372daf-d801-4fe6-89c2-3286b60cd58c wan -> opt4: Full Bandwidth Up
As you can see, there are two rules with recv igb0 and xmit igb1_vlan20
Accoding to https://www.freebsd.org/cgi/man.cgi?ipfw(8) order isn't relevant, i think.
Also there is this paragraph in man, which may be somehow related, because there is no out in rule:
The recv interface can be tested on either incoming or outgoing
packets, while the xmit interface can only be tested on outgoing
packets. So out is required (and in is invalid) whenever xmit is
used.
-
Sorry for double post
i was able to solve parts of the problem: i changed direction of rule for upload traffic, so my rules now looks like in attached images
generated rules then looks like this:
60007 0 0 pipe 10004 ip from any to any recv igb0 xmit igb1_vlan20 // da1cda49-cfd1-44a5-9509-8381855800ba wan -> opt4: Full Bandwidth Down
60008 0 0 pipe 10005 ip from any to any recv igb1_vlan20 xmit igb0 // 21372daf-d801-4fe6-89c2-3286b60cd58c opt4 -> wan: Full Bandwidth Up
This is working so far, at least now every rule matches some traffic.
But available bandwith is a lot lower than expected.
From reading man again, the out modifier may be missing here:
We can use pipes to artificially limit bandwidth, e.g. on a machine act-
ing as a router, if we want to limit traffic from local clients on
192.168.2.0/24 we do:
ipfw add pipe 1 ip from 192.168.2.0/24 to any out
ipfw pipe 1 config bw 300Kbit/s queue 50KBytes
note that we use the out modifier so that the rule is not used twice.
Remember in fact that ipfw rules are checked both on incoming and outgo-
ing packets.
Should i open bugs in Github directly?
One for fixing doc and the other one for adding out modifier so bandwith is not halved anymore?
Edit: did a little more research and lower bandwidth seems indeed to come from missing out modifier because packet is the processed twice, the effect is even worse when using queues, because then bandwith is halved
-
I was able to find the real problem.
My rule using 2 interfaces somehow clashed with an already existing "default queue" from previous tries.
My bad, i blamed the new rule only for this problem.
It is no good idea to mix up rules matching interfaces (without src/destination) and rules matching addresses only.
It was already working with src/dst address before, but when i changed the rule to match interfaces there are suddenly multiple rules matching:
60001 13 2833 queue 10000 ip from any to any recv igb0 xmit igb1_vlan10 // 47a9f075-3071-485a-af77-10bf40b890bf wan -> opt3: HIGH Prio Down Queue
60002 13 2387 queue 10004 ip from any to any xmit igb0 recv igb1_vlan10 // 6fd0200e-67ec-4cd3-8e28-48b09b2b7295 opt3 -> wan: HIGH Prio Up Queue
60003 26 5798 queue 10003 ip from any to any in via igb0 // a08111ee-8f5a-4d94-996c-3c77f22fb6e2 wan: NO Prio Down Queue
60004 11 3506 queue 10007 ip from any to any out via igb0 // f63b5459-06e8-4e3f-950a-72e7acc652d8 wan: NO Prio Up Queue
So for download both, rule 60001 and 60003 matched and i think because of this, the packet count twice for pipe --> the bandwith is reduced.