Manual:Routing Table Matcher

Introduction

Sometimes ISP's are giving different local and overseas bandwidth. To set up QoS you had to make static address list of local IP addresses, keep track of Ip ranges used in your country and update address list accordingly. Here you can find article describing mentioned approach.

With introduction of routing-table matcher it is possible to match packet which destination address is resolved in specific routing table. So we just need BGP peering with ISP and ask them to send all routes local to your country, add them to routing table and set up mangle rules accordingly.

Note: It is not possible to match source address against routing table.

Application Example

Consider following setup:

R1 is ISP router sending BGP routes R2 is client's main gateway and clients local network is 192.168.1.0/24

After setting up bgp peering (which is not covered in this article) we get following BGP routes

[admin@MikroTik] /ip route> print where bgp
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 .. 
 1 ADb  10.10.1.0/24                       10.1.101.1         20      
 2 ADb  10.10.10.4/32                      10.1.101.1         20      

Add routes to routing table

Next step is to add all received BGP rotues to another routing table, to do that we set up routing filters

#at first we have to specify input filter chain
/routing bgp peer set 0 in-filter=bbgp

#now we set up filter itself
/routing filter
add action=passthrough chain=bbgp set-routing-mark=local

As you can see now routes are added to "local" routing table

[admin@MikroTik] /ip route> print detail where routing-mark="local"
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 

...

 1 ADb  dst-address=10.10.1.0/24 gateway=10.1.101.1 
        gateway-status=10.1.101.1 reachable ether1 distance=20 scope=255 
        target-scope=255 routing-mark=local 
        bgp-as-path="3001,3001,3010,3002,3000" bgp-origin=incomplete 
        received-from=ISP 

 2 ADb  dst-address=10.10.10.4/32 gateway=10.1.101.1 
        gateway-status=10.1.101.1 reachable ether1 distance=20 scope=255 
        target-scope=255 routing-mark=local 
        bgp-as-path="3001,3001,3010,3002,3000" bgp-origin=incomplete 
        bgp-communities=3000:120,3000:200 received-from=ISP 

Mangle rule

Following mangle rule will match all packets that destination is resolved in "local" routing table.

/ip firewall mangle
add action=log chain=forward  routing-table=local

Routing rules

Now when we try to send packets from the client for example to address 10.10.10.4, mangle rule will not match anything. This is because by default every destination is resolved in "main" routing table.

To fix this we have to explicitly specify to resolve all packets coming from client in "local" routing table.

/ip route rule
add action=lookup src-address=192.168.1.0/24 table=local

Conclusion

To verify if packets are actually matched:

[admin@MikroTik] /ip firewall mangle> print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #   CHAIN              ACTION                  BYTES           PACKETS        
 0   forward            log                     28736           449 

Also check log messages

[admin@MikroTik] /log> print
...
11:06:31 firewall,info forward: in:bridge1 out:ether1, src-mac 00:0c:42:21:f1:ec
, proto ICMP (type 8, code 0), 192.168.1.10->10.10.10.4, len 44 
11:06:32 firewall,info forward: in:bridge1 out:ether1, src-mac 00:0c:42:21:f1:ec
, proto ICMP (type 8, code 0), 192.168.1.10->10.10.10.4, len 44
...

As you can see from the logs only packets coming from the client are matched. The reason for this is because routing-table matcher is matching only packet which destination address is resolved in local routing table. In our example 192.168.1.10 as destination is resolved in "main" routing table.

From what was said above, this approach is useful only for upload traffic marking and shaping.