Suggestion for best method on load balancing

[dude1]

I have encountered a hiccup on my plans of 1:1 load balancing 2 isp's on two WG3526-P routers.

I planned to piggyback from router 1 lan to router 2 wan port and then run one ethernet cable to in house switch. Since the Wan port must be used for poe, does this make load balancing by this method null and void?

Would like to keep it simple and avoid buying a dedicated load balancer if possible.

One idea I am currently looking into is getting poe splitters for both routers that will allow me to supply power into the dc port, freeing up the wan ports.

What are the specific power requirements of the dc port on the WG3526-P (is it 12V 2.5 amp exactly?) and is there a recommended splitter with those specs?

My switch does have ability to feed 48V, but this will tie up both wan ports and remove the ability to do load balancing as I understand. Is it possible with rooter to turn one of the other lan ports into a wan port?


Is best method of load balancing 2 WG3526-P routers like this to put the first router in DMZ mode, or is default setup sufficient to avoid ip conflicts?

[danielewood]

Is there a reason for going with 2x WG3526-P instead of using 1x WG3526-P and a USB enclosure for the second modem? ROOter has modem load balancing built in.

As for power requirements:
802.11af does 15.4 watts
802.11at does 30 watts
12v 2.5A is 30 watts.

That all said, I doubt there is any scenario where the WG3526 with two modems and under full load would draw anywhere near 30 watts. The EM7455 under fully saturated 50/300 network load at the highest transmit power averages 3.7V x 1A, or 3.7Watts. So, 802.11af (15.4 watts) might be an issue with two modems and WiFi under load.

If you use this PoE Injector from The Wireless Haven, you will melt the WG3526 long before you run out of power on the PSU side.

[dude1]

Thank you for the input. I was not aware the usb on the WG3526 was capable of hosting another modem. I will purchase the necessary parts and try this route.

[dude1]

New problems have popped up after following the of modems and men load balancing guide. If I plug in the usb modem adapter while the WG3526-P is powered on, the router will pick up the 2nd modem, but after a few minutes the 1st modem will go into a reconnecting loop. (both modems work fine separately)
If the WG3526-P is rebooted, both modems will fail to be detected indefinitely within the router modem page. The symptoms were the same whether on poe power or 12v plug.
Options selected were enable load balance for both modems under connection info section, as well as setting policies and rules verbatim from the of modems and men tutorial page just to attempt a successful simple 1:1 connection.
Has load balancing via this method been successful for anyone? Is there another setting outside of network section I am somehow missing?

[JimHelms]

It may have something to do with the killall issue being discussed on the ROOter forum:

So to be clear, the killall issue affects all current 18.06 and snapshot builds? Or is it just on some routers? I ask because I have a router at an offsite location that I'll be visiting and don't want to install it only to have to revert it before I leave.

My motivation for upgrading to 18.06 is because load balancing / failover doesn't work on the r7800 2018-06-01 snapshot. I have an MC7455 and an ethernet WAN connection (DSL, but obtains IP via DHCP), and I want the MC7455 to be the primary and ethernet as a backup/failover. Both interfaces always show as disabled in MWAN when connected. I can manually enable them (which the guide https://www.ofmodemsandmen.com/loadbalancing.html says not to do), and it works until the MC7455 disconnects and reconnects (due to the Sprint issue where it disconnects twice a day). At that point, the modem interface reverts to disabled again, so everything uses the ethernet interface and it never switches back to the MC7455.

So whatever logic is used to enable interfaces in MWAN when they're active/available doesn't seem to be working on my build, and I was hoping the 18.06 builds have fixed it. Unless I'm missing something?

So to be clear, the killall issue affects all current 18.06 and snapshot builds?

It does.

So whatever logic is used to enable interfaces in MWAN when they're active/available doesn't seem to be working on my build, and I was hoping the 18.06 builds have fixed it. Unless I'm missing something?

You are missing something.

For modems you have to enable the use of Mwan3 in the Modem->Connection Info or Connection Profile to make it stay working. It is a box labeled "Enable Load Balancing at Connection".

It will then enable Mwan3 at connection time and disable it when disconnected automatically.

This was done because people with only a single modem were having problems with Mwan3 harming their connection.

The WWAN and WAN interfaces can be enabled on the Load Balancing page and they will stay enabled always.

Any build of ROOter works this way so any snapshot or 17.01.4 is good.

[dude1]

Thank you for info about the killall issue Jim. I will dig in the rooter forum to see if any solutions are presented. I did try "Enable Load Balancing at Connection" checked on/off for both modems at the time on GoldenOrb_2018-05-24 with 2 mc7455's. One variable that I wanted to make sure was that this was not a power issue. I am fairly certain I can rule that out at this point.

[JimHelms]

You may have to try an older ROOter build.

[dude1]

I have successfully enabled load balancing on build GoldenOrb_2018-07-24 OpenWrt 18.06.0-rc2. I have also encountered a few interesting quirks that don't make any sense. The 2 providers I am load balancing are sprint (calyx) and att (tablet sim). After much troubleshooting, the real solution I found for this was to put the att sim into the router sim port, and the sprint sim into the pcie usb adapter to the router usb port (reboots reliably into load balance setup). If the sims are switched around the router will absolutely not connect one of the modems on bootup(seems random which one) and will fail to load balance every time.
With this rooter build, the modem connection profile was set to custom and it picked up based on sim imsi or iccid. For testing, both 7455 modems set exactly the same. APN is set under custom, so it should match to sim imsi or iccid on bootup (nice new feature) regardless of which sim port either sim is in.

I will shortly be testing an em7565 with one 7455 to see if I can get load balancing working as that is what I hope to have for modems in the final build.

Could any explanation be offered as to why the load balancing fails if the sprint and att sims are swapped around? At least the load balancing works with them set one way, so I can know the rules and policies for the load balance are set properly. Will be testing t-mobile soon as well. It just seems like a very weird issue. Would prefer sims can swap out in both ports for any carrier for redundancy. Could it be related to the sprint open NAT thing?

[dude1]

I also see unsupported protocol type on wan2 when the sims are swapped and fail load balancing.

[JimHelms]

I believe this issue is still related to the "killall" failure which requires a router reboot to restore a modem connection when dropped. I believe Dairyman has corrected the issue for the next round of builds.

It is strange that it works one way and not the other. This could be contributed to AT&T being more stable than Sprint--coupled with the killall issue favoring one interface over the other.

[BillA]

I also see unsupported protocol type on wan2 when the sims are swapped and fail load balancing.

The unsupported protocol is likely due to the connection being lost.
It has been reported by many others, that the Sierra MC7455 modem in particular doesn't play well with Sprint sim's, moreover CDMA/LTE service tends to be more finicky than GSM/LTE (AT&T, Tmobile) during initial network connection/reconnection.
Try swapping out both modems with a Sierra EM7565/7511 or some other brand.
Also the way the router handles internal vs external modems, it could have slightly different setup timings or perhaps glitchy, so a good test would be to attach both modems externally in separate enclosures, to see how the system behaves.
If none of the above suggestions seem to help, then as a last resort you may want to consider replacing the Sprint sim with another carrier.