MikroTik

Posted: **Mon Jan 18, 2016 12:26 pm**

Hi all,

I've looked all over but still can't fully grasp what I need to do to have this work. I'm a bit of a n00b. Hope you can help...

Here is my setup:

ether1 - WAN (Dialing PPPoE from Mikrotik through ADSL modem in bridge mode)
ether2 - PC
ether3 - switch in my lounge (media center, Xbox etc)
ether4 - VOIP Phone
ether5 - <empty>

I have a 10mb adsl line (10 up 1 down)

I'd like to create a priority queue so that my VOIP phone gets full priority, followed by my PC, then my switch etc...

Basically a cascading load-balancing situation so that if my line is heavily utilised (which it often is), priority bandwidth always goes to the top (VOIP phone in my case) and then PC etc...

It's probably dead simple but could anyone shed some light on how to achieve this? I'm assuming a queue tree is the way, as simple queues dont seem to be able to offer much in the way of automatic loadbalancing / traffic prioritisation.

Thanks in advance
WB

Posted: **Mon Jan 18, 2016 5:57 pm**

You can probably do this with simple queues instead of queue trees. It's a little easier because the simple queue lets you specify upstream and downstream limits all at the same place where a queue tree only works on packets outbound through a particular interface, so you'd need two queue trees - one on the pppoe interface and one on the LAN interface...

In either case, you're going to need to set up some mangle table rules to mark your packets. Since you're new at this, I suggest that you start simple and then gradually improve it as you begin to understand how it functions.

For the mangle portion, you're going to need to mark VoIP connections, and then based on the connection marks, you will mark the individual packets with a packet mark 'voip' - and then mark all other packets as 'default' or 'besteffort' or something like that.

/ip firewall mangle
add chain=prerouting connection-mark=no-mark action=jump jump-target=classify
add chain=prerouting connection-mark=voip action=mark-packet new-packet-mark=voip passthrough=no
add chain=prerouting action=mark-packet new-packet-mark=default passthrough=no
add chain=classify src-address=IP.OF.PHONE action=mark-connection new-connection-mark=voip
add chain=classify dst-address=IP.OF.PHONE action=mark-connection new-connection-mark=voip
add chain=classify connection-mark=no-mark action=mark-connection new-connection-mark=default

Then in your simple queues, create one simple queue that matches packet mark voip and put some settings on it that give it priority, e.g. use limit-at to guarantee a minimum amount of bandwidth - 180k should be enough for a single VoIP endpoint. Set priority=1 on this queue, and max-limit = 1M or something like this - perhaps the phone periodically downloads firmware from the VoIP server or something....

Then the other queue will match "default" packet mark, and it has priority 8 and max-limit = bandwidth of the DSL connection.

Once this works, you can start to create more packet marks and more queues and juggle the priorities and bandwidth parameters to your liking.

For simple queues, just use target=0.0.0.0/0 because you want to match against all traffic at the "global" level in your router - don't worry about using a particular interface. The packet marks will be how different traffic goes through different queues.

Posted: **Mon Jan 18, 2016 11:04 pm**

Thanks again ZeroByte

Luckily I'm already using mangling to route some traffic via a colleague's VPN for a SQL database so I get the basic idea of it.

Current mangle rule is as follows:

Chain: prerouting
Dst Address: 123.123.123.123 (SQL server)
Protocol:6 (TCP)
Port: 1234
Action: Mark Routing
New Routing mark: SQL_routing

I then have a Route for all route-marked traffic to go through the VPN.

What I don't understand is:

1. chain=classify - don't see that in the GUI in winbox nor do I know what it means

2. passthrough=no - still been wondering what this means with my current rules
3. Lastly, is it OK for a packet to have 2 marks? i.e. can I use my existing mangle rules ("SQL_routing") AND the 'besteffort' mark at the same time to achieve two different results? One for routing and of course one for bandwidth priortisation

Even though I know packet marks don't leave the router, I always thought it would be resource intensive to mark every single packet passing in and out of it. Does it not affect performance at all having the mikrotik do all this extra work for every packet?

Thanks again and sorry for all the questions
witblitz

Posted: **Mon Jan 18, 2016 11:22 pm**

What I don't understand is:

1. chain=classify - don't see that in the GUI in winbox nor do I know what it means
2. passthrough=no - still been wondering what this means with my current rules
3. Lastly, is it OK for a packet to have 2 marks? i.e. can I use my existing mangle rules ("SQL_routing") AND the 'besteffort' mark at the same time to achieve two different results? One for routing and of course one for bandwidth priortisation

Even though I know packet marks don't leave the router, I always thought it would be resource intensive to mark every single packet passing in and out of it. Does it not affect performance at all having the mikrotik do all this extra work for every packet?

Thanks again and sorry for all the questions
witblitz

1- this is a custom chain for the sake of performance - basically, connection marks are faster to process because the router is already tracking connections, so one check looks to see if the connection is marked or not. If not, then it goes into the classify chain where it can start saying "is it voip? no, is it web? no, is it etc etc etc. One thing I forgot is to put a rule at the end of the classify chain with the action=return. This means that after the connection is classified, then it goes back to the rest of the mangle prerouting chain.

When creating a custom chain, you have to type the chain name in manually somewhere first - either as the jump target of the jump rule, or else when you create the first rule in the chain. After that, the custom chain will be available as a drop-down selection everywhere that chain names are used.

2. put your route mark rules after the jump rule, but before the passthrough=no packet mark rules.

3. connection marks, packet marks, and routing marks are all separate from each other, but as far as I know, a packet can only have one of each.

As for performance, as I stated in my answer to #1, the goal is to cause the router to have the fewest number of rules as possible to evaluate because yes, it must traverse the chain(s) for each and every packet. It's not as bad as it sounds, but you do need to keep efficiency in mind when making firewall rules.

Posted: **Tue Jan 19, 2016 10:51 am**

Thanks again man. I'll have to do some reading on chains, jump-rules etc as I'm not familiar with the terminology so not really grasping the exact process here. I do however understand what we're doing as a whole, but obviously I need to make myself understand this 100% for future.

You said

"One thing I forgot is to put a rule at the end of the classify chain with the action=return"

Would you mind pasting me the code again with that rule in there? Don't wanna mess it up I'm not totally clear on where it should go or the syntax.

Cheers!
WB

Posted: **Tue Jan 19, 2016 6:59 pm**

Would you mind pasting me the code again with that rule in there? Don't wanna mess it up I'm not totally clear on where it should go or the syntax.

You know that you can drag and drop rules to change their order within a chain - so if you need to adjust it, that's how...

whenever you add a rule:
/ip firewall masquerade add chain=X {stuff}
This puts the new rule on the end of the chain named X.

Anyway - to add the return rule at the end of the classify chain, just type this into the terminal:
/ip firewall masquerade add chain=classify action=return

When you make a custom chain, the system won't use it by default - you tell one of the system chains when you want it to be used. They're quite useful because you can hook the same chain up in multiple places - for instance if you wanted to classify new outgoing connections from the Mikrotik by the same set of rules, then you could just put a jump rule in the output mangle chain that jumps into 'classify', and the same rules now apply to both "prerouting" and "output"

Return means to go back into whatever chain it was that jumped into this chain. I don't think you can put action=return on a system chain such as postrouting - it wouldn't make sense.

Chains make sense if you find yourself putting lots of rules in a row with lots of similar criteria on them.
For example, suppose you have a DMZ host on a DMZ interface, and the host is 192.168.10.12 and you want to allow http, https, and dns from the world, you want to allow a whitelisted host to have full access (suppose the whitelisted host is where you originate management from for services such as remote desktop, etc - you want this host to be able to do everything) - furthermore, you have a blacklist but only for this one host... this takes several rules to do:

/ip firewall filter
add chain=forward connection-state=established,related
add chain=forward out-interface=dmz dst-address=192.168.10.12 src-address-list=backlist action=drop
add chain=forward out-interface=dmz dst-address=192.168.10.12 protocol=tcp dst-port=80,443
add chain=forward out-interface=dmz dst-address=192.168.10.12 protocol=udp dst-port=53
add chain=forward out-interface=dmz dst-address=192.168.10.12 src-address-list=whitelist
add chain=forward out-interface=dmz dst-address=192.168.10.12 action=drop
add chain=forward out-interface=wlan1 action=accept

Note that this configuration causes the router to repeatedly check the interface and destination IP address - which wastes cpu cycles at the very least, and it also clutters up your view with lots of rules.

If a packet comes along that isn't going to 192.168.10.12, but is a new connection, then it has to pass all 5 of the remaining rules before any other rules can be checked and might apply to this packet.... if all of these checks are in a separate chain, then you can make things faster for packets like this if they only have a single rule to get past:

/ip firewall filter
add chain=forward connection-state=established,related
add chain=forward out-interface=dmz dst-address=192.168.10.12 action=jump jump-target=server-filter
add chain=forward out-interface=wlan1 action=accept

add chain=server-filter src-address-list=blacklist action=drop
add chain=server-filter protocol=tcp dst-port=80,443
add chain=server-filter protocol=udp dst-port=53
add chain=server-filter src-address-list=whitelist
add chain=server-filter action=drop

See how short the forward chain becomes for packets that aren't going to the server?
See how much simpler each rule is for packets that ARE going to the server?
In this particular case, the default rule of the server-filter rule is to drop everything that doesn't match, but you could actually just return the packet because you might have some default log targets or something back out in the forward chain.... but this is all a matter of how you design things.

Posted: **Wed Jan 20, 2016 11:53 am**

Once again, Thanks Zerobyte. You're the man !!

I've got it working, however it has broken my other 2 mangle rules and I'm not sure where to put them in the current list.

I really want to stop asking you so many questions but I'm so close!

Here are my 2 existing mangle rules:

5   chain=prerouting action=mark-routing new-routing-mark=vpn_traffic passthrough=no protocol=tcp dst-address=1.1.1.1 log=no log-prefix="" 
 6    chain=prerouting action=mark-routing new-routing-mark=vpn_traffic passthrough=no protocol=tcp dst-address=2.2.2.2 dst-port=5038 log=no log-prefix=""

I have a PPTP VPN dialled at all times.

I then have a ROUTE configured to push anything with the ROUTING MARK "vpn_traffic" (as above) through that VPN. This works fine until now. I've tried moving them under your jump rule below but still doesnt work.

Here is the code you gave me, modified (10.0.0.199 is my VOIP phone)

 9 X  chain=prerouting action=jump jump-target=classify connection-mark=no-mark log=no log-prefix="" 
10 X  chain=prerouting action=mark-packet new-packet-mark=voip_traffic passthrough=no connection-mark=voip_traffic log=no log-prefix="" 
11 X  chain=prerouting action=mark-packet new-packet-mark=default passthrough=no log=no log-prefix="" 
12 X  chain=classify action=mark-connection new-connection-mark=voip_traffic passthrough=yes src-address=10.0.0.199 log=no log-prefix="" 
13 X  chain=classify action=mark-connection new-connection-mark=voip_traffic passthrough=yes dst-address=10.0.0.199 log=no log-prefix="" 
14 X  chain=classify action=mark-connection new-connection-mark=default passthrough=yes connection-mark=no-mark log=no log-prefix="" 
15 X  chain=classify action=return log=no log-prefix=""

My (hopefully FINAL) questions are:

1.) Where do my current mangle rules go in order to use the simple queue AND my VPN routing simultaneously?
2.) If I were to add another packet mark (i.e. NETFLIX) for a third queue, what would I add? My guess is:

/ip firewall mangle
add chain=classify src-address=my.tv.ip.address action=mark-connection new-connection-mark=netflix
add chain=classify dst-address=my.tv.ip.address action=mark-connection new-connection-mark=netflix

Posted: **Wed Jan 20, 2016 11:56 am**

Also maybe worth mentioning these are the existing 4 mangle rules (Default). Assuming these can stay at the TOP of the list:

[admin@MikroTik] /ip firewall mangle> print
Flags: X - disabled, I - invalid, D - dynamic 

 0  D chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-ppp tcp-mss=1441-65535 log=no log-prefix="" 
 1  D chain=forward action=change-mss new-mss=1410 passthrough=yes tcp-flags=syn protocol=tcp in-interface=all-ppp tcp-mss=1411-65535 log=no log-prefix="" 
 2  D ;;; special dummy rule to show fasttrack counters
      chain=prerouting 
 3  D ;;; special dummy rule to show fasttrack counters
      chain=forward 
 4  D ;;; special dummy rule to show fasttrack counters
      chain=postrouting

then comes my 2 mangle rules, and then yours. That's how I have it now, anyways

Posted: **Wed Jan 20, 2016 1:17 pm**

OK so..........

Somehow, my old 2 mangle rules started working again. God knows how

I then wanted to add them (vpn route-marked traffic) to the VOIP queue as well, as this pertains to my VOIP db and contacts list and may as well also have priority.

I figured I'd give a connection mark of "voip_traffic" to any packets that already had the "vpn_traffic" routing mark.

However, I couldn't get it to work UNTIL I changed the chain on this rule to "forward". It was on "prerouting" before like the other 2 mangle rules, but came after them.

The problem is I don't understand WHY. But everything works... Perhaps not in the most efficient way.

So I have my 4 default mikrotik rules, then the below, and then the whole section you gave me with the jump into classify chain etc...

5   chain=prerouting action=mark-routing new-routing-mark=vpn_traffic passthrough=no protocol=tcp dst-address=1.1.1.1
 6   chain=prerouting action=mark-routing new-routing-mark=vpn_traffic passthrough=no protocol=tcp dst-address=2.2.2.2 dst-port=5038 
 7  chain=forward action=mark-connection new-connection-mark=voip_traffic passthrough=yes routing-mark=vpn_traffic

Feel free to ignore all the above, but if you see something that seems wrong and are really bored, do let me know.

Thanks for all your help man!!

Cheers
witblitz

Posted: **Wed Jan 20, 2016 6:30 pm**

Feel free to ignore all the above, but if you see something that seems wrong and are really bored, do let me know.

I'd say to set passthrough=yes on those route-mark rules.

Posted: **Wed Jan 20, 2016 6:39 pm**

OK thanks I've done that.

Unfortunately 3 more issues I've noticed:

1.) the mark-connection rule for my.voip.phone.ip (in the classify chain) got a BIT of traffic at some stage but since then has had none. Bytes/packets reading in the mangle section both read 0 since i reset counters.. (even after many voip calls)

2.) But somehow, I can still see traffic in the VOIP queue. Which is odd because it doesnt look like the mark-connection rule (which eventually triggers the mark-packet rule) is doing its job!?

3.) When looking at the VOIP queue's traffic (while im on a VOIP call), I see downstream traffic but no upstream. Tx is at 0 constantly, while Rx looks healthy. Therefore I can only assume that my VOIP phone's Tx isnt included in the queue.

This has all left me rather confused. I've totally grasped the whole jump rule and classify chain (thank you for this). But the anomalies above have left me very very confused.

Can I start paying you for your time or something ?!

Posted: **Wed Jan 20, 2016 6:48 pm**

OK thanks I've done that.

Unfortunately 3 more issues I've noticed:

1.) the mark-connection rule for my.voip.phone.ip (in the classify chain) got a BIT of traffic at some stage but since then has had none. Bytes/packets reading in the mangle section both read 0 since i reset counters.. (even after many voip calls)

2.) But somehow, I can still see traffic in the VOIP queue. Which is odd because it doesnt look like the mark-connection rule (which eventually triggers the mark-packet rule) is doing its job!?

3.) When looking at the VOIP queue's traffic (while im on a VOIP call), I see downstream traffic but no upstream. Tx is at 0 constantly, while Rx looks healthy. Therefore I can only assume that my VOIP phone's Tx isnt included in the queue.

This has all left me rather confused. I've totally grasped the whole jump rule and classify chain (thank you for this). But the anomalies above have left me very very confused.

Can I start paying you for your time or something ?!

Heh - no money needed.

1 and 2 are basically the same thing: The classify mark-connection rule only runs whenever a new connection forms - so the first packet of the connection will match this rule, and from that point forward, the connection is marked. The kernel's connection tracking automatically handles it from there. That's why you use connection marking to do packet marking... it's faster this way. The mark-packet rule should be running up a bunch of hits though.

3 - if you're still using queue trees, then I would expect this - a queue tree is like a shower head - a stream of water comes in one side and it sprays the water out of lots of little holes on the other. The "parent" side of the queue is the water pipe, and the sprayer faces "outward" onto the network of that interface.... if this analogy makes any sense....

So going upstream, you'd need another queue tree on the wan interface - but you should be able to use the same packet marks for this.

Posted: **Wed Jan 20, 2016 6:54 pm**

Thanks bro

I'm using simple queue's as you suggested (default-small).

I have 2 - one for VOIP (top priority) and one for Other traffic (lower priority),

Neither have any child queues:

add limit-at=200k/200k max-limit=1M/1M name="VOIP Queue" packet-marks=voip_traffic \
    priority=1/1 target="" time=9h-20h,mon,tue,wed,thu,fri
    
add max-limit=2M/12M name="Other Traffic Queue" packet-marks=default target=""

Does that make any sense as to why the upload is always at 0 on my VOIP queue?

The queue for other traffic seems to work fine.

Posted: **Wed Jan 20, 2016 7:01 pm**

I think I may have solved my own problem... I had 0.0.0.0/0 for target in my queues.

I have ports 3,4,5 bridged to port 2 (bridge-local).

I set the target on my VOIP queue to bridge-local and both upload/download are showing traffic

Does this make sense!?

If so - awesome.

All I need to do now is just add extra connection and packet marks for my other traffic (like netflix example).

It it to simply duplicate the connection mark (classify chain) and packet marks as before?

Posted: **Wed Jan 20, 2016 7:04 pm**

Yep - that's how you'd put more traffic classes in there, alright. Just insert new class rules between voip and default (order-wise) and you know you're in the right place.

Glad I could help the light come on for using chains - they're great in many respects. Did you notice the drop-down filter at the top-right corner of the firewall window? That lets you view chains one at a time. If you have a chain selected and click "new rule" then that chain will be chosen by default, too.

Posted: **Wed Jan 20, 2016 7:32 pm**

You've helped many lights come on my man. I appreciate it

That dropdown filter looks handy but I've hardly got any rules at this stage lol.

I have many more questions given that I'm not a trained network guy, but I will reserve them for future.

Much respect sir

WB

Posted: **Thu Jan 21, 2016 2:11 pm**

Hey man

VERY quick Q!

If I were simply trying to prioritise traffic from different DEVICES on my network, would it not be more efficient to ditch all mangle rules and simply make simple queues for each device via its port on the mikrotik or its IP(s)?

e.g.

1. Target=Ether4-VOIP Phone - Priority 1
2. Target=Ether-2-PC - Priority 2
3. Target=Ether-3-TV- Priority 3
4. Target=All my girlfriend's device IPs - Priority 4

Posted: **Thu Jan 21, 2016 5:16 pm**

Yep - that would be a simple way to do it. Of course if you ever want to put two devices into the same bandwidth policy to share a queue, then you're back to mangling anyway....

6 in one hand / half a dozen in the other, really.

In your situation, I'd probably just use direct IP targets in the simple queue, and I would keep the devices configured to use DHCP, but put static leases in the Mikrotik. (centralized but simple configuration that way)

1. Target=Ether4-VOIP Phone - Priority 1
2. Target=Ether-2-PC - Priority 2
3. Target=Ether-3-TV- Priority 3
4. Target=All my girlfriend's device IPs - Priority 4

I think you've got priorities scrambled:
1) priority 2
2) priority 4
3) priority 3
4) priority 1

Posted: **Thu Jan 21, 2016 5:19 pm**

OK cool

Yes I've reserved IPs for all my devices in DHCP server config so they're essentially static

I will probably end up using mangles anyway when I need to split traffic coming from my PC (which has a lot going on). So this has been a productive exercise nonetheless.

Thanks again!

Posted: **Thu Jan 21, 2016 6:34 pm**

I think you've got priorities scrambled:
1) priority 2
2) priority 4
3) priority 3
4) priority 1

lol. the girlfriend doesn't need to know what a mikrotik or queue is and I plan to keep it that way

MikroTik

Basic Queue Tree Help

Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help

Re: Basic Queue Tree Help