RV082 Dual WAN - configuration questions

[dondersconsulting]

RV082 configured for Dual WAN

(2) identical DSL connections, configured as Static IP (not PPPoE) with modems in bridged mode.

Static IP's are /25 subnet and same gateway  ** this may be a problem?

Dual WAN set for Load Balance, network service detection is OFF

We have a 2003 terminal server running and successfully receiving connections through both WAN connections.  Depending on location, half the users are connecting to WAN1 IP and the other half to WAN2 IP.  We are getting sporadic disconnects of the remote users when they are idle for a couple minutes and automatic reconnection of the session takes over a minute.  If they close the (locked up) session and reconnect manually it will let them in right away. 

Could the handling of the Dual-WAN be the culprit?   Could the same gateway for both WAN's create this issue upstream (out of my control)?

I am going to move everyone to connecting through WAN1 and then change to Smart Link Backup and see if the issues persist.

Another thought is to use a secondary IP on the terminal server and use Protocol Binding to match "All traffic" for IP1 to WAN1 and IP2 to WAN2, which theoretically would stabilize the situation?

[Tom Watts]

Hi Donder, the gateway shouldn't make a difference. There is not really any way to determine is 1/2 server use one WAN while the other half use the other WAN unless you specifically binded those terminals to a WAN interface. It would be logical to experience disconnects or session timeouts as the source IP of the servers would change therefore dropping the session.

As you said, a good test would be to set as smart link back up. Another good test would be to bind specific LAN IP addresses to one WAN interface for all services and see if that node has problems.

-Tom
Please mark answered for helpful posts

[dondersconsulting]

I think you are missing a point about the Terminal Server - that is for remote connections coming from the WAN side into a single internal server.  I say that I have split the [remote] users between the WAN1 and WAN2 because 1/2 of them connect to the WAN1 Public IP and the other 1/2 connect to the WAN2 Public IP.  The issue may be that the return traffic could get sent down the wrong pipe when an idle connection resumes, or possibly some other side effect of the round-robin.  It does seem to happen more the further away the client is (geographically), so it could be exacerbated by latency.

Otherwise, I think you understood what I was getting at with the troubleshooting steps.  Thanks for confirming.

So far, I did not get any complaints of disconnects this afternoon after switching to load balance (single active WAN) and disabling the WAN2 port as a safeguard.  I will see how it goes in the morning and then if it's "fixed", go back to Load Balance but bind an IP to each WAN and see if that fixes it.

[Tom Watts]

You can also try to increase the time out periods.

https:///f_general_hidden.htm

example:

https://192.168.1.1/f_general_hidden.htm

You may also want to verify WAN MTU.

-Tom
Please mark answered for helpful posts

[dondersconsulting]

I cannot seem to access that hidden page except at another client.  Is that only for v3 hardware (v4 firmware)?

Both WAN's are set to MTU of 1492, which has always worked great with DSL connections - but I suppose I should check with Centurylink about that.  These timeouts are sporadic and only during idle times, so I don't see how MTU would cause that issue.

regardless, my client is still getting the locked screens (timeouts) today, which signals that the issue is not with the Dual WAN, but some other glitch in the router or DSL circuit performance.  I wish I could say that I trusted the DSL connection, but I don't - until recently, it has been capped at 1.5M (rural location).  They just allowed it to be upgraded to 3M, but likely that is beyond its 100% reliable speed.

[Tom Watts]

The DSL just depends how far you are from the DSLAM, obviously the closer the better. Generally speaking if DSL is unreliable it isn't because of the rate provision. The evc-map built will specify the rate even if it is an ATM or ethernet DSL. Most of the time if there is a problem with the DSL it is because the card on the DSLAM needs to be rebooted or because the uplink is over utilized. Depending how rural, a BRAS can even have 40-50k subscribers pumping through it and anywhere from a few hundred to few thousand subscribers on a single interface since they have a tendancy to eel-out.

If your DSL is dropping out, I'd ask the provider to go to the DSLAM and test at the pins and run an OAM ping to see any latency on the path from the BRAS to your CPE. Or, if you've got the option, ask them to cut you to an ethernet instead of ATM connection too.

I never tested the hidden page on a v1/v2 RV0XX but it works for sure on V3 hardware.

-Tom
Please mark answered for helpful posts