I have 3 interfaces and using SQM I have divided bandwidth as:
interface1 (LAN) {LAN1} = 12 Mbps
interface2 (LAN_S) {LAN2} = 10 Mbps
interface3 (WIFI_S) {LAN3}= 6 Mbps
I think you can do this by setting up one or more IFB's.
Consider this example here:
As you can see depending on whether WireGuard is up I amalgamate packets from both WireGuard interface and wan interface taking care to skip over encrypted packets in wan.
Perhaps something along these lines will help you.
With this approach you create your own 'intermediate frame buffer' interface through which packets from other interfaces are pulled and then sqm on that. Funky right?
Seems like a lot of trouble though compared to just one interface on the relevant wan interface you want to control, especially given that your lan bandwidths are almost the same.
Internet is expensive here, most optimal price is for 30Mbps and my 2 neighbours and I bought one single connection, 1st pay 45% of bill, 2nd neighbor pays 35% and 3rd pays 20%.
What dictates how traffic is routed from the different lan interfaces to the different wan interfaces? Is this based on src/dest IP or does the routing change depending on whether one of the wan interfaces is up?
Are you looking to apply CAKE on each interface LAN1/2/3 on everything that is NOT directed to/from 172.22.xx.xx?
Perhaps something like this would work?
For upload you set up three IFB's for LAN1/2/3 that skip traffic destined for 172.22.xx.xx and apply CAKE on those.
For download you set up three IFB's for LAN1/2/3 that skip traffic with source 172.22.xx.xx and apply CAKE on those.
@moeller0 is there a simpler way? And I think? IFB's can be set for both directions like this?
I would probably rethink the situation a bit. Assuming that there is no traffic volume-dependent cost, static partitioning of capacity based on the worst case scenario seems suboptimal. If only user 1 is active, why throttle her/him to 45% of the link's capacity (same for all other users)? I would consider it to be fair, if left-over capacity is used, but that each user gets a guaranteed capacity share proportional to her/his payment share, but would only enforce that if capacity is congested.
I would roughly go along like this:
make sure each users sub-net has a known internal IP range (or a list of registered MAC addresses) so that traffic can be easily categorized by "neighbour".
take simple.qos and modify it to have three tiers each with the same prio and the respective share of the total capacity configured as rate and say 95% of the links total capacity as ceil, so each neighbour can get up to 95% of capacity if no other neighbour uses the network, but under congestion each just gets their "fair" share.
However, being in the privileged position I am in (recent cost of living increases not withstanding), I would probably be the person paying the lion's share and I would simply use cake's per internal IP fairness mode, and just keep an eye on whether that is not glaringly unfair...
This makes more sense I think. Is it easy to set up such prioritisation based on IP ranges such that you can have three ranges 1, 2 and 3 and load evenly distributed between those three ranges?
Actually in my own setup I recently suffered from a Teams dropout I think because capacity went down to the minimum owing to peak congestion and my wife was streaming from Netflix at exactly that time. I think this is where prioritisation in my case would be useful, but the markings mechanisms all looks a little messy to me. Could I blanket mark all guest traffic (which includes our TVs) with one mark and all non-guest traffic with another mark such that CAKE will always prioritise non-guest traffic?
@Dopam-IT_1987 is there an easy way to mark packets without writing a 500 line script or is such a script the only way?
Nothing dictates it, Both wan interfaces are always up, both interfaces work simultaneously, 2nd interface is ISP Based Portal for cloud storage and free movies.
both interfaces should be up always and one interface provides us with internet and other with special features but not internet.
That's Something I wanted.
I am not sure, that's why I am here to ask experts like you.
I am okay with your idea but my issue always had been of bandwidth before sqm, those who pay more used to get less speed than those who pay less. The one with 6Mbps is always the trouble, he pays less share but he is always using torrents and all & and without us limiting using sqm our bandwidth usually gets to 0.5-3Mbps which is quite less than we deserve.
If there is a way to resolve this issue, I would highky appreciate it.
I have already did that.
Need a little help with that as I am unable to find a related documentation for that.
Tried that and the person paying 2nd large share was about fight with me over that as he was getting quite less speed due to our 3rd neighbour unfortunately.
good evening there was luci-app-qos in the past that divided by ip or mac equipment,
with cake i don't really know how i can do it, i just use host isolation,
I just wanted to do this too at some point so that my console is the maximum bandwidth without stopping
but starting a script for that might be quite long, @Lynx
WAN="wan"
# The network interface we're planning on limiting bandwidth.
# Download limit (in mega bits)
DNLD1=8mbps # DOWNLOAD Limit
DNLD2=13mbps # Download Limit
DNLD3=5mbps # Download Limit
# Upload limit (in mega bits)
#UPLD1=2mbps # UPLOAD Limit
#UPLD2=4mbps # Upload Limit
#UPLD3=1Mbps #
# IP address of the machine we are controlling
IP=192.168.2.1** # Host IP
IP1=192.168.2.1** # Host IP
IP2=192.168.** # Host IP
@moeller0 can you please help me out with this scenario?
"If only user 1 is active, why throttle her/him to 45% of the link's capacity (same for all other users)? I would consider it to be fair, if left-over capacity is used, but that each user gets a guaranteed capacity share proportional to her/his payment share, but would only enforce that if capacity is congested."
So this has two components, an easy one and a more tricky one. Getting HTB set up to offer three bands of guaranteed rates (like 45, 35, 25% of the total) with "borrowing" up to the link speed is the easy part. Steering packets into the desired band is considerably trickier. The way sqm typically works is that both ingress and egress instance sit outside of the NAT domain, so your internal IP addresses are not available, but I assume these to be your main identifiers... Foe egress that can be worked around by setting a DSCP of firewall mark and steer the packets based on that mark, but for ingress that simply does not work with the typical IFB. So you probably need to either use a wired-only primary router with sqm on the LAN side (there internal addresses will be visible) or use veth pairs to router the ingress traffic inside your NAT domain. I have personally zero first-hand experience with veth so can not help you there.
