Mikrotik Dual WAN: Is fault tolerance and balancing possible at the same time?

Question

network hardware

Good afternoon, colleagues! The network has a lot of tutorials on setting up either failover on 2 providers or balancing. Is it possible to combine these two features and set them up at the same time? Two providers give 2 static white IP addresses. If possible - poke, please, into the manual or what to read. Thanks in advance.

Answer 1

Before reading the manual, you need to understand what you want to balance.
You can balance traffic based on three methods or their combinations:
1. balance traffic proportionally. For example, 1:1 or 3:2 (the number of connections to the first WAN and the second, respectively)
I warn you: many services on the Internet do not like (up to a ban) requests from different addresses from a client in one session. Especially banks.
If there are dst-nat, then you will have to pretentiously label the traffic so as not to confuse the input-output.
2. balance based on information from the source (client). For example, dividing the address space of the client network in half or manually using lists or dynamically, analyzing certain query parameters, etc.
If clients are sitting behind a proxy, this will be quite difficult to do.
3. balance based on the purpose of the requests, i.e. share internet. Here, in general, the virgin land is not plowed opportunities. By the way, this is the main way to bypass RKN blocking, because I remind you that a VPN connection is also considered an external interface.
After that you can google the implementation.

Answer 2

Tee yes, then so-so: https://www.youtube.com/watch?v=Gwl-0bRxOY4

Answer 3

Everything was detailed by a rainhog colleague . At one time, back on Debian, I did balancing by traffic type. Ie, for example, I sent mail traffic, telephony (based on port ranges) to one provider, sites to another. Everything is great. I repeated the same on RB3011Ui. Practice has shown that the distribution by the number of packets, depending on the "thickness" of the channel, as a colleague also pointed out, is not always good and leads to a strange result. Difficult to recommend.