search

firehol / firehol

A firewall for humans...
GNU General Public License v2.0
1.49k stars 188 forks source link

fireqos does not work as described in the documentation #298

Open mniehren opened 6 years ago

mniehren commented 6 years ago

Hi,

i am new to firehol and first want to use fireqos without firehol.

So, i tried out this "small" config

DEVICE=eth1 INPUT_SPEED=16Mbit OUTPUT_SPEED=2200Kbit LINKTYPE="adsl local pppoe-llc"

interface $DEVICE eth1-in input rate $INPUT_SPEED $LINKTYPE class vpns commit 40% match port 1194 # OpenVPN class surfing commit 1% match tcp sports 0:1023

interface $DEVICE eth1-out output rate $OUTPUT_SPEED $LINKTYPE class vpns commit 40% match port 1194 # OpenVPN class surfing commit 1% match tcp dports 0:1023

In the documentation on chapter 4.ii, the following is described: ​ii. The class with highest priority will get all the spare bandwidth there is, of course only when it needs it.

After that i start 2 downloads, one over openvpn, one normal. As the openvpn connection has the hightest priority (0), i expected that the openvpn download should get most of the input bandwidth, but it doesn't. Both connections got 8Mbit.

Where is my fault ?

best regards Michael

dlakelan commented 6 years ago

Are you sure your hardware can support more than 8 mbit over OpenVPN? Wiro

dlakelan commented 6 years ago

Sorry, dropped my phone and cut off post...

Without aes-ni or other hardware accelleration 8-10 mbit over VPN is quite typical performance

mniehren commented 6 years ago

no, that's not the problem. If i download only over OpenVPN i nearly got 11 Mbit. If i paralle start a second download over normal http the 2 connections shares the hole bandwith, so i only got 8 Mbit on both. That's not what the config says ...

fireqos status eth1-in show the difference: TOTAL vpns surfin defaul 15055 15044 5 6 15069 15051 17 1 15064 15058 4 2 15097 15089 1 6 15085 10402 4680 3 15193 7119 8059 15 15055 7134 7919 1 15112 8628 6478 5 15158 10761 4393 4 15061 9826 5233 2 15106 9494 5611 1 15075 7603 7472 1 15086 7180 7905 - 15142 7345 7794 3 15066 7407 7654 6 14791 7836 6954 1 15219 8727 6492 - 15099 8424 6674 1 15138 8263 6870 4 15085 7961 7122 2

color code (packets): backlog | dropped | delayed | requeued Class Utilization on eth1-in (eth1 input => eth1-ifb) - values in Kbit/s TOTAL vpns surfin defaul 15123 9370 5751 3 15151 9004 6142 4 15030 8579 6450 - 15068 8576 6488 5 15109 7263 7842 4 15096 7188 7905 2 15061 7392 7668 1 15102 7055 8045 1 15170 6747 8422 1 15159 6857 8297 5 15129 6886 8241 1 15081 5984 9095 2

dlakelan commented 6 years ago

I wonder if this has to do with ack packets. Inbound qos only works by delaying or dropping packets so that you send acks differently and then the upstream source changes it's behavior. Perhaps encryption of acks is slower than sending acks unencrypted, and so the feedback is not symmetric. But I agree, it's not the expected behavior.

mniehren commented 6 years ago

do you have an idea, how to solve that issue ?

dlakelan commented 6 years ago

I think the first thing is to test two connections that aren't encrypted, the cpu requirements of the encryption inherently makes this asymmetric and that confuses the issue. How much of a testing setup do you have? Can you try prioritizing two different ip addresses instead of two different protocols and then try an HTTP download from each host and see how the bandwidth sharing works?

mniehren commented 6 years ago

I've checked a doubled Download, 1 over http, 1 over https with the following config: DEVICE=eth1 INPUT_SPEED=16Mbit OUTPUT_SPEED=2200Kbit LINKTYPE="adsl local pppoe-llc"

interface $DEVICE eth1-in input rate $INPUT_SPEED $LINKTYPE class www1 commit 40% match ip 217.11.60.18 class www2 commit 3% match ip 217.11.60.9 class surfing commit 1% match tcp sports 0:1023

interface $DEVICE eth1-out output rate $OUTPUT_SPEED $LINKTYPE class www1 commit 40% match ip 217.11.60.18 class www2 commit 3% match ip 217.11.60.9 class surfing commit 1% match tcp dports 0:1023

here is the log from fireqos status eth1-in:

TOTAL www1 www2 surfin defaul 179 - - - 179 276 - - - 276 120 - - - 120 169 - 1 - 168 14625 - 14413 - 212 15235 - 15027 - 208 15190 - 14999 1 189 15153 - 14818 41 295 14955 - 14720 14 222 15111 - 14955 3 153 15120 4033 10872 - 216 15311 7514 7584 - 214 15165 7528 7472 - 165 15195 7556 7472 - 167 15188 7498 7528 - 162 15147 6128 8871 - 162 15205 5429 9557 - 206 15250 5947 9081 - 223 15316 6253 8926 14 123 14982 5945 8856 3 179

so you see, the same results.

You can see it yourself with the following 2 downloads: wget https://f-droid.tuxgreen.de/linux-4.9.73.tar.xz --no-check-certificate for www1 wget http://www.tux-steuerung.de/linux-4.9.73.tar.xz for www2

dlakelan commented 6 years ago

well, this still has a cpu imbalance because of https but let's ignore that for the moment, it certainly seems like you're getting more like "balanced" performance where each class has the same priority.

what version of fireqos are you using?

also what is the output of

fireqos debug

mniehren commented 6 years ago

i am using V3.1.5.

Do you have the same effect with my config ?

Here is the output of fireqos debug:

tuxguard@~# fireqos debug FireQOS 3.1.5 (C) 2013-2014 Costa Tsaousis, GPL

: interface eth1 eth1-in input rate 16Mbit adsl local pppoe-llc (eth1-ifb, 16000kbit, mtu 1500, quantum 1500, minrate 160kbit) /sbin/tc qdisc del dev eth1-ifb root /sbin/tc qdisc add dev eth1-ifb root handle 1: stab linklayer adsl overhead 40 mtu 1500 htb default 8000 r2q 13 /sbin/tc qdisc del dev eth1 ingress /sbin/tc qdisc add dev eth1 ingress /sbin/tc filter add dev eth1 parent ffff: protocol all prio 39999 u32 match u32 0 0 action mirred egress redirect dev eth1-ifb /sbin/tc class add dev eth1-ifb parent 1: classid 1:1 htb rate 16000kbit ceil 16000kbit quantum 1500 : class www1 commit 40% (1:11, 6400/16000kbit, prio 0) /sbin/tc class add dev eth1-ifb parent 1:1 classid 1:11 htb rate 6400kbit ceil 16000kbit prio 0 quantum 1500 /sbin/tc qdisc add dev eth1-ifb parent 1:11 handle 11: fq_codel : match ip 217.11.60.18 /sbin/tc filter add dev eth1-ifb parent 1:0 protocol ip prio 10 u32 match ip src 217.11.60.18 flowid 1:11 /sbin/tc filter add dev eth1-ifb parent 1:0 protocol ip prio 10 u32 match ip dst 217.11.60.18 flowid 1:11 : class www2 commit 3% (1:12, 480/16000kbit, prio 1) /sbin/tc class add dev eth1-ifb parent 1:1 classid 1:12 htb rate 480kbit ceil 16000kbit prio 1 quantum 1500 /sbin/tc qdisc add dev eth1-ifb parent 1:12 handle 12: fq_codel : match ip 217.11.60.9 /sbin/tc filter add dev eth1-ifb parent 1:0 protocol ip prio 20 u32 match ip src 217.11.60.9 flowid 1:12 /sbin/tc filter add dev eth1-ifb parent 1:0 protocol ip prio 20 u32 match ip dst 217.11.60.9 flowid 1:12 : class surfing commit 1% (1:13, 160/16000kbit, prio 2) /sbin/tc class add dev eth1-ifb parent 1:1 classid 1:13 htb rate 160kbit ceil 16000kbit prio 2 quantum 1500 /sbin/tc qdisc add dev eth1-ifb parent 1:13 handle 13: fq_codel : match tcp sports 0:1023 /sbin/tc filter add dev eth1-ifb parent 1:0 protocol ip prio 30 u32 match ip protocol 6 0xff match ip sport 0 0xfc00 flowid 1:13 : class default (1:8000, 160/16000kbit, prio 3) /sbin/tc class add dev eth1-ifb parent 1:1 classid 1:8000 htb rate 160kbit ceil 16000kbit prio 3 quantum 1500 /sbin/tc qdisc add dev eth1-ifb parent 1:8000 handle 14: fq_codel : committed rate 7200kbit (45%), the remaining 8800kbit will be spare bandwidth.

: interface eth1 eth1-out output rate 2200Kbit adsl local pppoe-llc (eth1, 2200kbit, mtu 1500, quantum 1500, minrate 22kbit) /sbin/tc qdisc del dev eth1 root /sbin/tc qdisc add dev eth1 root handle 1: stab linklayer adsl overhead 40 mtu 1500 htb default 8000 r2q 1 /sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 2200kbit ceil 2200kbit quantum 1500 : class www1 commit 40% (1:11, 880/2200kbit, prio 0) /sbin/tc class add dev eth1 parent 1:1 classid 1:11 htb rate 880kbit ceil 2200kbit prio 0 quantum 1500 /sbin/tc qdisc add dev eth1 parent 1:11 handle 11: fq_codel : match ip 217.11.60.18 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip src 217.11.60.18 flowid 1:11 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 10 u32 match ip dst 217.11.60.18 flowid 1:11 : class www2 commit 3% (1:12, 66/2200kbit, prio 1) /sbin/tc class add dev eth1 parent 1:1 classid 1:12 htb rate 66kbit ceil 2200kbit prio 1 quantum 1500 /sbin/tc qdisc add dev eth1 parent 1:12 handle 12: fq_codel : match ip 217.11.60.9 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 20 u32 match ip src 217.11.60.9 flowid 1:12 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 20 u32 match ip dst 217.11.60.9 flowid 1:12 : class surfing commit 1% (1:13, 22/2200kbit, prio 2) /sbin/tc class add dev eth1 parent 1:1 classid 1:13 htb rate 22kbit ceil 2200kbit prio 2 quantum 1500 /sbin/tc qdisc add dev eth1 parent 1:13 handle 13: fq_codel : match tcp dports 0:1023 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 30 u32 match ip protocol 6 0xff match ip dport 0 0xfc00 flowid 1:13 : class default (1:8000, 22/2200kbit, prio 3) /sbin/tc class add dev eth1 parent 1:1 classid 1:8000 htb rate 22kbit ceil 2200kbit prio 3 quantum 1500 /sbin/tc qdisc add dev eth1 parent 1:8000 handle 14: fq_codel : committed rate 990kbit (45%), the remaining 1210kbit will be spare bandwidth.

Traffic is classified:

  - on 2 interfaces
  - to 8 classes
  - by 6 FireQOS matches

35 TC commands executed

All Done! Enjoy... bye...