Overflow algorithm - How does it works really?

I have set the WAN uplink and downlink limits accordingly, however sometime it looks like the Balance One is ignoring this.
Fore instance one of our connections was experiencing connection issues, so I have lowered the max up and downlink limits, however I have discovered the the Balance One was using all the available bandwidth from that line regardless the limit I had set (the default algorithm is to overflow)
How is that?

Hey ReeX,

I actually use this in a few different scenarios. So we have a Bonded Ethernet circuit SLA 3/3 Mbps for about 40 VoIP phones running on a G.711 codec. Not all phones used at one time but we use this circuit because its more stable than the backup cable circuit.

From my knowledge, when the bandwidth hits 90% of utilization assuming you have your WAN interface shaping accurate then it will fail over traffic to the next WAN connection that you have chosen. Then when it crosses back over the other way of the 90% threshold it reverts traffic back to your primary.

I could be wrong about how it reverts back but this is my understanding and how I personally use in real life scenario.

PS: I would keep on latest stable firmware and when you shape your WAN port on your Balance, give it a hard reset.

Thanks,

TJ

1 Like

Thanks TJ, but I don’t understand one thing:

  • WAN1 is a 4/4 line, however as for some issues the line wouldn’t allow speed higher than 2,5Mb/s, I have lowered line max speed to 2500/2500 in the WAN1 config.

    Once the issue was fixed by the ISP, the line could reach again 4Mbs, however the Balance One did not obey the limit imposed in the configuration (2,5mbs) as I could clearly see from the graphs that Balance One was allowing full 4Mbs usage. Shouldn’t the Balance One overflow as traffic was exceeding the 2500kbps limit set in the WAN1 config?

Yea, I know exactly what your saying. I think a Peplink team member would need to jump in on that particular issue. I would also check for any duplex mismatches as well as run a few packet captures to analyze from the back page.

MANGA/support.cgi

Thanks,

TJ

1 Like

Just a guess, but I suppose that the sessions (connections) already allocated to WAN1 before it reached 2500 kbps, could “grow” to consume the full 4Mbps. In that case there was no misallocation.

You mean that only new connections would be overflowed to next WAN once the
limit was reached?

Yes. Except for the feature where it can be configured to terminate sessions, when WAN1 is “back up”. Not sure if that is only available for “HTTPS Persistence” though.

Personally I have a much bigger problem with NOT getting new (download) sessions on WAN2 if WAN1 upload is saturated (because it is an ADSL there is no download, if all upload is being used). I asked about that in a separate thread.

Thanks Dennis your explanation makes sense.

Dennis, how do you set your upper limit?

I have the capacities of the WAN connections set under each WAN connection. Actually set quite a bit low for both upload and download. Something like 70% of nominal capacity.

I thought about that! Because recently I was noticing that often two or
more users where trapped into the main WAN instead of overflowing, and I
was suspecting that it could be due to the fact that the closer the
limit to the actual max-bandwidth and less chances are that users will
overflow. For example we are using an amazing professional grade SHDSL 4/4

  • a consumer grade LTE 45/45 + a poor quality sat 16/16.

The 4Mb/s line doesn’t reach more than 3900Kbps so I’ve set the cap to
3800, but it would overflow only when a user is flooding traffic (rare).
Today I have lowered the limit ti 3700kbps and it seems overflowing more
often than before, but I may lower this more, according to your input.

30% of 3900 would be about 2700kbps…

Your thoughts?

Yes, I think it is more or less a matter of statistics. A single session with a fast server would be able to saturate the 4 mbit/s, so even a single session can be limited.

My roughly 70% are more or less picked by random by me.