Bandwidth control

Probably routing to dummy interfaces will work, but to be honest this is very messy. Also I am using ipv4...

I will have a router and some wifi range extenders with different SSID's and some subnets. Some networks shouldn't have much bandwidth at all. All traffic will be routed. The range extenders don't support vlans, which would have made it all more easy.

I don't have experience with tc filters at all and I guess there would be much help needed.

I will have clients and a guest network and well they just don't need much bandwidth at all. Fair queuing is nice, but not a solution for any case. The best would be "fairness mode" for normal clients and some bandwidth limiting for special networks.

I think what you need is VLANs. You can put an SQM instance on eth0.4 or something, and then all your guest traffic on vlan 4 is limited. Perhaps try powerline modems instead of range extenders. They should pass vlan traffic fine.

If not, perhaps you can dedicate a separate range extender for each network. Then plug them to different ports on your switch. Put each switch port on different VLAN untagged, and have the router use tags. put SQM on the tagged interfaces in the router. voila.

If you don't have a metered connection, your other option would be to use something like a smart switch with QoS in the smart switch. Put high priority on your main network ports, and low priority on your guest network ports. Let guest network have as much bandwidth as it wants... but only as scavenger priority (DSCP CS1)

Your suggestions are all good and would solve the problem, but means in my case I need different hardware and well I wanted to avoid that.

So all in all I think I have two possibilities:

  1. Buy different hardware
    OR
  2. Maybe traffic won't be too much and fair queuing would be a good first step

As far as I understand openwrt isn't capable of doing that at the moment. It would probably need more specialized SQM scripts. I saw many posts like this on the web and is there a way to make feature requests?

Thank you for your help and time!

Here's what I suggest with no additional hardware required.

Turn on SQM on your WAN interface as outbound only (use the physical interface, like eth0.1 or whatever).

Turn on SQM on your LAN interface as outbound only with the layer cake option (use physical interface, eth0.2 or whatever) use the outbound bandwidth as the same as your WAN inbound bandwidth.

create a DSCP tagger chain in your firewall, and tag all the packets headed to your guest LAN as CS1, tag all the packets headed to your primary LAN as CS2. See recent thread here: Creating DSCP markings with iptables?

VOILA! high priority for your main LAN, low priority for your Guests, no bandwidth limit required.

DSCP markings are a good tip, thanks for that!

Turn on SQM on your WAN interface as outbound only (use the physical interface, like eth0.1 or whatever).
Turn on SQM on your LAN interface as outbound only with the layer cake option (use physical interface, eth0.2 or whatever) use the outbound bandwidth as the same as your WAN inbound bandwidth.

Why do you suggest to use SQM on WAN and LAN interface? Wouldn't WAN only be enough?

No, because the DSCP markings won't be on the packets at the time the WAN interface inbound is being queued. First they'll be queued, then they'll go into iptables and get marked, then it's too late.

On the other hand, if you have no inbound queueing on WAN, they'll go into iptables, be marked, and then on outbound of LAN they'll be queued again using the marks.

+1. Please go and try this first as this will be quite easy to implement, even if it is not sufficient it should be better than the current behavior and will make things slightly better while you are searching for a better solution.
I note that there seems to be a package under development that tries to use iptables to allow per-device ot per-subnet throttling, though currently IIRC you will need to build this from source. Unfortunately I do not even find the link right now. @hnyman do you remember the link to the discussion about using iptables for fine-grained speedcontrol by any chance?

No, because the DSCP markings won't be on the packets at the time the WAN interface inbound is being queued. First they'll be queued, then they'll go into iptables and get marked, then it's too late.
On the other hand, if you have no inbound queueing on WAN, they'll go into iptables, be marked, and then on outbound of LAN they'll be queued again using the marks.

This means I have to enable SQM on all interfaces(LAN) which will receive traffic from WAN?

I will definitely try to implement that in the first step. Also very good to hear that there is a package under development, because sometimes this can be useful in addition to the solutions described here.

For example if you have a wlan0 and eth0.1 bridged together you have an issue because both wlan0 and eth0.1 need SQM on them (br-lan itself doesn't queue). Here you can actually put a veth0/veth1 pair, place the veth1 into the bridge, and then route traffic to veth0 instead of br-lan, then you put the SQM on the veth0, this allows you to put all the traffic through one place rather than have it branch out to two places.

For example if you have a wlan0 and eth0.1 bridged together you have an issue because both wlan0 and eth0.1 need SQM on them (br-lan itself doesn't queue). Here you can actually put a veth0/veth1 pair, place the veth1 into the bridge, and then route traffic to veth0 instead of br-lan, then you put the SQM on the veth0, this allows you to put all the traffic through one place rather than have it branch out to two places.

Makes sense, thank you!

@dlakelan

@moeller0

I did some more research on this topic and came across the hashlimit module which someone used to limit bandwidth. Wouldn't something like this do the job as well and is it even possible this way?

  1. Specify the subnets and mark them

iptables -t nat -A prerouting_rule_u -s 192.168.1.0/24 -j MARK --set-mark 100 -m comment --comment "Subnet Restriction Upload"

iptables -t nat -A prerouting_rule_d -d 192.168.1.0/24 -j MARK --set-mark 101 -m comment --comment "Subnet Restriction Download"

  1. Mark the whole connection

iptables -t nat -A prerouting_rule_u -m mark --mark 102 -j CONNMARK --save-mark

iptables -t nat -A prerouting_rule_d -m mark --mark 103 -j CONNMARK --save-mark

  1. Limit the marked connections

iptables -A forwarding_rule_u -m mark --mark 102 -m conntrack --ctstate ESTABLISHED,RELATED -m hashlimit --hashlimit-name "Upload speed" --hashlimit-above 250kb/s -j DROP

iptables -A forwarding_rule_d -m mark --mark 103 -m conntrack --ctstate ESTABLISHED,RELATED -m hashlimit --hashlimit-name "Download speed" --hashlimit-above 500kb/s -j DROP

Couldn’t run a test yet, first have to wait until the hardware is ready.

Well, certainly try to run a dslreports speedtest with the high resolution bufferbloat setting and compare the performance for say shaping to 500Kbps with the hash-limit option versus using sqm-scrits cake/layer_cake to shape the wan interface tp 500Kbps.
Also I wonder, have you tried the per-IP isolation modes yet? If yes, would you be willing to share your assessment? I do not want to claim ,that these are a solution for all QoS challenges and might well be not a good fit for your specific problem, but for a number of users that were simply used to having to do fine-grained QoS rules these isolation modes seemed to have been good enough to not bother anymore with all the details. (Yes I am trying to slolicit both success and failure stories, so I can give better advice in the future when those isolation modes might be applicable).

It seems to me that hashlimit is a bit of a sledgehammer and again doesn't let you fully utilize available bandwidth.

I think DSCP tagging and a smart switch is a good solution and not particularly expensive. Even a tplink sg108e (less than $40) will do weighted round robin for you. Mark guest Network traffic CS1 mark normal traffic CS2 and game traffic CS5, VOIP traffic CS6.

Put layercake/SQM queues on WAN outbound, and let the switch handle inbound post-tag, no goofy veth required.

Edit, thinking about this it doesn't work because the inbound bottleneck will be in your ISP equipment... So you really do need to shape the packets in the router.

The advantage to shaping is that the queue system sees the length of the queue and drops the appropriate packets. Hashlimit will be just a fixed policing of the subset that's tagged. Not in general as good.

This matches what I expect, but I really would like to see real-world measurements...

1 Like

No doubt, measurements would be useful. In fact I'd like to do some research on these things. It'd be nice to get a network of 5 machines and a couple of smart switches and APs and set up some intense latency / bandwidth / game play / VOIP / shaping tests.

@accelerate it seems the package I mentioned ( nft-qos) now made it into the repository:
https://github.com/openwrt/packages/pull/6193

But that still needs to be tested in regards to latency-increase under load...