Hi, after upgrading my rutx12 to RUTX_R_00.07.05, I noticed that the secondary modem in the load balancing configuration remains as standby instead of online, as it was before the update, so there is no indication that load-balancing is actually working.
Can you please advise if I need to configure something differently, or if this a bug that is particular to RUTX12 that has dual modems?
Would it be possible for you to reset the device to factory settings and see if the issue persists? You can download a backup before doing reset, so that you can upload it later.
Let me know if the issue persists. If it does, please provide details of the configurations you had before the update. Then, I will try to replicate the issue on my end.
Hi AndrejJ, the device is 100 Km away from my location, so if I factory reset it I will lose remote connection. I might try to do this in the weekend if I get to the location.
There is nothing special about my configuration:
2*sim cards from 2 separate ISP’s that I want to use in the same time (hence the reason I bought RUTX12 and not any of your other 1 modem devices)
A wireguard VPN connection to my site for administration and for some IoT to connect to my management server.
My secondary sim is my preferred ISP, as it has better internet speed even if less signal strength, hence the 2:1 ratio between the modems. (my understanding of ratios is, for every 2 connections my preferred modem gets, 1 connection the secondary modem will get, hence 2:1).
The main difference to the previous firmware version is that when using Load Balancing, both the modems reported as Online and the traffic numbers showed traffic on both modems.
After the update my top modem interface will show Online, while the lower one will show StandBy as in my screenshot and when looking at real time traffic I can see KB of data on my top interface while the bottom one is mostly at Bytes traffic levels, suggesting only network keepalive traffic.
Can you first confirm that on your instance of RUTX12 you have both modems reporting as Online when in Load Balancing mode on the final Firmware version, as that is not the bahavior I am experiencing. My modems report as being in failover mode (Online/Standby), even if they should be in Load balancing mode according to the interface selection (see top right corner in my screenshot).
Indeed, it seems that there is a visual issue with status of the interfaces when load-balancing is enabled. Apparently, this is not just on RUTX12. It can happen even when the wired WAN is used. However, this is just visual. While testing, the Wired WAN shows as Online, and mob1s1a1 as standby, but the connections are balanced over both interfaces. So there should be no issues with the load-balancing itself. The issue is strictly visual.
This has been reported to the RnD team and they will address this in the future firmware releases.
Thank you for noticing, and apologies for any inconvinience that this may have caused.
Unfortunately I have to disagree with your findings, at least in my situation. It does not seem to be just a visual bug, but an actual issue with load balancing.
I have disabled sticky connections and change the ration to 1 on both modems, then reset the traffic statistics. This configuration should ensure that traffic (connections to be more correct) is arbitrary distributed between the 2 modems, so in time the traffic reported by both modems should be close to the same (I can expect a few % difference, but not a huge difference as I can notice in my situation).
Please see my traffic stats below. As you can see, my Online modem (Secondary modem) reports ~252 MB transferred, while my Standby modem reports ~5.5 MB, so that is a 98% difference. This does not suggest connections are arbitrary distributed 1:1 as my configuration is currently set.
Just a disclaimer, I know that using the built in Speedtest will use the preferred modem to test the speed, thus ignoring the load balancing rule, but I did not use the test after resetting the traffics stats, so this is pure client trafic that should have been load balanced, but it is obviously not.
Of course, I could be totally wrong, and connections might actually be distributed 1:1 between the modems and it’s an absolute coincidence that heavy traffic connections all go to the Online modem, so maybe you can let me know how you confirmed how many connections are active on each modem to conclude they are balanced, as the WEB UI only shows protocol connections, not connections/modem. Is there a console command that can reveal the number of connections on each modem interface? Can you please provide it to me so I can troubleshoot further?
Thank you again for your support!
The speedtest likely used only one connection, and thus, only one interface was used.
Please, try the following test with multiple connections:
Access the device via CLI/SSH (username ‘root’) and execute the following commands to install iperf3 package:
opkg install iperf3
Then, have a webUI of RUTX12 opened on the Network → WAN page where you can see transmitted (TX) and received (RX) data on both interfaces. Take notes of the current TX/RX values.
Then, in the CLI window run the tests:
# run a speedtest with 8 connections (TX should increase on both interfaces in WebUI)
iperf3 -c <iperf3_server> -P 8
# run a reverse speedtest with 8 connections (RX should increase)
iperf3 -c <iperf3_server> -P 8 -R
You can find a list of public iperf3 servers here.
Please, keep me updated on the results.
I confirm the connections should be load balanced between the 2 interfaces even if one of the interfaces appears as in Standby, as the traffic per interface is now similar, after testing some high traffic connections client side.
The reason for the traffic not looking balanced before was because of my wireguard connection persisting on the same modem, and that is most of my traffic in a normal day.
Thank you for your support and I hope the visual bug showing an load balanced interface as Standby will be solved in the next firmware updates.
Glad to hear that it is actually working properly in your case. Thank you for testing this.
As mentioned, the visual issue should be addressed in upcoming firmware updates, and apologies for the inconvenience this have caused you.
This topic was automatically closed after 15 days. New replies are no longer allowed.