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= routing-mark=ISP2
add gateway= routing-mark=ISP1
add gateway=

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= action=lookup table=main
add dst-address= action=lookup table=main
add dst-address= action=lookup table=main
add dst-address= action=lookup table=main
add src-address= action=lookup table=ISP1
add src-address= 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 network will use ISP1 and all traffic from the network will use ISP2. Here is the implementation:

/ip firewall mangle
add chain=prerouting src-address= action=mark-routing \
new-routing-mark=ISP1 passthrough=no

add chain=prerouting src-address= 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.

16 Responses to “Mikrotik policy routing implementation example”

  1. mhugo Says:

    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.

  2. Butch Evans Says:

    An easy way may be by using the “in-interface” match parameter.

  3. cobra Says:

    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?

  4. Butch Evans Says:

    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.

  5. maroon Says:

    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?

  6. Butch Evans Says:

    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.

  7. maroon Says:

    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:

    0 A S reachable 77.42.XX.XX 1 blink
    1 A S reachable 212.98.XX.XX 1 terranet
    2 A S reachable 212.98.XX.XX 1 terranet
    3 ADC 77.42.XX.XX/29 77.42.XX.XX 0 blink
    4 ADC 0 lan
    5 ADC 212.98.XX.XX/28 212.98.XX.XX 0 terranet

    Route rule conf:

    0 dst-address= 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


  8. Butch Evans Says:

    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.

  9. Hilfe!!! Says:

    […] 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 […]

  10. Badboi Says:

    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 from iSP1
    ip from ISP2
    and gateway will be

    plz help me to configure this

  11. collins465 Says:

    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?

  12. collins465 Says:

    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?

  13. Políticas de Rotas por Redes - Página 2 Says:

    […] 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 […]

  14. rigan123 Says:

    Policy Routing has limitation with throughput.
    I checked that It has maximum 30 Mbps throughput with RB433AH box

  15. Dúvida com rota para DNS Says:

    […] 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() { […]

  16. Mikrotik policy routing implementation example | Butch Evans Blog | Blog Administratora Says:

    […] Mikrotik policy routing implementation example | Butch Evans Blog. […]

Leave a Reply

You must be logged in to post a comment.