RT-AC88U Dual WAN -- Is it still "experimental"?

[Fizix]

I have an RT-AC88U with a VDSL ISP (primary on WAN) and a cable ISP (secondary on ethernet 1) connection in failover mode.

I have found that it does not seem to switch properly and seems to give up after some time on keeping the lease active on the standby WAN. Here are different scenarios I have tried:

• Ping watchdog NOT enabled and failback enabled:
  • Remove data line to VDSL gateway - Nothing happens since there is an active ethernet connection it assumes the connection is good.
  • Remove the VSDL gateway ethernet line to the RT-AC88U - It will attempt to failover to the cable modem, but more than half of the time it will not connect correctly with the result that there is no Internet connection. After failing to connect it will show lease - "renewing" but never does even with a cable modem reboot.

• Ping watchdog to 8.8.8.8 enabled and failback NOT enabled (both results the same):
  • Remove data line to VDSL gateway - It will attempt to failover to the cable modem, but more than half of the time it will not connect correctly with the result that there is no Internet connection.After failing it will show lease - "renewing" but never does even with a cable modem reboot.
  • Remove the VSDL gateway ethernet line to the RT-AC88U - It will attempt to failover to the cable modem, but more than half of the time it will not connect correctly with the result that there is no Internet connection.After failing it will show lease - "renewing" but never does even with a cable modem reboot.

• Ping watchdog to 8.8.8.8 enabled and failback enabled:
  • Remove data line to VDSL gateway - It will attempt to failover to the cable modem, then seems to see that there is an active ethernet connection to the gateway and attempts to switch back. I would have expected it to try pinging 8.8.8.8 before attempting to failback. The result is that it keeps connecting and disconnecting both. Eventually the secondary stops connecting.
  • Remove the VSDL gateway ethernet line to the RT-AC88U - It will attempt to failover to the cable modem, but more than half of the time it will not connect correctly with the result that there is no Internet connection. After failing it simply shows lease - "renewing" but never does even with a cable modem reboot.

I was able to get the secondary WAN connection to the cable modem to get a new lease by going to the WAN setting (not DUAL WAN tab) and selecting "ETHERNET 1", disable WAN + apply then enable WAN + apply.
This seemed to get the router to play nice with the cable modem again. I know the cable modem was OK because I could connect my laptop directly and connect. I did not reboot the router between that point and getting the lease with the method just outlined which got a "new lease on life".

So I ask, "Is Dual-WAN still considered 'experimental'?"!

I am not wanting anything fancy other than if the primary goes down it switches to the secondary. Failback would be nice, but it would be simple enough to reboot the router after seeing that the primary is back on line, but even this seems to be dubious.

Last regarding failback enabled with ping watchdog enabled -- it appears to me that when the ping watchdog is enabled it is only ping checking to see if the connection has gone down, but is not ping checking to see if it is back up, rather it simply sees that there is an active ethernet connection and attempts to reconnect, then starts ping checking and disconnects again -- rinse and repeat.

Fizix

 

[Fizix]

A quick follow-up.

I seem to have gotten fail-over to work fairly consistently now. I set up ping to 8.8.8.8, but not fail-back.

When I hard boot the router I have to go to the secondary WAN (Charter on Ethernet 1). I have it set to normal on DHCP, but during boot it seems to behave as if aggressive is on, so I have to disable WAN and re-enable to get it to get lease information. Once done it seems to hang on to and renew the lease information.

It has properly failed-over twice now. I have to reboot when I notice that the primary has come back up to go back to primary.

If I enable fail-back, it will automatically try to switch back before the Gateway to ISP link is back up (i.e. it simply sees an ethernet connection to the Gateway and tries to switch back and then of course fails again because it can't ping 8.8.8.8.)

***** MY QUESTION: Is there some setting I am missing that will get the fail-back to work correctly? *****

 

[Fizix]

Echo ... echo ... echo ... echo ... echo

I was hoping for input from the community on this.

I have noticed that on the secondary WAN connection (in this case over Ethernet 1) that during boot it does not appear to respect the "normal" vs "aggressive" so that my Charter ISP as secondary does not connect. This is where disabling and then re-enabling the WAN connects properly.

Is there any way to add a script to do this automatically at the end of a hard boot cycle?

 

[Wildcatz_1]

@Fizix wanted to reply when I saw your post as I too am seeing the same thing. Using other ISP's like Comcast & TWC see the same issue. I am noticing that regardless of setting (look for 40 seconds before failing over, wait for 40 before failing back etc) that a) the AC88u seems to jump the gun and 'want' to hit the secondary/fail over service then even with fail back selected it just sits on the secondary and most of the time (not all) does not fail back. This leaves the primary in a state of disconnect but also for some reason leaves it in a 'renewing' state with regards to IP from the ISP. In other words, in my experience I then have to turn off dual WAN, go back to primary in the UI, toggle off and on Internet on the primary and then I get reconnected almost instantly.

I did some testing over the past few days and sure enough it was jumping to the secondary like crazy and not coming back. So much so that I was ready to point the finger at the ISPs. However when looking at the ISP modem logs, apart from a few errors here and there (T3 ranging etc) all was clean.

So, in conclusion I think there is an issue (seems to be more prevalent since the last FW release IMO) with the Dual WAN support on the AC88u/AC3100 and really hope this is addressed quickly with the next FW release.

 

[bodean]

@Fizix wanted to reply when I saw your post as I too am seeing the same thing. Using other ISP's like Comcast & TWC see the same issue. I am noticing that regardless of setting (look for 40 seconds before failing over, wait for 40 before failing back etc) that a) the AC88u seems to jump the gun and 'want' to hit the secondary/fail over service then even with fail back selected it just sits on the secondary and most of the time (not all) does not fail back. This leaves the primary in a state of disconnect but also for some reason leaves it in a 'renewing' state with regards to IP from the ISP. In other words, in my experience I then have to turn off dual WAN, go back to primary in the UI, toggle off and on Internet on the primary and then I get reconnected almost instantly.

I did some testing over the past few days and sure enough it was jumping to the secondary like crazy and not coming back. So much so that I was ready to point the finger at the ISPs. However when looking at the ISP modem logs, apart from a few errors here and there (T3 ranging etc) all was clean.

So, in conclusion I think there is an issue (seems to be more prevalent since the last FW release IMO) with the Dual WAN support on the AC88u/AC3100 and really hope this is addressed quickly with the next FW release.

Given every other ASUS router has had a FW update in the Month of may, one may be right around the corner, so we will see. 3.0.0.4.380.3264 is floating around new on the other ASUS routers....any day now for this one I would assume. Maybe today?

 

[Wildcatz_1]

@bodean, agreed and that would be fantastic. Love the option of Dual WAN for fail over/back but needs to work otherwise become a pain in the ___

 

[RMerlin]

Personally, I expect most, if not all Asus routers will receive a FW upgrade before June 2nd.

 

[bodean]

Personally, I expect most, if not all Asus routers will receive a FW upgrade before June 2nd.

Probably right.

 

[Pene]

A quick follow-up.

I seem to have gotten fail-over to work fairly consistently now. I set up ping to 8.8.8.8, but not fail-back.

When I hard boot the router I have to go to the secondary WAN (Charter on Ethernet 1). I have it set to normal on DHCP, but during boot it seems to behave as if aggressive is on, so I have to disable WAN and re-enable to get it to get lease information. Once done it seems to hang on to and renew the lease information.

It has properly failed-over twice now. I have to reboot when I notice that the primary has come back up to go back to primary.

If I enable fail-back, it will automatically try to switch back before the Gateway to ISP link is back up (i.e. it simply sees an ethernet connection to the Gateway and tries to switch back and then of course fails again because it can't ping 8.8.8.8.)

***** MY QUESTION: Is there some setting I am missing that will get the fail-back to work correctly? *****

pre note: my dual wan hardware is an rt-ac87u with latest stable merlin fw.

however I missed this whole thread (except the opening comment), I did the same today. set up the main line on wan (fix ip, fix dns and so on) and the backup line on the 3rd ethernet (dhcp ip and auto dns). set up to ping 8.8.8.8, failover mode without failback. after 10 sec (10 repeatedly error with 1 sec time on the main line), it switches to the backup line. plug the cable back and pulling out the backup it switches back to main. and so on. it works quite well.

however it seems to behave a bit odd: if I restart the router, the backup line will be online (and the main as a standby). and another oddity: sometimes the backup line do not get an ip (as you described above). a router restart solves this (did not try to restart wan only), so I set up a nightly daily restart 4am.

so I think for me a good solution can be to bind the dual wan router's mac a static ip on the backup (the dhcp) line/modem, and then it will prevent to set up the backup link as the active connection when the router (re)starts. or maybe to set the DHCP query frequency to normal. i will post my experience in a few days.

 

[Fizix]

@RMerlin

Thanks for jumping in‼

That will be good news if it addresses some of the Dual-WAN issues that not a few are experiencing. My primary beef is that they advertise it as a feature, but seems to be only partially baked. I find it a bit misleading to list it as a feature then say "Oh it is experimental".

Don't get me wrong, I am a big ASUS fanboy - the last 6 gaming machines that I have built are ASUS motherboards. The last 3 are allocated as Crosshair I - kids machine, Crosshair IV - wife's machine, Rampage V Extreme - my machine. Earlier machines have been cascaded to extended family .

@Pene

Thank you for the reply!

The main scenario I don't see in your testing is what if the primary fails, then comes back on line, but the secondary is also still working fine.

This is where I run into problems. If fail-back is not on it continues with the secondary, but in my case the secondary is only 15/2 whereas the primary is 45/6 (i.e. 3x faster down and up). I want it to switch back.

If fail-back is on, even with ping watchdog enabled if it sees that the primary has a good ethernet connection to the gateway (notice I did not say that it is actually connected to the internet), it tries to fail-back anyway, then promptly starts checking the ping watchdog again and sees that it cannot and starts the fail-over/fail-back cycle over again - rinse and repeat ad nauseam.

 

[RMerlin]

That will be good news if it addresses some of the Dual-WAN issues that not a few are experiencing. My primary beef is that they advertise it as a feature, but seems to be only partially baked. I find it a bit misleading to list it as a feature then say "Oh it is experimental".

Dual WAN is something I see them still work on almost in every new firmware release. So, they are aware of issues, and are working on it.

Dual WAN isn't as easy to implement as it might appear, especially not in a router firmware that has so many custom features, has to deal with a large variety of WAN setups, from the basic DHCP to the downward "imaginative" VPN + DHCP method used by Russia's Beeline.

 

[Pene]

@Fizix I think this script worth the time to take a look on it and maybe to modify: http://www.snbforums.com/threads/rt-ac66u-3g-4g-backup-mode-issue.11228/#post-76054
I think it is not a big deal to change the script to schedule a one time reboot 5 mins later after the check shows that the main line is ready again.

Yes, you are right, I do not worry if we stay on the secondary line. There is no real difference between our 500/30 and 50/50. Not to mention that I think the time while the router changes between the wans or any other problems that can occur meanwhile is way too much. (However it seems the nightly restart doesn't solve the problem, as the secondary line comes up first )

 

[Pene]

Personally, I expect most, if not all Asus routers will receive a FW upgrade before June 2nd.

Meanwhile I'm amongst thoose who have to thank a lot for you and I wouldn't like to be greedy: do you have any time window/plan how long does it take for you to implement the possible ASUS dual wan changes to your fw version?

 

[RMerlin]

Meanwhile I'm amongst thoose who have to thank a lot for you and I wouldn't like to be greedy: do you have any time window/plan how long does it take for you to implement the possible ASUS dual wan changes to your fw version?

Changes are part of the GPL releases, so they happen whenever I merge a new GPL. I can never predict ahead of time as it depends on when Asus releases the GPL, whether they release all the required models at once or not, and how complex a merge turns out to be.

380.59 is currently based on 380_2697, so it has any change Asus made up to that specific version.

 

[Fizix]

@RMerlin

Dual WAN isn't as easy to implement as it might appear, especially not in a router firmware that has so many custom features, has to deal with a large variety of WAN setups, from the basic DHCP to the downward "imaginative" VPN + DHCP method used by Russia's Beeline.

I agree with you Merlin, just wish ASUS would wait until it is more robust before making a claim.

I do look forward to seeing if they have made any improvements in DUAL WAN when the next firmware is available.

@Pene

I will take a look at the script you mentioned. Thanks for providing the link.

P.S. Did you mean 50/30 instead of 500/30? Or did you mean 500/50 intead of 50/50?

 

[Pene]

P.S. Did you mean 50/30 instead of 500/30? Or did you mean 500/50 intead of 50/50?

nope, both correct. we are not using the full up on our main line.

update on the topic: after one whole week, our setup looks stable in production environment. there were some connection downs, which were successfully managed by the router. So by now, the next turn is to set up a static ip to the (now dhcp-dynamic) main line and test if. if it comes up as first, we are almost ok if not, the next step will be to give a try to the above mentioned script.

 

[Fizix]

I see that the new version is now available (as of last Friday [5-27-2016] or so). However, I am hesitant to make the jump until a few more have tried it, since it crosses the "can't go back" firmware boundary.

I will try it after more peeps report in on the stability of the firmware.

I did not see any specific notes about DUAL WAN as such, but a few items that affect it.

 

[VANT]

I have same issue on my 87u (when primary wan is back router is still on secondary wan) with latest fw based on 380 branch. On branch 378 dual wan work quite ok and no problems with fail back.
I have PPPoE primary wan. Some guys say that this work ok with dhcp wan. ???

 

[Pene]

After two weeks, I have to say: the only chance to solve my problem is to switch the connections. Until now, my primary line was on the WAN port and the secondary line was on ETH4 (and the secondary wrongly came up as connected, however the primary is on standby mode). Now, my primary line is on ETH4 and the secondary is on WAN, and AGAIN the secondary comes up first (both have static IPs by now). In this week I'll do some tests with ETH3 and ETH4 ports, however I think the admin surface can be wrong or the primary/secondary labels/html divs are mistakenly swapped. @RMerlin is it possible? Or if I'm wrong, the reasons are in deeper region (fw? hardware?).