Mikrotik policy routing implementation example
In “normal” routing, you have a set of routes that tell the router about how to reach certain networks. Policy routing is a way to do the same thing, but have different “paths” or routes for various types of traffic. In this article, we will explore the requirements for setting up policy routing and explain some of the concepts involved.
Policy routing is implemented in 3 parts. The first part is to define the routes and which policies will use those routes. The second part is the routing rules, which will define how the policies apply to certain traffic. The third is to define the actual policies. We’ll look at each of these individually.
The network below is the one we will use for this example.
We will assume that you already have the IP addresses set up on your router.
First, we must define our routes. We will add three “default” routes. These are below:
/ip route
add gateway=10.10.11.1 routing-mark=ISP2
add gateway=10.10.10.1 routing-mark=ISP1
add gateway=10.10.10.1
The first 2 routes will be used by our policies. The third route will be used by any traffic that does not have a policy defined and by traffic from the router itself.
Next, we need to define our routing rules. There are many ways to accomplish this, but what I will show here is the cleanest way I have found to implement a working policy.
/ip route rule
add dst-address=192.168.0.0/24 action=lookup table=main
add dst-address=192.168.1.0/24 action=lookup table=main
add dst-address=10.10.10.0/30 action=lookup table=main
add dst-address=10.10.11.0/30 action=lookup table=main
add src-address=10.10.10.0/30 action=lookup table=ISP1
add src-address=10.10.11.0/30 action=lookup table=ISP2
add routing-mark=ISP1 action=lookup table=ISP1
add routing-mark=ISP2 action=lookup table=ISP2
The first 3 rules tell the router to ignore routing marks for all packets destined for the “connected” networks. The next 2 rules that tell the router to use ISP1 and ISP2 for the traffic FROM the router on those particular interfaces. These rules will allow us to manage the router remotely from either of the 2 “public” interfaces. Finally, there are 2 rules that use the ISP1 and ISP2 tables for traffic that we will “mark” for those tables.
Finally, we need to define the policies. A policy basically says, “use this routing table for this type of traffic”. Policies are implemented in the firewall using Mangle. We will use a couple of examples. In our first example, we will use the following policy:
All traffic from the 192.168.0.0/24 network will use ISP1 and all traffic from the 192.168.1.0/24 network will use ISP2. Here is the implementation:
/ip firewall mangle
add chain=prerouting src-address=192.168.0.0/24 action=mark-routing \
new-routing-mark=ISP1 passthrough=no
add chain=prerouting src-address=192.168.1.0/24 action=mark-routing \
new-routing-mark=ISP2 passthrough=no
The above 2 rules are all that are needed. Note that the “new-routing-mark” matches the “routing-mark” entry in the route statements we added earlier.
A common policy is to route certain traffic (by type) over certain networks. For example, we could implement a policy like the following:
Route all http, smtp, dns and pop3 traffic over our ISP1 circuit and all other traffic over the ISP2 circuit.
/ip firewall mangle
add chain=prerouting dst-port=80 protocol=tcp action=mark-routing \
new-routing-mark=ISP1 passthrough=no
add chain=prerouting dst-port=25 protocol=tcp action=mark-routing \
new-routing-mark=ISP1 passthrough=no
add chain=prerouting dst-port=110 protocol=tcp action=mark-routing \
new-routing-mark=ISP1 passthrough=no
add chain=prerouting dst-port=53 protocol=udp action=mark-routing \
new-routing-mark=ISP1 passthrough=no
add chain=prerouting action=mark-routing \
new-routing-mark=ISP2 passthrough=no
The above 4 rules will implement the policy requirement I stated. NOTE: In this policy, Peer-to-peer traffic will use ISP2, unless the peer-to-peer traffic tries to use one of the ports defined by the policy.
Peer-to-peer traffic requires more than one packet to identify, so if you want to implement a policy that applies to this traffic, you have to define OTHER traffic first, and let the peer to peer traffic follow the “default” action, as I did above.
This is not a complete description of all the possible implementations for policy routing, but it will give you a head start in implementing policy routing. I hope you find this article helpful.
February 2nd, 2009 at 1:15 pm
Any idea how I can add a routingmark when one of the WAN links are assigned IP by DHCP.
Cant find anywhere to add the mark in the dhcp client.
February 5th, 2009 at 10:46 pm
An easy way may be by using the “in-interface” match parameter.
March 24th, 2009 at 1:53 pm
I has use this example to route 2 Clases C on 2 diferent gateways.One of this gateway are with NAT and after I use this example I can`t access my inside servers.How can I access now the servers from outside?
April 18th, 2009 at 10:52 pm
There are some methods that you could use to do this. I am assuming that since you said “one of these gateways are with NAT”, that the other one is not. If that is the case, then you will need to use the connection tracking in Mangle to keep up with connections made to the NAT address. It’s a bit more than I can easily explain here in part because I am simply taking a “stab in the dark” as to what the problem is.
October 14th, 2009 at 2:28 am
I have a similar situation but with 1 LAN
so, does it work if I match specific computers inside the LAN to route through ISP2? and the rest of computers through ISP1?
Also, what about Dst-nat? I have E-mail server published and I want the users to access it from outside on both Real IP’s, is it doable with you configuration?
October 14th, 2009 at 3:13 am
You can use policy routing to route traffic based on any classification method you want. For example, you can create policies that route traffic based on the lan side IP address (what you asked specifically), the protocol (http goes out isp1, smtp out isp2, etc.) or any other match parameter available in the firewall mangle.
The destination nat question is an interesting one, because you have to use a combination of mangle and nat to make this work. What you’d use is something like:
/ip firewall mangle
add chain=forward in-interface=public1 action=mark-connection new-connection-mark=From_public1
add chain=prerouting connection-mark=From_public1 dst-address-type=!local action=mark-routing new-routing-mark=isp1
The above code would cause traffic that was originally dst-nat on the isp1 (public1) interface to be routed back out that same interface. Of course, you’d have to build similar rules for the ISP2 network. Additionally, you’d need to ensure that you have the proper src-nat rules in place so that traffic going out those 2 interfaces would be properly natted to the correct IP address.
October 14th, 2009 at 5:30 am
Butch, thanks for your quick reply
I’m having a slow connection on the primary ISP and sometimes timed out connection! on the other hand, the secondary ISP is working like a charm.
Moreover, if I trace route from primary connection I got a clean trace route and 100% successfully passing all the hops with a good latency.
my configuration:
NAT Conf:
chain=srcnat action=src-nat to-addresses=77.42.XX.XX src-address-list=blink_users out-interface=blink
chain=srcnat action=src-nat to-addresses=212.98.XX.XX src-address-list=special out-interface=terranet
Mangle Conf:
chain=prerouting action=mark-routing new-routing-mark=bli passthrough=no src-address-list=blink_users
chain=prerouting action=mark-routing new-routing-mark=ter passthrough=no src-address-list=special
Route Conf:
# DST-ADDRESS PREF-SRC GATEWAY-STATE GATEWAY DISTANCE INTERFACE
0 A S 0.0.0.0/0 reachable 77.42.XX.XX 1 blink
1 A S 0.0.0.0/0 reachable 212.98.XX.XX 1 terranet
2 A S 0.0.0.0/0 reachable 212.98.XX.XX 1 terranet
3 ADC 77.42.XX.XX/29 77.42.XX.XX 0 blink
4 ADC 192.100.100.0/24 192.100.100.20 0 lan
5 ADC 212.98.XX.XX/28 212.98.XX.XX 0 terranet
Route rule conf:
0 dst-address=192.100.100.0/24 action=lookup table=main
1 dst-address=77.42.xx.xx/29 action=lookup table=main
2 dst-address=212.98.xx.xx/28 action=lookup table=main
3 dst-address=212.98.xx.xx/28 action=lookup table=terranet
4 dst-address=77.42.xx.xx/32 action=lookup table=blink
5 dst-address=77.42.xx.xx/32 action=lookup table=blink
6 routing-mark=ter action=lookup table=terranet
7 routing-mark=bli action=lookup table=blink
Your help is highly appreciated
Regards,
October 14th, 2009 at 6:10 am
This is not really the best place for this discussion. Please send me an email direct and we can arrange support. My contact information is available in the right sidebar near the top.
December 14th, 2010 at 1:23 pm
[…] that is called policy based routing. See the following example, where they just have 2 subnets: Mikrotik policy routing implementation example | Butch Evans Blog i7 940 | Corsair 6GB DDR3 1600 + AX850W | Asus P6T Deluxe v2 + Xonar DX | 2x MSI Cyclone GTX 460 […]
January 27th, 2011 at 10:15 pm
i have internet connection from two different ISP and now i m using, i like to share this connection to my LAN
i want to configure like this ip 192.168.0.0/24 from iSP1
ip 192.168.0.100/24 from ISP2
and gateway will be 192.168.0.1
plz help me to configure this
July 28th, 2011 at 8:49 am
My question is how can i add the third ISP3? i want to the third Network to serve as additional support to any of the two Networks based on your setup incase ISP1 or ISP2 goes down for a while?
July 29th, 2011 at 6:49 am
or what happens if ISP1 goes down? likewise ISP2… will it automatically use the available ISP ? or do i need a script that will redirect traffice automatically to ISP3?
January 10th, 2012 at 8:25 am
[…] não é referenciada nas documentações e RFC. Understanding Policy Routing – Cisco Systems Mikrotik policy routing implementation example | Butch Evans Blog http://www.mikrotik.com/testdocs/ros/2.9/ip/route.php O OSPF você utiliza como IGP, para o […]
January 19th, 2012 at 9:23 pm
Policy Routing has limitation with throughput.
I checked that It has maximum 30 Mbps throughput with RB433AH box
September 14th, 2012 at 9:26 am
[…] você faz a regra para TCP 53 também. [1] http://wiki.mikrotik.com/wiki/Policy_Base_Routing [2] http://blog.butchevans.com/2008/09/m…ation-example/ Saudações, Trober Citação googletag.cmd.push(function() { […]
September 20th, 2012 at 2:24 pm
[…] Mikrotik policy routing implementation example | Butch Evans Blog. […]