This is the second article for configuring load-balancing on EdgeOS. In this article, I’ll go into more in-depth configurations that I’ve found useful having run a load-balanced configuration for quite a while.
Configurations
Warnings
In my original article, I share a list of things that break when you implementing load-balancing on EdgeOS. You should have a look at these items and make an evaluation on the usefulness of this configuration based on what I share.
Change Default Route-Test Behavior
Background
By default, EdgeOS will ping your default gateway to determine the availability of a given WAN interface. This sounds good hypothetically but, in practice, doesn’t work as well. Doing this doesn’t protect against the scenario of an upstream failure within the provider’s network (which, with Comcast, is a common problem). Instead, we want to pick a public destination that indicates that we’re ready for “common service” and test this.
Implementation
Here are the configuration sections we’re going to add for each WAN interface:
set load-balance group G interface eth0 route-test type ping target 8.8.8.8
set load-balance group G interface eth0 route-test count failure 2
set load-balance group G interface eth0 route-test count success 2
set load-balance group G interface eth0 route-test initial-delay 10
set load-balance group G interface eth0 route-test interval 10
set load-balance group G interface eth2 route-test type ping target 1.1.1.1
set load-balance group G interface eth2 route-test count failure 2
set load-balance group G interface eth2 route-test count success 2
set load-balance group G interface eth2 route-test initial-delay 10
set load-balance group G interface eth2 route-test interval 10
Let’s walk through each of these with an explanation:
set load-balance group G interface <interface> route-test type ping target <address>- We’re going to use a ping against the specified address instead of the default gateway.
set load-balance group G interface <interface> route-test count [failure|success] 2- We want to wait for two failures or two successes before we decide an interface is unavailable.
set load-balance group G interface <interface> route-test initial-delay 10- Wait 10 seconds before we actually decide there is a failure with this. This helps prevent false-positives on a media reset for devices that might take a moment to initialize even after the media is up.
set load-balance group G interface <interface> route-test interval 10- Run our ping test every 10 seconds. We’re hitting public websites so we need to be considerate here.
Change Connection Weights (Optional)
Background
If you have imbalanced connections like I do, you’ll want to consider adjusting the weight of your load-balancing configuration. Here are my download speeds:
- Comcast - 200Mbps down
- AT&T - 50Mbps down
For me, the calculation of weight considers two factors:
- Download speed of the connection
- The reliability of the connection (primarily because of work)
Because the AT&T connection is so much slower than Comcast, I really don’t want to overly favor this (giving equal weight, for example). Instead, I split them based on speed initially (so 75% for Comcast, 25% for AT&T) and then consider that Comcast seems to go down at literally the most inopportune times. This results in 70% to Comcast, 30% to AT&T though I could probably stand to research this further.
Implementation
Here’s how you practically implement the weights:
set load-balance group G interface <interface> weight <weight>
The weight above is specified as an integer representing the percentage (so 70 or 30 respectively for my two connections).
Summary
You have now completed your load-balancing configuration and the additional configuration I recommend. As mentioned in the Things That Break section in part 1, from here things become more complicated in general for how to accomplish various configurations. I fully intend to document my configurations further as I explore these challenges and learn how to properly overcome them. Thanks for your time!