Weighted, but not balanced

These two WAN connections are identical connections to the same ISP. I have them set up identically as weighted balance both with a setting of 10.

The traffic patterns always look like this. Should I not expect it to look, um, more balanced?

Do you have a http persistence outbound policy set? Is it just a single firewall appliance (or PC) on the LAN of the Peplink or are there lots of user devices?

I do have https persistence set (but not http). There are about 100 devices on the LAN.

Ok great and is the persistence mode set to “by source” or " By destination"?
image

1 Like

Change your weights to 1:1 instead of 10:10. You would have to have 11 concurrent connections before you see any traffic on the second link.

I use a persistence by source for tcp 443, and 1:1 weights for tcp port 80. Everything else goes through least used (make sure you have real world upload and download capacity defined for the WAN).

Beyond that, breaking things up by user also works well. Husband devices priority to link A and wife devices priority on link B, etc. That provides “dedicated” links for your primary devices while still providing redundancy.

Hope this helps and happy balancing. For what it is worth - I asked the exact same question about 5 years ago.

2 Likes

Persistence is set to “by source”

Thanks Jmjones -I will try your advice today.

Interesting observation. One would think that 1:1 and 10:10 would yield the same result given the ratio is the same. Here’s a case where some documentation would be … uhhh … useful.

Maybe someone from Peplink would care to comment?

1 Like

weighted balance at 1:1 did the trick for me - thanks for the tip jmjones.

1 Like

My hunch is that the outcome of 10:10 and 1:1 would be identical as the number of sessions increases. I think it is actually better the way that Peplink has implemented it - although it is far less intuitive this way.

As I say that, I do struggle to come up with a workflow where 10:10 would be preferred over 1:1. It makes sense on an inbound rule where you would want to control how many connections go to a single server. But, there seems to be less use for it when it is for outbound traffic.

The best I can come up with for client side stuff would be to maybe control something like DNS queries. “I want the first 10 queries to go to DNS on WAN1, and then the next 10 to go to DNS on WAN2” – no single ISP can tell all of my queries. I am sure there are millions of workflows where this difference in implementation would be useful, I am just struggling to think of one right now.

Another question regarding the weighted balance algorithm is whether it is only counting “Active” connections. How does it scavenge the closed connections? i.e. using the 10:10 (A:B) ratio. First 10 sessions are established, and then 2 close - leaving 8 total “active” sessions. 2 new sessions open - are the new sessions routed to A or B? If the 2 closed connections are scavenged, then the 2 new sessions would open on A. If they are not, and the counters are just rolling counters - -the new sessions would go to B. I would think that the scavenging method would be most useful. “I only want B to be active only if there are more than 10 concurrent sessions”

Interesting comments. I think it would be good to hear from one of Peplink’s technical folks on this – including your questions.

From a programming perspective, it would be way easier to implement the rolling counters as opposed to taking connection states into consideration. In fact, I would venture to say that it wouldn’t scale very well to keep track of the connection status. Imagine a weighted balance of 10000:1000 and having to enumerate the state of 10,000 connections to make a routing decision. It almost has to be static counters that get incremented with each new session and when one of them goes over the max - the counter resets to 0 and traffic is routed to the other side until that counter rolls past the max.

Another argument to why it would almost certainly be a static count would be that unless Peplink is keeping track of what routing rule landed a connection on a particular link - it wouldn’t be able to properly count connections as some of the connections could have been routed by a different rule entirely.

Of course, it is easy enough to create that exact scenario and determine exactly what it is doing…

1 Like