Using RouterOS to QoS your network - 2020 Edition

Below are my mangle rules

I use similar / same QoS for customers and they experience same issues on local UPLOAD traffic being clamped. meaning, if I do a file transfer over the network from one computer to another – that transfer gets capped.

Mangle rules are essentially same for myself and i use for clients

/ip firewall mangle
add action=mark-connection chain=prerouting comment=VOIP_TRAFFIC
new-connection-mark=VOIP protocol=udp src-port=5060-5099
add action=mark-packet chain=prerouting connection-mark=VOIP new-packet-mark=
VOIP passthrough=no protocol=udp src-port=5060-5099
add action=mark-connection chain=prerouting comment=DNS dst-port=53
new-connection-mark=DNS protocol=udp
add action=mark-packet chain=prerouting connection-mark=DNS dst-port=53
new-packet-mark=DNS passthrough=no protocol=udp
add action=mark-connection chain=postrouting connection-mark=DNS
connection-state=new dst-port=53 new-connection-mark=DNS protocol=udp
add action=mark-packet chain=postrouting connection-mark=DNS dst-port=53
new-packet-mark=DNS packet-mark=DNS passthrough=no protocol=udp
add action=mark-connection chain=prerouting comment=“HTTP TRAFFIC” dst-port=80
new-connection-mark=HTTP protocol=tcp
add action=mark-packet chain=prerouting connection-mark=HTTP dst-port=80
new-packet-mark=HTTP passthrough=no protocol=tcp
add action=mark-connection chain=prerouting comment=HTTPS_Traffic dst-port=443
new-connection-mark=HTTPS protocol=tcp
add action=mark-packet chain=prerouting connection-mark=HTTPS dst-port=443
new-packet-mark=HTTPS passthrough=no protocol=tcp
add action=mark-connection chain=postrouting comment=“IPSEC TRAFFIC”
new-connection-mark=IPSEC protocol=gre
add action=mark-packet chain=postrouting connection-mark=IPSEC new-packet-mark=
IPSEC passthrough=no protocol=gre
add action=mark-connection chain=postrouting new-connection-mark=IPSEC
protocol=ipsec-esp
add action=mark-packet chain=postrouting connection-mark=IPSEC new-packet-mark=
IPSEC passthrough=no protocol=ipsec-esp
add action=mark-connection chain=postrouting dst-port=500 new-connection-mark=
IPSEC protocol=udp
add action=mark-packet chain=postrouting connection-mark=IPSEC dst-port=500
new-packet-mark=IPSEC protocol=udp
add action=mark-connection chain=prerouting comment=OTHER in-interface=
ether1_wan01 new-connection-mark=no-mark
add action=mark-packet chain=prerouting connection-mark=no-mark in-interface=
ether1_wan01 new-packet-mark=no-mark passthrough=no
add action=mark-connection chain=postrouting comment=TORRENTS
new-connection-mark=p2p_conns p2p=all-p2p
add action=mark-packet chain=postrouting connection-mark=p2p_conns
new-packet-mark=p2p_traff p2p=all-p2p passthrough=no

I put my master interface in a bridge and the problem off cap local traffic went away.

Thanks to know!

I have RB2011 routers out in field with similar configuration, except VLAN’s and they’re using BRIDGES.

So they might be fine.

It might just be an issue with this RB1100AH as I’m using ‘router on stick’ configuration with VLAN’s assigned to ether-trunks

I’m worried that If I put the trunks into a bridge, it will have a huge negative impact on performance?

I am new to VOIP prioritization and I need a bit of advice and it looks like I’m at the correct forum.

I have a multiple site network with multiple subnet vlans:

Main Location Connections:

  1. 50/50Mb fiber internet, protected with sonicwall 2600 firewall (not my choice of equipment, but what I have to use)
  2. 20/20Mb fiber ethernet MPLS provided by ISP to circuit to remote locations

I have a mikrotik router that I have configured at main to do NAT & Routing with vlans.
the way I have configured the MikroTik is this:
1 subnet for VOIP VLAN network 51.0/24 DHCP on MikroTik VLAN Bridge, 1 access port for local network switch. PBX onsite.
1 subnet for local computer DATA VLAN network 50.0/24 DHCP on MikroTik VLAN Bridge, 1 access port, for Local Network Switch computers, printers, and all other
3 x subnet for remote sites DATA VLAN network 40.0/24, 30.0/24, 20.0/24 DHCP on MikroTik VLAN for computers, printers, and all other at remote sties that need to communicate with each other site
1 MPLS (ether5) Trunk Port with 4 DATA Vlans & 1 VOIP VLAN51 (20/20Mb to MPLS ether switch)

The remote sites are all identical and look like this:

  1. access port for VOIP VLAN 51 (ether1)
  2. access port for MAIN Data VLAN 51 (ether2)
  3. access port for Local Network Vlan, 40, 30, 20 (ether3)
  4. ether4 spare
  5. MPLS (ether5) Trunk Port with 4 DATA Vlans & 1 VOIP VLAN51 (5/5Mb to MPLS ether switch)

I need QoS for VLAN 51 prioritized over all other traffic except primary default network traffic for routing.

Am I at the right spot? Please contact me if you can help or check over my setup and help with QoS.

Thank you for your time in this. This forum seemed to be pointing me in the correct direction with QoS, but I’m a little confused how to prioritize VLAN 51, at remote sites and then at the main location with different limits?

Also, I was wondering if I could just prioritize all VLAN 51 VOIP subnet, or if I needed to do port prioritization too.

Any guidance would be greatly appreciated.

Sincerely,

Lynn

I spent a gazillion hours tonight Googling and working through a bunch of different threads on the topic of QOS. (I’m new to Mikrotik and was going to wade in slowly, but I encountered some choppy voice on a test call today and thought I’d try to clean that up.)

I started with the script posted upthread by pcunite, but after reading some of the documentation, I made some changes and thought I’d post them here to share (in case it helps anyone, or in case someone would like to fix any massive errors I’ve created).

One of the issues with pcunite’s script is that you have to back off from the rated line speed by 10% or so in order to give Queue A (the one with the VoIP markings) a chance to breathe, since there doesn’t appear to be any logic that actually prioritizes Queue A over Queue C–it just basically relies on the fact that Queue C can’t quite use the entire connection to prevent Queue A’s packets from queuing at the ISP edge (in my case, the cable modem).

I think I’ve encountered a way to get a bit closer to the actual maximum throughput and let HTTP and other bulk downloads use the full connection without compromising VoIP (and other priority) packets. This is done by making all of the traffic classes child queues of a single parent queue and then ordering these child queues in priority–my understanding in the Mikrotik wiki documentation is that this should work.

I did some testing and it seems to work when I forced the link to saturation with HTTP traffic (there was no audible VoIP packet loss, and HTTP traffic showed a small amount of packets in the queue while the VoIP queue showed traffic and no queuing, indicating they were passed through without delay).

In my case, I’m on a 50m down, 3m up cable connection, and my ISP does ever so slightly overprovision the connection (~51mbps down and ~3.2mbps up, and they do a pretty good job of giving me my rated speed 24/7), so I wrote the script to push me right to the edge of 50M/3M, and it seems to work OK and gives me just barely shy of those figures to my workstation all while keeping the VoIP connection clean and ICMP pings to nearby servers in the single digits. That said, this is really just a test and a draft and a quick hack of the script (plus an attempt to remove a few of the seemingly redundant lines), so for those just stumbling upon this thread from Google, don’t put this into production without it being vetted by the more experienced community members here.

I also threw in a few extra things–some lines (with limit-at=) to guarantee bandwidth for at least a couple of concurrent calls–this may be unnecessary since it’s first in the priority list, but I figured it couldn’t hurt. I also capped the bandwidth of VoIP and other priority traffic to a shade less than my actual connection, just in case for some reason something happens and a UDP flood attempts to monopolize my upstream bandwidth–there will be a little left over for HTTP and other traffic.

One thing–both the original script by pcunite and this one seem to fail to properly mark the HTTP_BIG traffic. I don’t know if there have been any changes in RouterOS since pcunite last updated his script that may affect that, but I spent a good two hours working on trying to get that to work to no avail. Ultimately, I decided that as long as VoIP traffic is properly classified and prioritized and ACK packets are given priority on the uplink (which helps with the browser feeling responsive even on a saturated uplink), the need to separately classify bulk uploads is mitigated. Perhaps someone can troubleshoot that further.

Oh, one other thing–I did change the VoIP mangle rules to go by DSCP markings rather than ports, since my VoIP infrastructure does mark packets, but if yours doesn’t, you’ll want to uncomment the port-based matching lines and delete the ones that reference DSCP.

Anyway, it seems to be working here, but there’s a very good chance I just got lucky in my testing and it really isn’t working at all or something, so hopefully someone will come along to stop me from spreading misinformation if that’s the case…but I hope this helps in some way.

Date: September 29, 2015

Version: 1.3b1, based on work by pcunite

Tested with RouterOS 6.32.1

Rename ether1-gateway and bridge-local to match your environment




###############################################################################

Mangle

Using prerouting/postrouting since we don’t have dst or src checks.

/ip firewall mangle
###############################################################################

DNS requests. Mark in two places because DNS is sent out by the router (itself) too.

add chain=prerouting action=mark-connection protocol=udp port=53 connection-state=new new-connection-mark=“DNS” comment=“DNS”
add chain=postrouting action=mark-connection protocol=udp port=53 connection-state=new new-connection-mark=“DNS”
add chain=postrouting action=mark-packet passthrough=no connection-mark=“DNS” new-packet-mark=“DNS”

Mark all VoIP TCP traffic based on DSCP marking 46 and 26.

add chain=prerouting action=mark-connection protocol=tcp dscp=46 new-connection-mark=“VOIP” comment=“VOIP”
add chain=prerouting action=mark-connection protocol=udp dscp=46 new-connection-mark=“VOIP”
add chain=prerouting action=mark-connection protocol=tcp dscp=26 new-connection-mark=“VOIP”
add chain=prerouting action=mark-connection protocol=udp dscp=26 new-connection-mark=“VOIP”
add chain=prerouting action=mark-packet passthrough=no connection-mark=“VOIP” new-packet-mark=“VOIP”

Mark all VoIP traffic. We’ve set all our equiptment to use SIP 5060,5061 and RTP 10000-20000.

add chain=prerouting action=mark-connection protocol=udp port=5060,5061,10000-20000 new-connection-mark=“VOIP” comment=“VOIP”

add chain=prerouting action=mark-packet passthrough=no connection-mark=“VOIP” new-packet-mark=“VOIP”

Mark all UDP traffic. Mark different UDP streams if you want more granularity.

add chain=prerouting action=mark-connection protocol=udp connection-state=new new-connection-mark=“UDP” comment=“UDP”
add chain=prerouting action=mark-packet passthrough=no connection-mark=“UDP” new-packet-mark=“UDP”

Ping replies. Mark in two places because ICMP is sent out by the router (itself) too.

add chain=prerouting action=mark-connection protocol=icmp connection-state=new new-connection-mark=“ICMP” comment=“ICMP”
add chain=postrouting action=mark-connection protocol=icmp connection-state=new new-connection-mark=“ICMP”
add chain=postrouting action=mark-packet passthrough=no connection-mark=“ICMP” new-packet-mark=“ICMP”

ACK traffic. Based on viewtopic.php?f=2&t=67965

add chain=postrouting action=mark-packet passthrough=no protocol=tcp tcp-flags=ack packet-size=0-123 new-packet-mark=“ACK” comment=“ACK”
add chain=prerouting action=mark-packet passthrough=no protocol=tcp tcp-flags=ack packet-size=0-123 new-packet-mark=“ACK”

Mark all new HTTP(s) connections with “HTTP” if they have not previously been marked as “HTTP_BIG”.

If the current mark of “HTTP” tranfers more than 5MB and at a rate of 200k+ then mark it as “HTTP_BIG” for the duration of the TCP session.

add chain=prerouting action=mark-connection protocol=tcp new-connection-mark=“HTTP” connection-state=new port=80,443 comment=“HTTP”
add chain=prerouting action=mark-connection protocol=tcp connection-mark=“HTTP” new-connection-mark=“HTTP_BIG” connection-bytes=500000-0 connection-rate=200k-1000M
add chain=prerouting action=mark-packet passthrough=no connection-mark=“HTTP_BIG” new-packet-mark=“HTTP_BIG”
add chain=prerouting action=mark-packet passthrough=no connection-mark=“HTTP” new-packet-mark=“HTTP”

Mark everything else that has no mark applied.

add chain=prerouting action=mark-connection connection-mark=no-mark new-connection-mark=“OTHER” comment=“OTHER”
add chain=prerouting action=mark-packet passthrough=no connection-mark=“OTHER” new-packet-mark=“OTHER”



###############################################################################

HTB Queue Tree a unidirectional queue

Based on 50M down / 3M up connection (measured at 50400k/50.4M down, 3008k/3.0M up).

Replace with your own values as needed and adjust downward if connection is unreliable.

Notes:

priority means ‘drop packets’ WHEN needed.

When limit-at=0 priority starts when max-limit is reached.

When limit-at=123 priority starts when limit-at is reached.

The priority option applies to children not parents. Parent is for setting

overall limits. Therefore use limit-at and max-limit on the children if

you want more granularity.

max-limit must always be set or priority will not happen.

Tips for TCP (not VoIP) SOHO network:

limit-at = Total bandwidth / max hosts

max-limit = Total bandwidth / min hosts

/queue tree
###############################################################################

The secret to ensuring VoIP quality (or any UDP traffic) is to put it into

a queue that will never be full and thus never prioritize (drop) packets.

add name=“MASTER_UP” parent=ether1-gateway queue=default max-limit=3000k
add name=“MASTER_DOWN” parent=bridge-local queue=default max-limit=50000k

add name=“VOIP_U” parent=“MASTER_UP” packet-mark=“VOIP” queue=default limit-at=200k max-limit=2850k priority=1
add name=“VOIP_D” parent=“MASTER_DOWN” packet-mark=“VOIP” queue=default limit-at=200k max-limit=45000k priority=1
add name=“ACK_U” parent=“MASTER_UP” packet-mark=“ACK” queue=default limit-at=200k max-limit=2850k priority=2
add name=“ACK_D” parent=“MASTER_DOWN” packet-mark=“ACK” queue=default limit-at=2000k max-limit=45000k priority=2
add name=“DNS_U” parent=“MASTER_UP” packet-mark=“DNS” queue=default limit-at=200k max-limit=2850k priority=3
add name=“DNS_D” parent=“MASTER_DOWN” packet-mark=“DNS” queue=default limit-at=2000k max-limit=45000k priority=3
add name=“UDP_U” parent=“MASTER_UP” packet-mark=“UDP” queue=default limit-at=200k max-limit=2850k priority=4
add name=“UDP_D” parent=“MASTER_DOWN” packet-mark=“UDP” queue=default limit-at=2000k max-limit=45000k priority=4
add name=“ICMP_U” parent=“MASTER_UP” packet-mark=“ICMP” queue=default limit-at=200k max-limit=2850k priority=5
add name=“ICMP_D” parent=“MASTER_DOWN” packet-mark=“ICMP” queue=default limit-at=2000k max-limit=45000k priority=5
add name=“HTTP_U” parent=“MASTER_UP” packet-mark=“HTTP” queue=default limit-at=200k max-limit=3000k priority=6
add name=“HTTP_D” parent=“MASTER_DOWN” packet-mark=“HTTP” queue=default limit-at=2000k max-limit=50000k priority=6
add name=“HTTP_BIG_U” parent=“MASTER_UP” packet-mark=“HTTP_BIG” queue=default limit-at=200k max-limit=3000k priority=7
add name=“HTTP_BIG_D” parent=“MASTER_DOWN” packet-mark=“HTTP_BIG” queue=default limit-at=2000k max-limit=50000k priority=7
add name=“OTHER_U” parent=“MASTER_UP” packet-mark=“OTHER” queue=default limit-at=200k max-limit=3000k priority=8
add name=“OTHER_D” parent=“MASTER_DOWN” packet-mark=“OTHER” queue=default limit-at=2000k max-limit=50000k priority=8

dear “alaskanjackal” giving higher priority to udp packets is not good when u download torrents, right?
i think i will place them under http_big

Perhaps not. I don’t (often) torrent, so that isn’t a concern. But that was in pcunite’s original script, and while prioritizing UDP traffic like that wouldn’t necessarily have been something I would have thought to do if I were writing a script myself, I saw no reason to change it.

There are other example scripts on the forums here that do a better job of classifying and deprioritizing torrent traffic, though none of the scripts I came across are perfect–most are just suggestions/ideas that require some heavy editing to get working. Despite its limited scope, the ones brought up in this thread are the most functional, at least from what I saw.

OK, so I just did a 1-hour long test (playing music through the line) while completely saturating my connection with multiple concurrent speed tests, uploads, downloads, and several very large Linux torrents going at once, and aside from one 20-second episode during the whole hour of some lightly choppy upstream audio, the VoIP call performed flawlessly.

I realized that shaping UDP downstream is pointless because it won’t cause any slowdown on the transmission, so there is no point in throwing away UDP packets that have managed to make it as far as my edge router. Perhaps it’s better just to not mark downstream UDP traffic or to put it in a separate (unlimited) queue or something, so I’ll mess with that later.

Also, there’s still some weirdness going on with HTTP and HTTP_BIG–stuff that isn’t big is going into BIG and stuff that is BIG is not, and then other stuff that should go into BIG gets left over and goes into OTHER. I’m not super worried about it, as the setup will likely work fine for daily use (and still prioritize VoIP, which is the main goal here), but it causes some unpredictable weirdness in choking/throttling larger uploads for no reason (occasionally, suddenly all upstream HTTP traffic will zero out for several seconds or even longer until it eases back to link speed). I probably need a better understanding of mangling and queue priorities in Mikrotik to diagnose that much more.

connection-rate is broken from firmware 6.28 and after. i dont understand why mikrotik dont fix it.
http://forum.mikrotik.com/t/connection-rate-not-work-on-rb951-2n/91736/4
downgrade to 6.28 and you will see that it works!
thank you for the nice qos script

Thanks. I dropped the connection-rate parameter from Mangle and it works now and properly classifies large transfers in HTTP_BIG once 5MB of data has been transferred. This may have negative consequences for some long-lived HTTP TCP connections that don’t use up much speed but may, over time, use more than 5MB of data, but I’m thinking it all probably makes very little practical difference in my network.

I also made a couple of additional changes just now: I separated out VOIP into VOIP-TCP and VOIP-UDP. I then put VOIP-UDP_D into a separate queue with a parent of my inbound interface (rather than MASTER_DOWN) without a limit. I also moved the other UDP_D outside of MASTER_DOWN with no limit. I think this is probably good practice, since, as I mentioned above, there’s no point in dropping inbound UDP packets if they’ve already made it this far. I left VOIP-TCP_D in the MASTER_DOWN queue with a limit as well as both VOIP-UDP_U and VOIP-TCP_U under MASTER_UP with limits (very unlikely that I’ll ever have more than a few dozen Kbps in VoIP traffic, but you never know what might happen, so why not).

Seems to be working, but I’ll play with it a bit more before posting a revised script.

Hi
Waiting for next parts… :smiley:

is there a newer version of this qos script? (1.3b1 is the latest i found)
can we use simple queues (pcq or sfq) instead of queue tree?

alaskanjackal,

Would you mind sharing your revised script? Thanks!

Had anyone got Option 2 to do anything? I have a 951Ui-2HnD 6.33.3 running in a small office with 5 VOIP phones connected to an internet VIOP server. Bandwidth is 8Mbs/1Mbs.
I have Option 2 installed set for 6Mbs/600Kbs. It’s tagging the packets right and the queues look good, but nothing happens. Speedtest.net reports the speed being 8Mbs/1Mbs, and if I run Speedtest.net while on a call, it gets all choppy.
So it’s not really doing anything.
I have spent the last 4 hours trying to get this to work, and bricked one 951 to the point that netinstall won’t see it trying to get this to work.
HELP!!!

alaskanjackal,

Please send me the updated MK script .

Try using pure DSCP
http://forum.mikrotik.com/t/dscp-mangle-and-queue-trees/100297/1

Does anyone know what is happen with option 3? Does it come out?
appreciate you


Thanks

alaskanjackal,

Would you mind sharing your new script?
(My mail: mrjurek@poczta.onet.pl)

Thanks.

Hello,

I am still using RouterOS 6.27 because connection-rate bug. Is it no fixed in new version ?
If already fixed, please tell me in which version.

Thanks

is already fix after 6.31 or 6.33. i cant remember exactly
u should install and test bugfix version 6.36.4