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.

http://blog.butchevans.com

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s