Tips and Tricks for Beginners and Experienced Users of RouterOS

Tips and Tricks for beginners and experienced users of RouterOS

This wiki page contains different kind of tips and tricks which could help for any RouterOS user. Each and every subject depends on RouterOS version and might change little bit between different kinds of RouterOS versions.

Note: Article is work on progress

Ease load on firewall by using no-mark as a mark for packets, connections and routing

Each packet goes through firewall and is checked against each firewall rule until it matches any of rules which are not set as passthrough. If you use rules which has action mark-packet, mark-connection and mark-routing, then it is worth to set additional matcher as no-mark for related parameter. It will allow for firewall to decide sooner if packet matches this rule and also will allow for you to avoid re-marking.

Example script which should configure router as explained before (written on 6.34.3 RouterOS):

foreach mrk in=("packet","connection","routing") do={
  {
    foreach i in=([/ip firewall mangle find where action=("mark-" . $mrk)]) do={
      local cmd ("ip firewall mangle set " . $i . " " . $mrk . "-mark=no-mark")
      :execute $cmd
    }
  }
}

Ease load on firewall by sorting firewall filter, NAT and mangle rules

Each packet goes through firewall and is checked against each firewall rule until it matches any of rules which are not set as passthrough. That means that CPU load and packet processing speed depends on it. There is a very simple way how to ease load on firewall filter, NAT and mangle rules and it is sorting. Based on action, without breaking logical order, you should sort your firewall rules by checking packet count on statistics for each independent rule. Move rules which has more packets matched up and those who have been matched more rarely move down. Remember that you always have to be sure that logical order of rules is not affected by this sorting.

If something does not work, then maybe it is like that on purpose

In RouterOS there is a feature called FastTrack. It makes connections more faster if it is enabled and correctly configured. Very often people are complaining that their queues or other features do not work. Make sure that FastTrack is not being accepted for the same traffic. Learn about feature you use before you use it.
http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack

Note: At the moment (6.34.3) FastTrack works only with UDP/TCP IPv4 traffic. In most cases you can easily test your configuration by using ping. If ping works and TCP/UDP does not, then it is very believable that FastTrack is here to blame

Make sure that interface names are correct

Quite often after using different kinds of scripts or for any other reason interfaces on router are renamed. If you are trying to configure something on interface and it does not work as suspected, make sure that you are trying to configure correct one.

Example command which should show correct interface names (written on 6.34.3 RouterOS):

[admin@MikroTik] > interface export 
/interface ethernet
set [ find default-name=ether3 ] name=ether1
set [ find default-name=ether1 ] name=ether3

Limits specified on parent Simple Queue are not working

In RouterOS if you have Simple Queues with child queues, then you have to remember that after parent queue matches some kind of traffic the same traffic will be again checked by child queues. It means that you have to cover whole set of packets which are captured by parent and there is a easy way to do it by using copy of parent as a child.

Example which shows how to correctly create child Simple Queue (written on 6.34.3 RouterOS).

This is not correct because only packets with address 192.168.88.1 will be limited by queues:

/queue simple
add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24
add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32

To fix this problem you have to add another child queue which would be copy of parent without specified limits:

/queue simple
add max-limit=100M/100M name=GLOBAL target=192.168.88.0/24
add max-limit=10M/10M name=child1 parent=GLOBAL target=192.168.88.2/32
add name=child2 parent=GLOBAL target=192.168.88.0/24

Queue slows down router

In RouterOS each Simple Queue works on single CPU core.

Example which shows how to ease load on Simple Queue on multi core systems (written on 6.34.3 RouterOS).

This queue will work on single core and will not work as fast as it would be possible:

/queue simple
add max-limit=100M/100M name=queue1 target=192.168.88.1/32,192.168.88.2/32

This queue will work on two CPU cores and will work better compared to previous queue (of course you have to be sure that limit is proper for you):

/queue simple
add max-limit=50M/50M name=queue2 target=192.168.88.1/32
add max-limit=50M/50M name=queue3 target=192.168.88.2/32

Myth about reboot

Very often people say that problem dissapeared after reboot. In most cases it actually is not true. Reboot does many things, for example, clears DNS cache, clears different dynamic entries and so on. If reboto helped in your case, you should think what on your device is configured and what of it is cleared by reboot. Then you can try to trace real reason.

Create static bindings for PPP interfaces

If you do not like that your PPP interfaces are dynamic, then you can on PPP profile execute on-up script which create static server binding for each client.

Example is made for PPPoE interfaces, but it can be easily adjusted for any other PPP interface types (written on 6.34.3 RouterOS):

if ([/interface pppoe-server print count-only where user=$user && !dynamic] = 0) do={
  log info message=($user . " - is being added as static binding")
  /interface pppoe-server add name=$user user=$user service=service1
  /ppp active remove [find where name=$user]
}

Note: Last command within script will disconnect client at first time authentication

[ Top | Back to Content ]