PCC with “both addresses and ports” I used many times works like a charm but breaks https connections.
Then I included !port443 into pcc rules but, since almost all traffic today is https, this mechanism is deprecated.
What is nowadays the best load balancing/aggregation method to share multiple wan with many LAN users, but also allow a single user to benefit of multiple wan bandwidth aggregation ?
Be aware: PCC is not true load balancing (but given the nature of normal traffic, it will approach it and use all connections as much as possible).
It is connection sharing over multiple ISP connections.
But it is perfectly possible that 1 connection uses 10Mbps, the second one uses 100Mbps.
No load balancing. However connections are perfectly distributed.
PCC does not break HTTPS traffic. So more information is needed to see where you made the mistake. I assume you forget to filter out just marked traffic (connection-mark=nomark) from being marked again by the PCC rules. Also, mark new traffic (connection-state=new). If not, the subsequent traffic is being connection marked again and that could be a different connection mark.
I use only src-address as the selector and it works fine for any protocol and scenario, except of course that it does not distribute the load from one user over different internet connections (so the user always only gets the speed of the internet connection that happens to be assigned to them).
i think you are wishing 2 opposite things at the same time
PCC does not breaks https connections perse
the situation is the following, sometimes when you access a site, platform or service is not a single server involved, there are several through it, so there are multiple destination ip addresses involved, because of that only src-address its safe to use to avoid this situation, but off course each individual LAN ip addresses only use one service provider
this works ok to balance traffic when you have many users but not when you have few
as almost always in life there are some trade-offs between things
Well , actually “both addresses and ports” breaks https because the same user points to wanted https server by multiple ip addresses sources (our wans) and it doesn’t like it.
Src-address is safe as just one wan is used by lan user so multiple users traffic can be spread over available wans but no “bandwidth aggregation” per user.
Are there actually other Solutions to achieve both goals ?
No. That has nothing to do with “breaking https”. It may break certain websites. That is however not related to the use of https, but the destination server or a loadbalancer in front of it keeps your “session” bound to your IP address.
First Times, using “both addresses and ports” PCC, as single LAN user, a speed test over three 100Mbps wans always given near 300 Mbps result (this is what I mean by “bandwidth aggregation”), and all lan users were spread over three wan.
I.e. two concurrent users could reach 150Mbps.
Lately, https sites connections start to break, I solved by adding port=!443 , but as said, all is https now and all my PCC rules are ignored.
Now I’m looking to achieve same goals with alternative methods…
Well, “bandwidth aggregation” is a whole different animal than load balancing. It another word for bonding, but the key thing is you need something at the other end to “un-bond” to the internet … and if you connection vary in speed and/or latency, that introduces another level complexity/trade-offs for doing “bandwidth aggregation”.
My thought is if you have a lot of normal web traffic (e.g. http or https) load balancing is often better than any bonding / “bandwidth aggregation” scheme. Reason I say that is bonding WANs adds both overhead and latency (and also complexity, single point-of-failures, difficult with latency/speeds varies, etc.. etc…). Since “a lot” web traffic is graphics/scripts/trackers/REST/etc – all generally pretty small and short requests… So even one person loading a single web page load may actually contain MANY potentially connections that will get distributed. More users you add, the more statistically these web requests will get distributed across the WANs.
It’s when you do NOT have web traffic, like large filetransfers/media streams (or other long duration connections) is where bonding / “bandwidth aggregation” might be useful – since you kinda only have ONE connection in these cases & that where PCC/ECMP isn’t going to help you.
Not when using “source address” only as classifier. Then only 1 connection will be used, over and over again.
“Both addresses” is normally the best option for optimal distribution (and yes, it may cause havoc on some connections but it’s very rare from what I understood).
Well, i’ll give “both addresses” a try as triple-suggested by Holvoetn
My further ask was about some other mechanism other than PCC to achieve load balancing with “easy efficiency”.
When your user is just using a single website at a time, there will not be any speed advantage when using PCC.
Any large downloads are happening over a single connection and that always uses only a single link.
Sure, when you use “both addresses” and the user is one who has many tabs or windows open and starts downloading large files in each of them, you can see an advantage. Not to the speed of a single download, but to the combined speed of 2 or 3 downloads.
In practice, does that ever occur?
I happen to have an environment where I don’t have immediate feedback from my users. I am not hearing “hey this site does not work!” every 5 minutes. I may hear 3 months later via the management that “people have complained that the network is rubbish and they cannot use several sites”.
So in my case I use only src-address as a classifier, that is the safest thing.
When you are using it in another environment (more like a family) you can try other methods and hope that everyone understands what kind of problems can occur and how they report them.
If I would have to guess, I would guess that banking systems are the least likely to have problems. Banking system programmers usually understand proper security. Much more chance that it fails on some low-profile website of a small company.