Manual:Routing Table Matcher: Difference between revisions
Created page with '<h2>Introduction</h2> <p> 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 o…' |
No edit summary |
||
Line 120: | Line 120: | ||
[[Category:Manual]] | [[Category:Manual]] | ||
[[Category:IP]] | |||
[[Category:Routing]] | [[Category:Routing]] | ||
[[Category:Firewall]] | [[Category:Firewall]] | ||
[[Category:Examples]] | [[Category:Examples]] |
Revision as of 12:01, 15 March 2010
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--R2--Client 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 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.