Balancing traffic in Mikrotik between two WAN interfaces with regard to incoming traffic
Recently decided to try to implement a simple balancing of traffic between multiple WANs. Why just simple? I am too hard to understand large amounts of information, and I suspect not one. Therefore, I decided to try to develop a scheme in which even a novice will understand, since it is not enough to use other people's work, you need to know what you are doing and why.
Immediately I warn you - the system has many flaws, for example, it is possible to access the same resource from different IP, which is fraught with authorization. So it is best to use it for connections that are not sensitive to the source address, for example, to the same torrents.
And yet, I will not describe the Mikrotik setting from scratch, it is assumed that you already have a router with two VANs, which already have IP addresses, and the local ports are also configured. And that the user is more or less oriented in microtics, at least at the level of what the menu item knows somewhere.
For absolutely newbies and people poorly versed in networks (you can be a master in one and a beginner in another, I don’t see anything unusual in that) I posted a couple of spoilers
So. Conventionally, we assume that:
- we have local addresses in the range 192.168.0.0/16 and are connected to the bridge Localca
- Provider1 is sitting on our WAN1 interface, with gateway 10.0.0.1
- Provider2 sits on our WAN2 interface, with gateway 172.16.25.1
')
So let's get started.
First of all, create new routes:
Do not worry if it duplicates existing dynamic (or created by you) routes. All the salt in the routing marks. All routes with a routing mark are a separate routing table, and other tables cannot use the packages going through it, so you need to register the path to the local addresses too. In theory, when there is no address in the desired table, the packets can look at the default (not labeled) routing table. But I have had cases when this principle did not work, so it is better to be safe
We will create a mangle that will send all new connections to the desired gateway:
The first rule catches all unmarked (and therefore new) connections that do not go to our LAN, and therefore go through the WAN interface, and label them with the desired label. I chose this approach, since we have several VAN interfaces, and each would have to create a separate rule with the required Out. Interface, and so we are limited to one rule. The second rule for connections with the desired label assigns a mark of routing. Comment serves us so that we can find this rule as a script.
The next item we go to System-Scripts and create a new script for the following content:
First, we reset the variables, then we get into these variable data about the load on the interfaces (and specifically the number of bits received per second, for which the rx-bits-per-second parameter is responsible). Next in the variables one and two we enter the width of each Internet channel in bits, and we get the opposite (since the microtic does not show fractional often, then dividing the number of bits by width we would get 0) relative load (divide the width by load in bits). And then we compare them, and if the number is greater than the first VAN, then in our mangle (here the comment was useful, we turned to the necessary mangla on it) we enter the routemark for VAN1, otherwise VAN2.
Now the matter is small - to set the frequency of execution of the script. Go to the System-Sheduler and add a new task with the desired execution interval, in the field on Event: enter
Where erazel_balancing is the name of the script in which we change the mangle. Do not forget to change the name of your script.
Now we have a fully automatic load balancing system for external interfaces, depending on their relative workload.
Well, there remains the question of accessing the server from various external addresses. So I would advise this approach to be used for torrents and other non-critical applications. Just in the first mangle (which marks the connection points) to make another condition on the protocol and the port, and to duplicate it for different protocols / ports. For example:
Immediately I warn you - the system has many flaws, for example, it is possible to access the same resource from different IP, which is fraught with authorization. So it is best to use it for connections that are not sensitive to the source address, for example, to the same torrents.
And yet, I will not describe the Mikrotik setting from scratch, it is assumed that you already have a router with two VANs, which already have IP addresses, and the local ports are also configured. And that the user is more or less oriented in microtics, at least at the level of what the menu item knows somewhere.
For absolutely newbies and people poorly versed in networks (you can be a master in one and a beginner in another, I don’t see anything unusual in that) I posted a couple of spoilers
So. Conventionally, we assume that:
- we have local addresses in the range 192.168.0.0/16 and are connected to the bridge Localca
- Provider1 is sitting on our WAN1 interface, with gateway 10.0.0.1
- Provider2 sits on our WAN2 interface, with gateway 172.16.25.1
')
So let's get started.
First of all, create new routes:
/ip route add disabled=no distance=1 dst-address=192.168.0.0/16 gateway=Localca routing-mark=isp2 scope=30 target-scope=10 add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=172.16.25.1 routing-mark=isp2 scope=30 target-scope=10 add disabled=no distance=1 dst-address=192.168.0.0/16 gateway=Localca routing-mark=isp1 scope=30 target-scope=10 add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.0.0.1 routing-mark=isp1 scope=30 target-scope=10 What are the routes, they are the same routes
Routes are an indication of the router on which port or for which IP address to search for the desired subnet. Without this, the router will not know where to send the packets. That's why we specified not only Internet gateways, but also the port where our local addresses are located
Do not worry if it duplicates existing dynamic (or created by you) routes. All the salt in the routing marks. All routes with a routing mark are a separate routing table, and other tables cannot use the packages going through it, so you need to register the path to the local addresses too. In theory, when there is no address in the desired table, the packets can look at the default (not labeled) routing table. But I have had cases when this principle did not work, so it is better to be safe
We will create a mangle that will send all new connections to the desired gateway:
/ip firewall mangle add action=mark-connection chain=prerouting connection-mark=no-mark disabled=no dst-address=!192.168.0.0/16 new-connection-mark=inet_con passthrough=yes add action=mark-routing chain=prerouting comment=multiwan connection-mark=inet_con disabled=no new-routing-mark=isp2 passthrough=no The first rule catches all unmarked (and therefore new) connections that do not go to our LAN, and therefore go through the WAN interface, and label them with the desired label. I chose this approach, since we have several VAN interfaces, and each would have to create a separate rule with the required Out. Interface, and so we are limited to one rule. The second rule for connections with the desired label assigns a mark of routing. Comment serves us so that we can find this rule as a script.
mark-routing, what is it for
The routing mark is used to specify the routing table for the selected packets / connections. They will use only those routes that carry the corresponding Routing Mark. By this method, we can send different traffic to different gateways / ports according to the conditions we need. All that is to the left of the Action tab in mangles (and in the filter and NAT) is a filter. So the less we specify the criteria, the wider will be the coverage of traffic falling under this rule. Accordingly, by combining different conditions, we can very accurately separate the traffic we need.
The next item we go to System-Scripts and create a new script for the following content:
:global rx1 "0" :global rx2 "0" /interface monitor WAN1 once do={ :global rx1 $("rx-bits-per-second"); } /interface monitor WAN2 once do={ :global rx2 $("rx-bits-per-second"); } :local one 20000000 :local two 8000000 :global wan1 ($one / $rx1) :global wan2 ($two / $rx2) if ($wan1>$wan2) do={/ip firewall mangle set [find comment=multiwan] new-routing-mark=isp1} else={/ip firewall mangle set [find comment=multiwan] new-routing-mark=isp2} First, we reset the variables, then we get into these variable data about the load on the interfaces (and specifically the number of bits received per second, for which the rx-bits-per-second parameter is responsible). Next in the variables one and two we enter the width of each Internet channel in bits, and we get the opposite (since the microtic does not show fractional often, then dividing the number of bits by width we would get 0) relative load (divide the width by load in bits). And then we compare them, and if the number is greater than the first VAN, then in our mangle (here the comment was useful, we turned to the necessary mangla on it) we enter the routemark for VAN1, otherwise VAN2.
Now the matter is small - to set the frequency of execution of the script. Go to the System-Sheduler and add a new task with the desired execution interval, in the field on Event: enter
/system script run erazel_balancing Where erazel_balancing is the name of the script in which we change the mangle. Do not forget to change the name of your script.
Now we have a fully automatic load balancing system for external interfaces, depending on their relative workload.
Well, there remains the question of accessing the server from various external addresses. So I would advise this approach to be used for torrents and other non-critical applications. Just in the first mangle (which marks the connection points) to make another condition on the protocol and the port, and to duplicate it for different protocols / ports. For example:
add action=mark-connection chain=prerouting connection-mark=no-mark disabled=yes dst-address=!192.168.0.0/16 new-connection-mark=inet_con passthrough=yes protocol=tcp src-port=45000 Source: https://habr.com/ru/post/190352/
All Articles