What's new

Asus Dual-WAN >> Load-balancing with fail-over?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

b cheang

Occasional Visitor
Hi,

I have RT-AC86U on latest merlin FW 384.7. At the same time i have 2 x 1Gpbs connection from 2 diff ISPs.

I have configured load-balancing ratio of 1:1 but when primary WAN goes down and come back up again, it seems all traffic still goes via secondary WAN (ETH 4).

Does anyone faced the similar issues?

If I configured them in fail-over mode, they worked perfectly OK as watchdog function sends pings to www.google.com

Appreciate any advices.
 
@b cheang, @peraburek suggested
try this out in load balancing mode
https://pastebin.com/iDRDjaGV
this script is doing almost everything you could need
Ahem o_O, whilst the script can assist in identifying if a specific WAN interface is UP or DOWN (and initiate either a WAN restart or router reboot), in your situation it will only be useful when included in a script that monitors/manages the switch between Dual-WAN interfaces.
I have RT-AC86U on latest merlin FW 384.7.
I have 2 x 1Gpbs connection from 2 diff ISPs.

I have configured load-balancing ratio of 1:1 but when primary WAN goes down and come back up again, it seems all traffic still goes via secondary WAN (ETH 4).
How do you determine that the recovered Primary WAN (WAN0) interface is not used and all traffic is still via the Secondary WAN1 (eth4)?
Did you examine the RPDB/routing rules (before the enforced switch from WAN0 -> WAN1) and after?
Code:
ip rule

ip route show table 100

ip route show table 200
Also examine/interprete the iptables 'statistic' rules in the Balance chain
Code:
iptables --line -t mangle -nvL

Chain balance (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      482 33248 RETURN     all  --  *      *       0.0.0.0/0            192.168.1.0/24
2        0     0 RETURN     all  --  *      *       0.0.0.0/0            192.168.0.0/24
3        0     0 RETURN     all  --  *      *       0.0.0.0/0            10.64.64.64
4       50  2589 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443
6        8 11024 RETURN     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:443
7        0     0 RETURN     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:80
8      391 90230 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match  0x80000000/0x80000000
9        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
10      96 12889 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.75000000000 CONNMARK xset 0x80000000/0xf0000000
11      31  3296 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            connmark match  0x0 CONNMARK xset 0x90000000/0xf0000000
should give you a clue (see rules 10 and 11 above) for ratio 3:1

NOTE: To assist diagnostics, it may be easier, to reset the counters to 0 in the Balance chain after the Primary WAN has seemingly recovered?

P.S. The above may not be the same on the RT-AC86U ?
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top