Need help for limiting bandwidth for a subnet mask


I'm coming from DDWRT and I had an ability to limit the bandwidth only for a whole subnet mask.
My previous setup on DDWRT was limiting the bandwidth for and my DHCP pool was
The bandwidth limitation for this subnet mask was 16000kbps(DOWN)/3500kbps(UP). My internet connection can go up to 20048kbps download and 4048kbps upload.

I don't find how to replicate the same thing on LEDE. Can someone help me?

Why I do this?
When someone of my family by downloading reach the maximum of my internet connection the ping goes high and playing online games is impossible.
This way only selected devices by me out of the subnet mask limited range can affect the ping.

Take a look at the SQM section in the LEDE documentation...

@unixfox If sqm is not working like intended try old school qos; disable sqm, install luci-app-qos, qos-scripts (not sure if it is done automatically if you install the luci app) and your language pack.

Please also use the search function of the forum ;- )

@Doppel-D Thank you for your reply!

I already did a tons of search and I couldn't find a way to only limit the bandwidth of a special subnet mask.
I've got QoS already installed because I knew it was not possible on SQM.

I explain you in details what I want to do.
My main subnet mask is with my routers and the others devices in my house.
My DHCP distribute only IPs from to
I want to only limit the bandwidth for the range of to, a whole subnet mask of :
This way the others devices ( to will never be rate limited and I'll set the IP of my devices to the range that it's not rate limited. For example my personal computer will have this IP:

Here is a screenshot of my QoS configuration on DDWRT:

I read the documentation and I can't figure out how to do this with QoS.

Have you tried sqm?

Have you tried the iptables --connrate option?



This module matches the current transfer rate in a connection.
--connrate [!] [from]:[to]
Match against the current connection transfer

sqm can be used for bandwith limiting

I set it up 2 days ago. It even can track how much data each device downloads and throttle down bandwith for it so that it does not use too much bandwith if on metered connection. Or you can just limit max bandwith for them and that's it.

1 Like

Thank you for your reply all of you!

I found a way to achieve my goal.

I splitted the lan interface into two virtual interfaces, one for me and the another for my family. This way I limited only the virtual interface of my family using wondershaper.

Final results:

About SQM I quickly gave up this idea because I got really bad ping if I set to 95% of my connection and if I set to 80% of my connection I get an almost stable ping but I lost some of my bandwidth.

By the way I'm building since a few days a complete custom build for my tplink router and I will post it on this forum as soon as I find it stable for public use.

1 Like

Thanks for sharing @unixfox
I'd like to try this but I can't understand how this table works.
I'd appreciate your help (you can PM me if you don't want your thread spammed)

Please, do your family a favor and do not use wondershaper anymore, it was great for its day, but it really is an ancient relict of simpler times. You could use sqm's piece_of cake instead (sqm will only affect the interface it is instantiated on, so it should not conflict with whatever else you set up for the rest of your network.).

That said, have you tried following the instructions on especially the last paragraph?

Honestly, this is simply the "approximateness" of ingress shaping, and for that you will need to sacrifice some bandwidth, but that is the only way to maintain decent latency under full load (well, except, if you ISP is enlightened and does proper bufferbloat free ingress shaping for you line you will not need to implement your own ingress shaper, the fact that sqm-scripts with ingress 95% did not work, makes this unlikely though).
Judgnig from your use case "online games" I would assume that bounded latency under load would be more important to you than a bit of your bandwidth, but this is a trade-off everybody needs to find for themselves (there is no objective better or worse, it truly is subjective).

But really, I wonder what issues you encounter with sqm/cake's per internal-IP-fairness; if you would be willing to tesat that again and let me know what issues you encounter, I would be willing to a) try to help you get sqm optimised or b) if that fails try to relay your issue to the cake developers...

Best Regards

P.S.: Not re-testing sqm/cake is obviously also fine, we would just miss out on a data-point about its short comings making it less likely that the observed behavior, even if caused by a bug, will be fixed/changed in the future...

1 Like

Isn't SQM more cpu intensive than wondershaper? I chose wshaper because it was really simple and did his job very well. I'll test SQM a second time to see if it's working almost like wshaper. I am open to test multiple solutions because I'm not at my first flash, I flashed my router almost 50 times since a few days to find the perfect build (I've a router with low flash/ram: TP-Link TL-WR841N(D) v11).

You are talking about: Making cake sing and dance, on a tight rope without a safety net?
If so I don't understand how that could make the ping stable while my brother is watching a movie on Youtube?

I'm both a gamer & a Linux SYSAdmin and I need to use all of my bandwidth because I'm often in the case when I upload something to my servers and it penalizes me by reducing the upload speed from 4048kbps to almost 3000kbps. The latency increases the closer we get to the maximum that my line offers in upload.

Like I said on Reddit, my ISP is letting me having more bandwidth than my line can offers. The max of my line is 16000kbps(DOWN)/3500kbps(UP) and my modem is configured at 20048(DOWN)/4048(UP). I have the privilege of having this exception (because my ISP advertise more on their website (internet Loco): and I would be disappointed in myself depriving myself of it.
Technical details retrieved by a VDSL2 tool for my modem:

                       download          upload
Line:                  20048 kbps        4048 kbps
Modem max:             20592 kbps        n/a Estimated!
Calculated max:        16907 kbps        3542 kbps Estimated!
Profile:               8d
Line length:           247 m Estimated!
Training margin:       6.3 dB
Attenuation:           18.1 dB

6dB for training margin is the lowest value with frequent desynchronization and that's a really bad value. The normal value is at around 10dB (source: [The values ​​of the noise margin and their characteristics]).

PS: I appreciate your interest in my issue.

Start with repeated speedtests on the raw line with no shaping or other users. You should not count on more than the advertised plan speed. Trying to use that is going to introduce a variability issue. If it is dropping below that there are likely signal problems.

In my experience with ordinary slow ADSL (6 / 0.75) I just set an uplink sqm to 0.70 and leave the downlink unregulated. At least the provider has a reliable line that always tests out at 6 / 0.75.

In my experience, an ISP "letting" you have "more than the line can offer" is a bug not a feature. The result will be frequent packet loss, periods of disconnection and resynchronization, and maybe ultimately lower bandwidth due to all the errors/drops/resyncs. If that isn't true for you... well you're lucky!

If you want to rely on your devices working, setting better training margins and getting slightly less but very reliable bandwidth may ultimately give you better results.

If you have sophisticated needs for QoS, and you're a SysAd anyway so have experience configuring things, I don't think you'd go wrong using FireQOS and setting up a custom system that works for your needs. For example you can just put all the "family" Vlan into a single queue with lower priority than the queues you're using exclusively for the known IP addresses of the servers you admin... and whenever you need to do some real work, your connection gets all the bandwidth it needs.

FireQoS is essentially a high level language for specifying QoS which gets "compiled" into a set of tc commands.

btw you can specify the use of the "cake" qdisc in FireQOS. the cake qdisc and the SQM config scripts are completely separable.

Not really, as far as I know the heavy cost is caused by the shaper itself, so it does not matter much whether you use HTB, HFSC, cake or ... So in short wondershaper is in all likelihood not much cheaper than sqm-scripts.

Great, I am interested to learn your opinion after that test.


Well, if only your brother and you are using the network each of you will get 50% of the bandwidth under full saturation load. Now there is going to be some serialization delay, but cake, AFAIK, will happily switch between users on a packet by packet basis and should be able to isolate your gaming reasonably well from your brother's you-tubing (assuming the 50% of the bandwidth is sufficient for each of you). But all theory is gray, so just go and test whether that works in practice.

Ah, in the upload direction, sqm does typically not need a big bandwidth sacrifice, with your VDSL2 link you should be able to run it at 100*64/65 = 98.46 % of sync rate (assuming your ISP does not also use a shaper/policer between the dslam/msan and the wider internet). But you will need to correctly describe the link characterization to sqm scripts (basically you need to define the correct per-packet-overhead). But in the download/ingress direction you will need to make a bandwidth sacrifice, otherwise any inrushing traffic will easily "spill-back" into the dslam's/msan's/upstream shaper's buffers and induce unwanted additional latency under load...

That does not seem to be possible...

Looking at the "loco" plan is 50/4, so 20/4 dos not seem to be sign of generosity of your ISP, but rather an indicator that your DSLAM/MSAN is slightly further away than ideal.

That seems like an over simplification at best; if training margin is the same as SNRM, then sure higher offers more resilience, but that actually is a value your ISP picks, in a reasonable noise free environment, 6dB is just fine. In your case since you are too far from the dslam/msan for full sync (50/4) I guess this really just shows your ISP configured its gear for >= 6dB SNRM.

Best Regards

On an ADSL link you also need to configure link layer ATM otherwise ATM/AAL5's 48/53 encoding will make a shaper setting of 0.7 for 0.75 sync rate uncomfortably close (0.75 * 48/53 = 0.679245283019, and that does not include any other per-packet-overhead). I assume that you took care of that, but just to state the obvious :wink:

I agree with @moeller0 about the implications for 6dB SNR margin. It really all depends on how often you get noise bursts. My mother has DSL and her modem gives statistics on forward error correction rate (correctable errors) and CRC error rate (uncorrectable errors). She's got relatively massive FEC errors per 24 hours (millions of packets) but it typically results in something like 100 CRC errors, so for the moment it's OK. But if the season changes, or it's windy, or whatever I could easily imagine her internet going up and down like a YoYo as FEC no longer is sufficient, and probably would then resync at a lower rate. If that happened, the QoS which is tuned to the rate she gets now would probably work very poorly. She'd also hate trying to VOIP under those circumstances I'm sure.

@dlakelan That's what just happened to me yesterday (because it was very windy) my internet dropped and I had to reboot the modem. I'm currently trying to get this resolved with my ISP because that's not the first time but that's another story.

@moeller0 I tried multiple combinaisons for SQM (ingress/egress queueing disciplines, all the queue setup scripts), I didn't find the right one to let me capable of using all the bandwidth and having a stable ping when my brother is watching a Youtube video or my mother uploading something on Dropbox for example because according to my tests SQM is designed to get an equal traffic for each user on the network while maintening a stable ping and not for giving the power to one device to be capable of using all the bandwidth and maintening a stable ping by limiting the bandwidth for the others members of my family when I just play an online game and my family watching a movie on a streaming website. I even tried an experimental setting called "Latency target for ingress/egress" but that worked pretty bad maybe because my router can't handle it (CPU).

I'll stick to my initial configuration with SQM on the VLAN of my family instead of wondershaper.
If I get a better internet connection by contacting my ISP about my issue (or by moving to another because Scarlet is the worst in my country) I'll retry all the possibilites that you talked about (@moeller0 @dlakelan @lleachii ) but currently I'm pretty happy with my settings.

Thank you everyone for your help.

Have you tried the advanced options recommended in the "sing and dance" section of lede's sqm documentation? As long if there are not more than 5 concurrently active devices in your network the sing and dance instructions should guaratee your gaming host as much bandwidth as you have now, but with the advantage that the latency of unrelated flows should stay sane even if the link is fully loaded...

Not exactly, initially it only offered per-flow-fairness, and that means a multi-flow torrent/windows10 update user gets more of the available bandwidth; only later additions to the cake qdisc tried to do a first round of per-IP-address-fair bandwidth sharing.

True, sqm is not designed for that; but partly because this description seems under-constraint. Only if the one device does not use more than (total bandwidth - other user's bandwidth) will this scheme work in maintaining low latency for all, once the combined bandwidth of all devices exceeds the total available bandwidth you will need to deal with increasing latency and/or packet loss. So in short, do not touch "tsrget" unless you know what you are doing. Please note that sqm and cake will take care of the at least ~1.5 fullMTU packets equivalent for you automatically.

Probably nothing wrong with your router, but fq_codel's target parameter is not a knob to turn to control the latency, really this needs to be set to the higher of 5-10% of the specified "interval" parameter or the tie it takes to transmit say 1.5 * fullMTU packets. THere is a reason why the target fields in the GUI are hidden behind "Show and Use Advanced Configuration" and "Show and Use Dangerous Configuration"...

This is fine, after all if you are happy your problem is well-solved.

Best Regards