Hello,
What is the best way to do SQM/QoS for dual LTE WAN connections?
I have read that SQM does not work with LTE connections because the speeds are variable, what’s the alternatives?
Mwan3 policy is balanced and default rules.
I also use DoH https-dns-proxy with ControlD DNS.
LTE data plan is 1TB per month.
Thanks
Network Layout:
regarding your topology...
it's not exactly clear how traffic is passed to WANB... (i.e. for sqm, traffic must pass over a (typically) layer3 router interface...)
given the initial diagram, it's possible for lan hosts to access wanb directly...
specifically... you may wish to provide a sanitized
uci show network
uci show mwan3
uci show sqm
also, given the question asked...
is a fairly minimal description of what wan links are present, including typical throughput and/or variance observed for each LTE link if known...
sidenote:
using 'distant reflectors' as a metric is inherently problematic... ( though I can understand why people opt to use them )...
you may wish to do some research or get in touch with your ISP regarding any cdn-peering or internal speedtest or other infrastructure suitable for such a purpose...
Hi,
I am not currently using SQM or QoS.
WAN is connected to RPi with USB Ethernet and WANB is connected to Dell gigabit switch VLAN tagged.
LAN hosts are not able to connect to WANB directly, it's configured on the RPi
Okay here is the config:
uci show network
network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fd2c:c128:xxxx::/48'
network.@device[0]=device
network.@device[0].name='br-lan'
network.@device[0].type='bridge'
network.@device[0].ports='eth0'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.delegate='0'
network.wan=interface
network.wan.device='eth1'
network.wan.proto='static'
network.wan.netmask='255.255.255.0'
network.wan.gateway='192.168.8.1'
network.wan.dns='76.76.xxx.xxx'
network.wan.metric='10'
network.wan.delegate='0'
network.wan.ipaddr='192.168.8.2'
network.wanb=interface
network.wanb.proto='static'
network.wanb.device='eth0.20'
network.wanb.netmask='255.255.255.0'
network.wanb.gateway='192.168.0.1'
network.wanb.dns='76.76.xxx.xxx'
network.wanb.metric='20'
network.wanb.delegate='0'
network.wanb.ipaddr='192.168.0.2'
network.guest=interface
network.guest.proto='static'
network.guest.ipaddr='10.20.3x.xxx'
network.guest.netmask='255.255.255.0'
network.guest.gateway='10.20.3x.xxx'
network.guest.device='eth0.40'
network.guest.delegate='0'
network.iot=interface
network.iot.proto='static'
network.iot.ipaddr='172.17.xxx.xxx'
network.iot.netmask='255.255.255.0'
network.iot.gateway='172.17.xxx.xxx'
network.iot.device='eth0.50'
network.iot.delegate='0'
uci show mwan3
mwan3.globals=globals
mwan3.globals.mmx_mask='0x3F00'
mwan3.wan=interface
mwan3.wan.enabled='1'
mwan3.wan.track_ip='8.8.4.4' '8.8.8.8' '208.67.222.222' '208.67.220.220'
mwan3.wan.family='ipv4'
mwan3.wan.reliability='2'
mwan3.wanb=interface
mwan3.wanb.track_ip='8.8.4.4' '8.8.8.8' '208.67.222.222' '208.67.220.220'
mwan3.wanb.family='ipv4'
mwan3.wanb.reliability='1'
mwan3.wanb.enabled='1'
mwan3.wanb.initial_state='online'
mwan3.wanb.track_method='ping'
mwan3.wanb.count='1'
mwan3.wanb.size='56'
mwan3.wanb.max_ttl='60'
mwan3.wanb.check_quality='0'
mwan3.wanb.timeout='4'
mwan3.wanb.interval='10'
mwan3.wanb.failure_interval='5'
mwan3.wanb.recovery_interval='5'
mwan3.wanb.down='5'
mwan3.wanb.up='5'
mwan3.balanced=policy
mwan3.balanced.last_resort='unreachable'
mwan3.balanced.use_member='wanamem' 'wanbmem'
mwan3.https=rule
mwan3.https.sticky='1'
mwan3.https.dest_port='443'
mwan3.https.proto='tcp'
mwan3.https.use_policy='balanced'
mwan3.default_rule_v4=rule
mwan3.default_rule_v4.dest_ip='0.0.0.0/0'
mwan3.default_rule_v4.use_policy='balanced'
mwan3.default_rule_v4.family='ipv4'
mwan3.default_rule_v6=rule
mwan3.default_rule_v6.dest_ip='::/0'
mwan3.default_rule_v6.use_policy='balanced'
mwan3.default_rule_v6.family='ipv6'
mwan3.wanamem=member
mwan3.wanamem.interface='wan'
mwan3.wanamem.metric='1'
mwan3.wanamem.weight='1'
mwan3.wanbmem=member
mwan3.wanbmem.interface='wanb'
mwan3.wanbmem.metric='1'
mwan3.wanbmem.weight='1'
LTE speed range from 2mbps to 80mbps, this is variable depending on time/ weather/ tower congestion, average maybe around 50mbps.
Edit: This is fixed LTE, I have to reboot the LTE routers every few days, sometimes the speed drops to like 2mbps until a reboot. Also played around with the huaCtrl android app to change LTE frequencies since ISP supports 900, 1800 and 2100mhz frequencies.
Here is some speed test results:
Maybe bring this up in the other thread, where it would be more relevant? But I assume we all agree that ideally we would like to get a robust and reliable (preferably on-way-delay) measurement node as close to the other end of the bottleneck link as possible. But in lieu of that we need to work with what we got, which is close by (by virtue of any-cast and CDN) popular server addresses.
That is hugely irritating. Is that with any provider or only the specific provider you use? Is it reflected in LTE stats you read off? If so I suppose you could read those in a script and reboot when needed. But I wonder if there is a way to avoid this. Does it only happen when you manually set the frequencies? I don't experience this at all with my B818-263. So you could consider trying one of those but they are expensive and hard to come by.
One of the coolest LTE setups I have come across is used by @Nomid. He has a setup based on RPi4 together with this:
I am curious about an arrangement like this myself, albeit @Nomid is within line of cite of a cell tower offering multiple bands. I am also close to cell tower but it does not offer multiple bands. I am getting pretty close to the best I could get from my cell tower anyway, I believe, particularly in the light of its congestion.
TBH, I think the first thing I personally would see if I could solve in that setup is the need for periodic reboots, if possible. The question of SQM is better answered in Lynx thread on Cake with adaptive bandwidth (my guess is that it might be possible to run dual instances of his script, or any of the other solutions in that thread) . My setup is a rpi4 with a USB modem attached, this is actually possible for you to test within a reasonable price i think, the question here is if it is your ISP or your Huawei's that are causing the problem, or even further down your chain. First thing I would do is try and figure out what exactly your tower and ISP delivers, what kind of bands, what kind of band aggregation, and perhaps MIMO, there is on that tower. What I would love to test in your setup is a simple cheap modem in a USB sleigh on that Rpi4 you have, the @anon50098793 build allready supports modemmanager, and I am personally testing that build right now with my modem, it works great for me. An em7455 modem can be had for around 15$, it's cat6 and on my connection it topped out at 110 Mbps, there are several m2 to usb adapters around in the 30$ price range. This solution would be reasonably plug and play, and will help you check if your problem is with those Huawei's or your ISP. Second, If you can test other openwrt builds on that rpi4, I would check out the Rooter build, this build is made by a bunch of really great guys and it is made for LTE connections, in that build you have the possibility of seeing exactly what band aggregation is going on, plus you have the possibility of band locking and several other neat things. I learned an awful lot about my connection using that build. The rooter build also has load balancing (i believe wulfy's build does too) and this might also be something you want to explore with your setup.
Thanks for the replies, I will test @Lynx 's script when I get a chance.
It's mainly an ISP issue and unfortunatley I don't have any other alternatives yet.
ISP only allows certain devices for fixed LTE.
HUAWEI 5G CPE PRO 2
HUAWEI B2368
HUAWEI B2368-22
HUAWEI B2368-57
HUAWEI B2368-66
HUAWEI B525S-23A
HUAWEI B525S-65A
HUAWEI B525S-95A
HUAWEI B535-932
HUAWEI B612-233
HUAWEI B612-533
HUAWEI B612S-25D
HUAWEI B612S-51D
HUAWEI B612S-52D
HUAWEI B618S-22D
HUAWEI B618S-65D
HUAWEI B618S-66D
HUAWEI B818-263
MIKROTIK CHATEAU LTE12
TP-LINK ARCHER MR600(EU)2.0
VIDA CPE4000-PLUS
VIDA CPE4000-PRO
ZTE 5G CPE MC801A
ZTE MF286
ZTE MF286A
ZTE MF286C
ZTE MF286C1
ZTE MF286D
ZTE MF286R
ZYXEL LTE7460
ZYXEL LTE7480-M804
Thanks
fyi: i've added @Lynx, @moeller0 and friends script to the build (will push in an hour or so), thankyou's!
should support multiple interfaces with;
option autorate '1'
at /etc/config/sqm for each sqm definition no need to edit the script...
for upstream amusement (or if anyone else has multiple instances until it's supported upstream) the source will be available here (in 15 mins) just unpack the tarball to / to test... to turn off... rm /bin/sqm-autorate-init.sh or set autorate '0' in /etc/config/sqm...
for manual usage (restarting sqm is all that's normally needed but command line is helpful for debugging);
sqm-autorate-init.sh [start|stop|status|help]
(note: extremely rough and currently only handles netdev+ifb4netdev aka single interface up+down wan links)
(note2: due to the way the upstream logic works afaik this is only for highly variable speed links for now... and not a 'generic-sqm-rate-tuner')
my implementation had some firstboot lockup bug... so will remove it and defer back to the originals...