Using RouterOS to prioritize (Qos) traffic for a Class C net

pcunite · Fri May 31, 2013 9:43 pm

Title:
Using RouterOS to prioritize (Qos) traffic for a Class C network

Welcome:
Congratulations on purchasing MikroTik's RouterOS v6 implementation for your network - one of the most powerful ways to manage Internet connectivity for both the enthusiast and network administrator alike. This article is not for ISPs or WISPs but rather office and home environments (SOHO) that want a single router to provide IP Firewalling and Qos services.

Why prioritize traffic?
Generally speaking because interactive traffic is waiting on large amounts of big bulky traffic. You have one connection to the Internet behind one router. Even if you could afford to add more Internet connections and more routers it is still possible to overwhelm them. Prioritizing (Qos) your network means to keep interactive traffic moving while shaping and limiting bulky traffic.

Traffic Types:
For the purposes of this article we are going to classify VoIP traffic as the most important type of user level traffic. Any other type of traffic (like big bulky http downloads) will be considered less important when VoIP traffic is occurring. However, when no VoIP traffic is present we want all other types of traffic to have full use of Internet services. The moment new VoIP calls come into play, once again other traffic will take secondary importance for the duration of VoIP calls.

Identifying your high priority traffic:
It is very easy to identify your traffic because we are working with a Class C network that you are in control of. You know the IP Addresses, or the IP Subnets (VLAN), or the Ports, or the TOS values for the equipment you support. Because of this it is really up to you how to want to label or mark your most valuable traffic. For our VoIP traffic we know that: udp SIP ports 5060, udp RTP ports 10000-20000, IP Address 192.168.0.5, and a TOS of 160 are VoIP source and destination locations and values. So, we could choose several ways of prioritizing these locations.

Disclaimer:
What follows is my best understanding of how to implement the stated goals in RouterOS v6 based on the documentation available. Feedback from MikroTik as well as fellow forum members is required to make this an accurate document. Please suggest changes that should be made. Let's make this issue a commonly understood one. Thank you.

pcunite · Fri May 31, 2013 9:43 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6 – Option 1

How to choose which marking procedure:
Always try to use the fewest number of rules possible to get the most performance. If you have multiple VoIP sources on your LAN you should mark by Port or Subnet (if they all live together). In our case, we only have one ip address that needs priority and it is assigned to a PBX server. Any udp traffic this PBX server wants to send/receive we generously allow it access to our Internet service. What follows is the most performant method I am aware of while still being easy to edit for others.

Mark your high priority traffic:
Some explanations of the options we'll be using. Our Internet service in this example is 5M down and 1M up. It is impossible to Qos traffic without an understanding of buffering in ISP supplied equipment. Please read the post on buffering to understanding why we set max-limit the way we do.

Limit-at:
Start limiting when traffic reaches this amount. If less than this amount do not limit. Therefore this allocates or commits this much. 0 disables this feature.

Max-limit:
The maximum amount that marked traffic may reach. Necessary for the algorithms to function and must not be 0. Choose a value 80%-90% of your tested speed to prevent the ISP's equipment from buffering. Please read the post on buffering as to why this is important.

# Qos Script Lite v1.0
# September 7, 2013
# Compatible with RouterOS 6.3
# Rename ether-WAN and ether-LAN to match your environment

# Mark all UDP traffic for an IP-PBX.
/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"

# Mark everything else.
add chain=forward action=mark-connection connection-mark=no-mark                  new-connection-mark="OTHER" comment="OTHER"
add chain=forward action=mark-packet     passthrough=no connection-mark="OTHER"   new-packet-mark="OTHER"

# Create two queue trees set to 90% of ISP Internet service.
/queue tree
add name="LEVEL_A_UP"   parent=ether-WAN queue=default max-limit=900k
add name="LEVEL_A_DOWN" parent=ether-LAN queue=default max-limit=4M
add name="LEVEL_B_UP"   parent=ether-WAN queue=default max-limit=900k
add name="LEVEL_B_DOWN" parent=ether-LAN queue=default max-limit=4M

# Add our marked connections as children of queue so priority works.
add name="VOIP_U"       parent="LEVEL_A_UP"   packet-mark="VOIP"  queue=default priority=1
add name="VOIP_D"       parent="LEVEL_A_DOWN" packet-mark="VOIP"  queue=default priority=1
add name="OTHER_U"      parent="LEVEL_B_UP"   packet-mark="OTHER" queue=default priority=2
add name="OTHER_D"      parent="LEVEL_B_DOWN" packet-mark="OTHER" queue=default priority=2

Notes:
This is our first example to get your feet wet. It is excessive in its support of udp (VoIP) traffic to all else. It would be recommended when the up-link is very small (say 512k or less). Normally you will not be saturating your links with only VoIP traffic and will have room to spare. Continue reading to see a well-rounded implementation for SOHO and larger situations.

pcunite · Fri May 31, 2013 9:44 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6 – Option 2

In this example we still give VoIP everything it wants (VoIP demands nothing less). However, we know the amount of calls and therefore Internet service contract we should purchase. Thus we know that we will not be saturating our Internet service with VoIP. This allows us to create additional queues to classify important traffic by function.

Standard traffic that should be classified into queues
Some traffic is special and should be passed on quickly whenever it appears. Traffic like DNS queries, ACK acknowledgments, ping replies, etc. Then you have traffic like simple and short web page views. Everything else, for the purposes of this article, is considered Bulk traffic. This would be things like ftp/http downloads, YouTube sessions, torrent sessions, and every other random thing out there. If you know that you have other special traffic (ssh sessions) that should not be considered Bulk, simply edit what follows and place it in the correct queue.

# Date: September 28, 2017
# Version: 1.3
# Tested with RouterOS 6.38.7
# Rename ether-WAN and bridge-LAN 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=prerouting  action=mark-packet     passthrough=no connection-mark="DNS"        new-packet-mark="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 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=prerouting  action=mark-packet     passthrough=no connection-mark="ICMP"       new-packet-mark="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   connection-mark=!"HTTP_BIG"  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-100M
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 90% of 1Mup/5Mdown Internet service.
#
# 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="LEVEL_A_UP"   parent=ether-WAN  queue=default max-limit=900k
add name="LEVEL_A_DOWN" parent=bridge-LAN queue=default max-limit=4M

# Next, create a queue for high priority traffic.
add name="LEVEL_B_UP"   parent=ether-WAN  queue=default max-limit=900k
add name="LEVEL_B_DOWN" parent=bridge-LAN queue=default max-limit=4M

# Finally, create a queue for traffic that normally exceeds levels.
add name="LEVEL_C_UP"   parent=ether-WAN  queue=default max-limit=900k
add name="LEVEL_C_DOWN" parent=bridge-LAN queue=default max-limit=4M

# A
add name="VOIP_U"       parent="LEVEL_A_UP"    packet-mark="VOIP"     queue=default priority=1
add name="VOIP_D"       parent="LEVEL_A_DOWN"  packet-mark="VOIP"     queue=default priority=1
# B
add name="ACK_U"        parent="LEVEL_B_UP"    packet-mark="ACK"      queue=default priority=1
add name="ACK_D"        parent="LEVEL_B_DOWN"  packet-mark="ACK"      queue=default priority=1
add name="DNS_U"        parent="LEVEL_B_UP"    packet-mark="DNS"      queue=default priority=2
add name="DNS_D"        parent="LEVEL_B_DOWN"  packet-mark="DNS"      queue=default priority=2
add name="UDP_U"        parent="LEVEL_B_UP"    packet-mark="UDP"      queue=default priority=3
add name="UDP_D"        parent="LEVEL_B_DOWN"  packet-mark="UDP"      queue=default priority=3
add name="ICMP_U"       parent="LEVEL_B_UP"    packet-mark="ICMP"     queue=default priority=4
add name="ICMP_D"       parent="LEVEL_B_DOWN"  packet-mark="ICMP"     queue=default priority=4
# C
add name="HTTP_U"       parent="LEVEL_C_UP"    packet-mark="HTTP"     queue=default priority=1
add name="HTTP_D"       parent="LEVEL_C_DOWN"  packet-mark="HTTP"     queue=default priority=1
add name="HTTP_BIG_U"   parent="LEVEL_C_UP"    packet-mark="HTTP_BIG" queue=default priority=2
add name="HTTP_BIG_D"   parent="LEVEL_C_DOWN"  packet-mark="HTTP_BIG" queue=default priority=2
add name="OTHER_U"      parent="LEVEL_C_UP"    packet-mark="OTHER"    queue=default priority=3
add name="OTHER_D"      parent="LEVEL_C_DOWN"  packet-mark="OTHER"    queue=default priority=3

Disclaimer:
When suggesting changes please offer solutions that would be easy to edit for others. I'm reserving Option 3 for expert configurations (performance or otherwise) if needed. I want this to be the default Qos topic we can point people to.

pcunite · Fri May 31, 2013 9:45 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6
Option 3 ... coming soon

pcunite · Sat Jun 01, 2013 6:02 pm

How Buffering and bufferbloat in ISP supplied equipment affects Qos and latency sensitive protocols

Understand that in modern computers and routers there is almost no delay between the interfaces with port speeds now at 1000Mbps. Even 100Mbps and 10Mbps is generally faster than Internet service. This means that when up-link traffic leaves the router (probably coming from multiple PC's and phones), unless you take action, it will always be queued by whatever is connected to the router's up-link port. This is usually a cable or adsl modem or other ISP's supplied equipment.

Up-link
To explain this in detail let's first focus on up-link traffic. As stated, traffic leaving the router's up-link (WAN) port is coming from multiple PC's and or VoIP phones. Let's just say that no one is consciously doing any uploading or downloading as commonly defined. Surfing the internet and talking on the phone … that's not uploading and downloading is it? Yes, it is! When a user is simply browsing the web they are actually making 10 separate tcp http connections per page (modern web pages) thus sending and receiving traffic all at once. A single VoIP call is 90kb both directions.

As little as two people actively surfing the Internet and a single VoIP call can fill the modem's buffer. If it gets filled with tcp only traffic first (tons of ACK's or any traffic/protocol you don't care about), then your favorite udp traffic gets to wait forever while it empties. This repeats itself every second and very often destroys real time VoIP conversations. Never let your babies grow up to be queued by post router equipment!

Down-link
What about down-link traffic? If your router has a 100Mbps or better interface then it can generally keep up to where there is not going to be a problem UNLESS you have exceeded your ISP allotment for downloading. When that happens you begin to queue in several places. Since UDP traffic is not shapable (if you drop them they will not automatically slow down) the only thing you can do is to start dropping TCP traffic and allow it to automatically negotiate a slower rate. Thus for business customers always have a max-limit on the down-link for TCP traffic of any kind.

VoIP specifics
What if you only have UDP traffic and you've exceeded your download limits? Buy more Internet! UDP going both directions must never be dropped. If they are important to you then you must allow them through. If this is true then why have we specified an up-link limit for VoIP (udp) traffic? Because it is the lesser of two evils. Never drop VoIP packets but never queue them in a cable modem! If 2.5% of VoIP packets disappear some people won't notice. Naturally, you need to buy more upload speed if this is a constant issue for you. Our 1M up-link service can only handle about 12 active calls with zero room for anything else. Hopefully that never actually happens.

Disclaimers:
Qos does not fix network issues with your ISP. They must supply you with a connection that has 2.5% packet loss or less and has less than a 150ms round-trip delay to make VoIP and other interactive services work well. When testing, make sure that the network you're calling is also able to handle the call or the test is invalid and not a reflection on you.

Currently cable and adsl modems have an internal 300Kib buffer. Studies show that 16Kib is about right for most speeds in the USA. If and when this gets corrected you may not need to set max-limit so aggressively. Hopefully one day you'll be able to set it to the actual speeds you are paying for. The reason you must always set it to something is because the HTB algorithm used by Linux and RouterOS need a max-limit value to correctly force its queues to fill (and not your modem) and thus prioritize traffic.

Residential service contracts allow speeds to fluctuate based on time of day and network utilization. This means that if you set a max-limit of 900K and around noon the ISP only gives you 500K for 10 seconds then your VoIP call is going to have its packets queued at the customer's modem. This can never happen right? Well, it just did. If someone on the forum wants to tell the rest of us how to get real-time bandwidth changes (Dynamic Qos and shaping) so we can update max-limits on the fly ... well, that would be mighty nice. Otherwise, if you have issues purchase a business contract or set max-limit even more aggressively.

Shaping (limiting) means throwing away packets. With TCP, it will throttle itself and resend the packets at a slower rate. With VoIP and other udp type packets, they never come back. You have no option but to accept them and process them as fast as you can. There is no “C” in udp.

Codel is coming natively to the Linux kernel so some of these issues may improve or change.

For cable service use a 2012 or newer DOCSIS 3 modem like the Motorola SB6141.

pcunite · Sat Jun 01, 2013 6:02 pm

Reserved

Chupaka · Tue Jun 04, 2013 4:17 pm

great info, but it's better to use http://wiki.mikrotik.com for such articles - forum is more for questions, not for tutorials

pcunite · Tue Jun 04, 2013 4:22 pm

great info, but it's better to use http://wiki.mikrotik.com for such articles - forum is more for questions, not for tutorials

Thank you. My intention was to perfect this post and then have it accepted by MikroTik after all the experts had confirmed it. Then, as you say, have it posted in the Wiki.

Tue Jun 04, 2013 4:24 pm

great info, but it's better to use http://wiki.mikrotik.com for such articles - forum is more for questions, not for tutorials
Thank you. My intension was to perfect this post and then have it accepted by MikroTik after all the experts had confirmed it. Then, as you say, have it posted in the Wiki.

Good idea. Waiting for next parts.

deejayq · Mon Jul 01, 2013 1:30 pm

# HELP! I don't know how to mark what is left?

just add two rules at the bottom of the script
first mark-connection with dst-address=0.0.0.0/0 (nothing else)
second mark-packet with connection mark you set on the first rule (BULK i think you named both marks).

theprism · Sun Jul 14, 2013 3:48 am

It doesn't work.

Here's what I have:
****************************************
/ip firewall mangle

add chain=forward action=mark-connection src-address=192.168.151.7 new-connection-mark=VOIP
add chain=forward action=mark-packet passthrough=yes connection-mark=VOIP new-packet-mark=VOIP
add chain=forward action=mark-connection dst-address=192.168.151.7 new-connection-mark=VOIP
add chain=forward action=mark-packet passthrough=no connection-mark=VOIP new-packet-mark=VOIP

add chain=forward action=mark-connection dst-address-list=IPTVlist new-connection-mark=IPTV
add chain=forward action=mark-packet passthrough=yes connection-mark=IPTV new-packet-mark=IPTV
add chain=forward action=mark-connection src-address-list=IPTVlist new-connection-mark=IPTV
add chain=forward action=mark-packet passthrough=no connection-mark=IPTV new-packet-mark=IPTV

add chain=forward action=mark-connection src-address=0.0.0.0/0 new-connection-mark=BULK
add chain=forward action=mark-packet passthrough=yes connection-mark=BULK new-packet-mark=BULK
add chain=forward action=mark-connection dst-address=0.0.0.0/0 new-connection-mark=BULK
add chain=forward action=mark-packet passthrough=no connection-mark=BULK new-packet-mark=BULK

/queue tree

add name="TOTAL_U" parent=pppoe-out1 queue=default priority=8 limit-at=0 max-limit=680k
add name="TOTAL_D" parent=bridge-homelan queue=default priority=8 limit-at=0 max-limit=4300k

add name="VOIP_U" parent=TOTAL_U packet-mark=VOIP queue=default priority=1
add name="VOIP_D" parent=TOTAL_D packet-mark=VOIP queue=default priority=1

add name="IPTV_U" parent=TOTAL_U packet-mark=IPTV queue=default priority=2
add name="IPTV_D" parent=TOTAL_D packet-mark=IPTV queue=default priority=2

add name="BULK_U" parent=TOTAL_U packet-mark=BULK queue=default priority=8
add name="BULK_D" parent=TOTAL_D packet-mark=BULK queue=default priority=8

/ip firewall address-list
add address=184.84.243.193 list=IPTVlist
add address=4.27.18.126 list=IPTVlist
****************************************

In mangle I see exactly same counts for src and dst on each marking portion, which makes me think that mangles shouldn't be configured like that.
/ip firewall mangle screenshot is attached

Also prioritization doesn't work, since if I start my IPTV only, it works fine. Now, while IPTV is running, if I start a download, my IPTV is screwd. Image is distorted and become impossible to view and hear the audio.
/queue tree screenshot is attached

Any solutions?

Thanks,
T.P.

WiPoint · Thu Aug 29, 2013 3:05 pm

Hi from your Web Mangle Mark up rule MAX packet size has to to be in the range of 0-65535. Any advice on what to set it as?
ROS6.2 RB1100AHx2

pcunite · Sat Aug 31, 2013 12:56 am

We need someone from MikroTik (or popular online blogger) to help with these rules. These are what I was able to create based on documentation. Qos is a very important feature and one of the main reasons someone would want one of these advanced routers. Let's hope they chime in and we can build a good default script.

pcunite · Sat Aug 31, 2013 6:15 am

Hello everyone. I've tested and updated the script. It now works correctly on RouterOS 6.1. Note that ether1 is WAN and ether2 is LAN. Adjust those as necessary for your environment.

I would appreciate if someone could tell me how to mark big downloads over HTTP traffic. Currently, the script marks port 80 so everything HTTP gets too much priority. The idea situation would be to let short bursts of HTTP traffic get high priority and the big long downloads get less.

whiely · Sun Sep 01, 2013 11:27 pm

Hello everyone. I've tested and updated the script. It now works correctly on RouterOS 6.1. Note that ether1 is WAN and ether2 is LAN. Adjust those as necessary for your environment.

I would appreciate if someone could tell me how to mark big downloads over HTTP traffic. Currently, the script marks port 80 so everything HTTP gets too much priority. The idea situation would be to let short bursts of HTTP traffic get high priority and the big long downloads get less.

with connection byte ?

pcunite · Thu Sep 05, 2013 3:14 am

>> how to mark big downloads over HTTP traffic?

With connection byte?

Thank you, the answer is to use connection-bytes and connection-rate.

TikUser · Thu Sep 12, 2013 12:15 am

I’ve watched these 2 videos: HR13: QoS on RouterOS v6 and MUM US11: QoS workshop. In the second video (18:15min) Janis says: "Prerouting is a sum of (mangle) input and (mangle) forward. Both chains are together in here. Postrouting is a sum of (mangle) forward and (mangle) output."

Prerouting = input + forward
Postrouting = output + forward

In your Option 2 configuration You used prerouting and postrouting together. Will these two mangles come into conflict (because of 2 forwards)? If I’ve understood it correctly, in mangle postrouting we mark traffic that goes from the router (output) and through the router (forward). How will this affect the marked traffic from the prerouting and meant for forward? Will it be remarked?

pcunite · Thu Sep 12, 2013 12:55 am

Prerouting = input + forward
Postrouting = output + forward

In your Option 2 configuration You used prerouting and postrouting together. Will these two mangles come into conflict (because of 2 forwards)? If I’ve understood it correctly, in mangle postrouting we mark traffic that goes from the router (output) and through the router (forward). How will this affect the marked traffic from the prerouting and meant for forward? Will it be remarked?

I don't think the 2011 talk was referring to v6, maybe it was. But Prerouting not = input + forward. Look at the 3rd image here. The reason I use pre and post on DNS traffic is because the forward chain is not able to mark traffic sourced from the router itself and also traffic coming into the router from LAN.

Maybe there are other ways of accomplishing the same thing. Perhaps your question will reveal a better way. At the moment, this is all I know. However, when I was watching traffic from the connections menu, doing what I'm doing now was the only way to see it show up marked.

TikUser · Thu Sep 12, 2013 1:48 am

I believe the presentation (Packet Flow and QoS v6) in the 1st video (from 7:16min) could help clarify the situation. This is for ROS v6.

All traffic from the Input Interface goes to Chain Prerouting. If we choose to mark it in Prerouting, from there on, all traffic going to Input and Forward is marked. So, in a way, Prerouting is a sum of Forward and Input.
The Chain Output will remain unmarked. Maybe this is the answer on how to mark traffic sourced from the router itself. Mark it in the mangle Chain Output?

jandafields · Mon Oct 07, 2013 6:15 am

Looking at OPTION 2 above....

In Queue A, you have voip = priority 1
In Queue B, you have ack = priority 1
In Queue C, you have http = priority 1

Since the parent queues don't have a priority, what actually makes "queue A priority 1 (voip)" a higher priority than "queue C priority 1 (http)" since they are both priority 1?

Isn't there a setting that must tell which parent has a higher priority than another parent, or how will it know?

Or, if priority is the wrong term, the real question is: What keeps queue C from using up all the bandwidth and not leaving any for queue A, since they are both maxed at 900k/4M?

pcunite · Mon Oct 07, 2013 3:53 pm

Looking at OPTION 2 above....

In Queue A, you have voip = priority 1
In Queue B, you have ack = priority 1
In Queue C, you have http = priority 1
...
Or, if priority is the wrong term, the real question is: What keeps queue C from using up all the bandwidth and not leaving any for queue A, since they are both maxed at 900k/4M?

You are correct to wonder, and indeed there is something at issue here. I'm still perfecting this script. Basically what is happening currently, and why this script works for small networks is that: since Queue A is never full (never exceeds capacity) nothing is ever prioritized (dropped) within it. Queue C will always be exceeding capacity and thus traffic marked to go there will indeed be dropped (prioritized) at times. But as you've correctly noticed only at 900k/4M. This means that Queue A gets a 10% window of head room before ISP equipment starts to buffer.

What is the fix for this? I'm still researching but I think it must be a dynamic script using connection-rate and other actions. Let's review some wants.

1. Don't ever drop SIP and RTP (VoIP) packets.
2. Don't limit (drop) HTTP traffic until we absolutely have to.

To achieve the above we need to know how many SIP and HTTP (or random BULK) sessions are open (or their byte usage) at any given time. Thus a dynamic script ... when many SIP sessions are open we should increase the limits for HTTP (maybe only 100k/1M), when there are no SIP sessions, automatically allow HTTP to have 900k/4M usage again.

I've created this thread for people that know to tell us how to do this. So far, they've not see this thread and replied. But I do thank you for noticing.

jandafields · Mon Oct 07, 2013 4:21 pm

Ok, this command should tell you how many sip sessions are open. You might need to change dst-address to src-address, depending on the sip traffic:

/ip firewall connection print count-only where protocol="udp" and dst-address~":50.."

~":50.." will match any port between 5000 and 5999

We could run that every xx seconds, then use the number returned by that command and then limit the other queues accordingly as we know that every sip session is probably around 100kbps in both directions.

Craftylover · Tue Oct 15, 2013 4:27 am

Hello everyone.
It seems as though many of the QOS examples listed in the forum are individually tailored to a certain users needs and/or a particular application -this one just happens to be generic enough to make a little sense to me (completely new at this).

Might there be a way to add anything to this configuration that would help prioritize streaming video for a home network? Looks as though some of the Netflix traffic for example gets lost in the fray when there is heavy traffic marked as HTTP and the quality tends to suffer. I have seen some stuff pointing to L7 pattern matching, but I can honestly say that I do not know how to implement.
Any pointers would be appreciated.
Thank you.

ingjaab · Tue Oct 15, 2013 11:17 am

hello how would qos, wan, lan1, lan2 , LAN3, lan4, lan5, ... ..........., yes core has 12 ether

thanks

pcunite · Tue Oct 15, 2013 6:23 pm

Might there be a way to add anything to this configuration that would help prioritize streaming video for a home network? Looks as though some of the Netflix traffic for example gets lost in the fray when there is heavy traffic marked as HTTP and the quality tends to suffer. I have seen some stuff pointing to L7 pattern matching, but I can honestly say that I do not know how to implement.

Great question. You must understand that the best way to Qos a network is to have enough bandwidth to work with. People want everything ... but that is a tall order.

Want: VoIP is perfect, file downloads are max speed, video streaming is perfect ... all at the same time!

Wow! I want that too but to achieve this you must have at least 10mb down. Why? Because streaming video is 5mb down! How many users do you have? It gets worse from there.

Currently, the script does find and mark video traffic as "HTTP_BIG". To have what you want you have two options. Keep the script as is but put "HTTP_BIG" into a bigger queue and ensure internet speed is 10mb down and hope that only one user is streaming video.

Or you need to separate video streaming from big downloads. Thus you could use L7 matching or IP's from hulu, YouTube, etc. Once you've separated out your traffic types I would put "VIDEO" into PCC queues. The more users streaming the better PCC will segment them. Naturally, you'll want 5MB per user ... but that is your problem.

You might also tweak what the script marks as "HTTP_BIG". Some sites (like pinterest) have so many images on a single page it looks like streaming video for a short time.

whowantstwoknow · Wed Oct 23, 2013 2:36 am

Hi there,

In my recent thread, part of my goal is to route VOIP traffic from the netgear TA612V through the routerOS router. Came across this thread, now forgive the noob question, but in the context of the scripts in this thread and the interfaces I have (see below), which interfaces are my ether-LAN and ether-WAN?

[admin@MikroTik] /interface> print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE MTU L2MTU MAX-L2MTU
0 R ether1-gateway ether 1500 1598 4074
1 R ether2-master-local ether 1500 1598 4074
2 R ether3-slave-local ether 1500 1598 4074
3 ether4-slave-local ether 1500 1598 4074
4 ether5-slave-local ether 1500 1598 4074
5 R wlan1 wlan 1500 2290
6 R bridge-local bridge 1500 1598

Thanks in advance
W.

2fast4youbr · Fri Nov 22, 2013 10:19 pm

Just did and when a softphone from outside company tries to connect, we can listen anything...

any tips ?

2fast4youbr · Tue Nov 26, 2013 11:37 pm

Cant wait for version 3....

good job, working nice here!

arpiska · Thu Jan 23, 2014 2:07 pm

Please help me how to change this solution, if I have 2 WAN and several LAN interface?
- wan1 60M/3M , wan2 21M/5M
- vlan1, vlan2, vlan3... as local ethernet

TikUser · Mon Feb 10, 2014 3:20 am

[Solved]

mdkberry · Fri Feb 14, 2014 7:33 am

Hi pcunite

great, post and pretty much the only thing out there on VoIP QoS at this level that I can find for Router OS.
have you progressed any yet. There seem to be some key issues still outstanding.

I am about to setup QoS for a VoIP network on an RB2011 which will be competing with other subnet LANS for a 5mbps up and 5mbps down EFM service and I really need to nail the VoIP QoS. Any further reading recommendations... other than who the best support person is to pay to do it at Mikrotik.

Rgds
Mark

Urban! · Fri Feb 14, 2014 3:40 pm

hi pcunite

im using 12M up and 12M Down

how to set the upload rates and download rates in Voip

# 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="LEVEL_A_UP" parent=ether-WAN queue=default max-limit=900k
add name="LEVEL_A_DOWN" parent=ether-LAN queue=default max-limit=4M

# Next, create a queue for high priority traffic.
add name="LEVEL_B_UP" parent=ether-WAN queue=default max-limit=900k
add name="LEVEL_B_DOWN" parent=ether-LAN queue=default max-limit=4M

# Finally, create a queues for traffic that normally exceeds levels.
add name="LEVEL_C_UP" parent=ether-WAN queue=default max-limit=900k
add name="LEVEL_C_DOWN" parent=ether-LAN queue=default max-limit=4M

thanks

pcunite · Fri Feb 14, 2014 3:49 pm

Great post and pretty much the only thing out there on VoIP QoS at this level that I can find for Router OS.
Have you progressed any yet? There seem to be some key issues still outstanding.

Any further reading recommendations ... other than who the best support person is to pay to do it at Mikrotik?

There are a couple of people on the board here who you could pay: efaden, sdischer, or IPANetEngineer. They know what they're doing. I was hoping this post would bring out the VoIP experts but sadly they've not seen it yet. This is something we've all got to get nailed down.

pcunite · Fri Feb 14, 2014 4:03 pm

Hi pcunite. I'm have 12M/12M. How to set the upload rates and download rates for Voip? Thanks.

Make sure you understand how buffering works. Next, it all depends on how many active phone calls you want to support. A single VoIP call is 90kb both directions ... up and down.

With this knowledge, first we chop off 1M/1M (90%) so that the cable/adsl modem does not buffer anything. Next, let's allow for 10 active phone calls: 90kb x 10 = 900kb, which is about 1M. So, 1M for buffering, and 1M for VoIP means we set max-limit to equal 12 - 2 = 10M.

ros code

add name="LEVEL_A_UP"   parent=ether-WAN queue=default max-limit=10M
add name="LEVEL_A_DOWN" parent=ether-LAN queue=default max-limit=10M
add name="LEVEL_B_UP"   parent=ether-WAN queue=default max-limit=10M
add name="LEVEL_B_DOWN" parent=ether-LAN queue=default max-limit=10M
add name="LEVEL_C_UP"   parent=ether-WAN queue=default max-limit=10M
add name="LEVEL_C_DOWN" parent=ether-LAN queue=default max-limit=10M

Just so you know, my VoIP script is not perfect. It works, however. Until you really know how to master segmenting traffic you'll at least have VoIP calls working correctly.

mdkberry · Sun Feb 16, 2014 4:05 am

I would like to adapt pcunite's script to my scenario. and would welcome any suggestions.

my router is RB2011 routerOS 6.7

ISP service is 5mbps up and 5mbps down on EFM (4 wire symmetrical).
this is connected on Eth1 of the router.

I have a VoIP PBX which will make 25 calls max at a time.
this is on the Voice subnet x.x.20.x which is connected to Eth2

the Data LAN is on x.x.10.x connected to Eth3

another subnet is on x.x.88.x connected to Eth4 (but bridged with Eth3)

and there is a WLAN1 interface with x.x.30.x subnet on it.

what I am looking at currently with this is to QoS VoIP traffic on x.x.20.x with a set bandwidth of 2.5mbps each way up and down. to guarantee the VoIP service.and then allow the other subnets to compete for the other 2.5mps ideally using the same queues as in the example from pcunite. Though it would be nice if they could use the remainder of the 5mbps when VoIP isnt being used to the max. In the Cisco configs I have used before the way I dealt with this was to assign QoS as a percentage of bandwidth use and that worked well. I dont see a way to do that with Mikrotiks.

another problem I can't work out yet is how to associate multiple interfaces to a queue, which I will need in this example since I have seperate LANs on seperate interfaces, but they need to use the same queue. I can't bridge the interfaces and apply it there, because two of the subnets have DHCP services and that all stops working when you add bridges in.

EDIT: here are some solutions for my situation so far,

-I have been able to pretty much stick to the script provided by pcunite.
-I included the chains for my PBX using 192.168.20.2 in src-address and another one for dst-address and set ports to 5060, 5061, 10000-20000 on both of those. These are associated to Level A queue.
-all the mangle chains are on prerouting or postrouting including the above ones, instead of forward, though not sure what difference that makes I would be interested to hear comments on that, it seems to work.
-the LEVEL_DOWN queues are all set to parent 'global' resolving the NAT fine, and also multiple subnets/interfaces issue.
-the LEVEL_UP queues set to parent 'ether1-gateway' (the WAN link)
-copy and pasting the script gave me a few issues not sure why, it may have been me accidently clicking fields before saving but it didnt seem to take properly into RouterOS 6.7 and I had to double check some of the mangles to fix a few fields that got dropped randomly, as per my post later on in this thread.
- I have set the Level A queue to 4M/4M, Level B to 3M/3M and Level C to 3M/3M though I am thinking of putting a Queue above Level B and C to max-limit them collectively to 3M to allow the 2M of voip always to be available to Level A. Have to think about that as it may still cause problems for the Level B traffic which can be from my PBX. From my understanding of VoIP so far it is more important to get the ACK and SIP traffic without packet loss than the RTP media traffic which can handle it a little, though it needs to stay below <5% loss.

mdkberry · Tue Feb 18, 2014 2:38 am

Hi pcunite

in testing your script using YouTube media , I am finding that instead of port 80 traffic getting marked with HTTP or HTTP_BIG mark
it is ending up getting marked by the UDP rule in mangle.
if I disable UDP in mangle then it correctly marks the traffic with HTTP or HTTP_BIG

any thoughts on this?

pcunite · Tue Feb 18, 2014 4:22 am

In testing your script using YouTube media, I am finding that instead of port 80 traffic getting marked with HTTP or HTTP_BIG mark it is ending up getting marked by the UDP rule in mangle. If I disable UDP in mangle then it correctly marks the traffic with HTTP or HTTP_BIG.

The order of the rules is important somewhat ... but let me see what you have and I can hopefully spot the error.

mdkberry · Tue Feb 18, 2014 7:15 am

my bad...somehow when I copy-pasted it from your script into the terminal on my router, the UDP mangle didnt copy the protocol for just that mangle.
I just fixed it and everything looks to be ok.

another question, when I copy-pasted, all the mark-connection mangle rules defaulted to "passthrough=yes" should these be set to no?
I can see mark-packet should be set to no, but wasnt clear about the mark-connection default state.

TikUser · Tue Feb 18, 2014 12:52 pm

Hello pcunite! I've noticed something interesting in your rules. Have You used the examples from this Mikrotik wiki for HTTP and HTTP_BIG?
The rule structure is pretty much the same. You are using the same connection rate and connection bytes values. Everything seems fine, except your comment(explanation) for this rules. The author of the wiki talks about 4Mb (500kB), and You about 5MB. The same values, but different explanation.
4Mb (little letter b), 5MB (big letter b).
Mb= megabit
MB= megabyte
This is a huge difference.

SyCo · Tue Feb 18, 2014 2:44 pm

Hello! I've noticed something interesting in your rules. [...]

Nice find! Like you've said it's only in the comments.
I see also that the rule use the correct value of 500kB -> connection-bytes=500000-0

Then we simply need to change the comments

BTW on that same line there is also a little typo where it's written "tranfers" instead of "tranSfers".

mdkberry · Wed Feb 19, 2014 6:38 am

another router setup using the same script and I am seeing HTTP_D traffic which is supposed to be priority 1 being dropped before the other traffic in Level C which is lower priority.
any thoughts? piccy attached.

dropped_packets.tiff

TikUser · Wed Feb 19, 2014 12:52 pm

another router setup using the same script and I am seeing HTTP_D traffic which is supposed to be priority 1 being dropped before the other traffic in Level C which is lower priority.
any thoughts? piccy attached.
dropped_packets.tiff

I. Reduce the number of Queue Trees to 2. One for download & one upload. Your goal is to create a unified hierarchy.
Like this:
Queue Tree - download(the same for upload).
1. DNS - Priority 1
2. ICMP - Priority 1
3. VOIP -Priority 2
4. ACK - Priority 3
5. HTTP - Priority 4
6. HTTP_BIG - Priority 5
7. UDP - Priority 7
8. OTHER - Priority 8

II. Or rearrange the Queue Tree. Look at the picture in the attachment. The picture isn’t something, but it serves the purpose.

Merge level B & C into one queue tree. VOIP (level A) remains in its queue. At the top create the total download bandwidth queue, with VOIP (level A) and Everything else (level B+ level C) as its children.
Read this Mikrotik wiki for more information.

P.s. For the Queue Tree - download, You also need to use the HTB Interface as parent. NOT global. Global is not good for this examples. It is used for another type of QoS.

TikUser · Wed Feb 19, 2014 8:53 pm

another problem I can't work out yet is how to associate multiple interfaces to a queue, which I will need in this example since I have seperate LANs on seperate interfaces, but they need to use the same queue. I can't bridge the interfaces and apply it there, because two of the subnets have DHCP services and that all stops working when you add bridges in.

The pcunite examples won't work well in Your case. You need to create another set of mangle and Queue Tree rules.
- Replace prerouting with the forward chain for traffic going through the router.
- Use src-address-list(your network) + out. interface(WAN-Internet) for marking the connections going through the router(forward chain) to the internet and backwards.
- Create separate mangle rules for marking the download(Internet->LAN) and upload(LAN->Internet) packets from these connections.

- Replace postrouting with the output chain for traffic from the router to the internet. If needed, use out. interface option in order to make the connections in the output chain more precise.
- Create separate mangle rules for marking the download and upload packets from these connections. Which means: Packets coming from the internet to the router (Internet->router), and packets going from the router to the internet (router->Internet).

"We think of Connections as "Both Upload and Download" since most connections have packets in both directions. We think of Packets as either "Download" or "Upload"." Quoted from: NetworkPro on Quality of Service
Watch out how you order the rules!

- Now you can use parent global in Queue Tree for creating the download and upload tree. You must not use the HTB Interface (ether1, ether2,...) in Queue Tree as the parent for the download and upload queue, because You have more than 1 active LAN interfaces, which, as You said, mustn't be bridged.

This is out-of-my-head solution.

Not tested. Test it and adapt it to your needs. This is not the only possibility. For every problem, there are a couple of solutions.

And most important: You need to understand the packet flow, Queue Tree and prerouting, forward, output, postrouting chain in order to know where to apply what, and why. Until You know what You are doing, a router without prioritization is a better solution than a router with a false implemented prioritization.

Search the Mikrotik forum and You will find the answer to: “another question, when I copy-pasted, all the mark-connection mangle rules defaulted to "passthrough=yes" should these be set to no? I can see mark-packet should be set to no, but wasnt clear about the mark-connection default state.“

In most of the cases, when You mark the connections, use passthrough=yes. When You mark the packets, use passthrough=no.

pcunite · Wed Feb 19, 2014 9:47 pm

I am seeing HTTP_D traffic (which is priority 1) being dropped before other traffic in Level C, which has a lower priority.

Notes:
To QoS traffic with a MikroTik you have to be an expert and really understand their documentation. I am not an expert. Please note that my QoS script is for VoIP packet protection. I don't ever want to drop a VoIP packet ... ever ... never. You need to do extensive reading on the subject if you want to design a QoS system that differs from the one I've created.

Terms:
priority means 'drop packets' WHEN needed.
max-limit means to drop packets ONLY when exceeded.

Explanation:
If over 1M of HTTP_D traffic appears then they'll get dropped. I don't know how many PC's you have on your network, but it is real easy to exceed 1M from casual browsing. If you have over 1M of HTTP_D and HTTP_BIG_D at the exact same time then priority is calculated between the two.

TecnoNet · Sat Feb 22, 2014 10:05 am

Note: ehter1--REAL--MAIN is the internet from the ISP,
and in this QOS we Limit the HEAVY DOWNLOAD DATA and leave the rest

mdkberry · Wed Feb 26, 2014 1:07 am

thanks for all the input those that have posted that really helps. I will test it TikUser ideas out and let you know how it goes.

one thing I noticed when I tried pcunite's script tailored in the way I mentioned. once the PBX started distributing calls outbound
all the VoIP traffic ended up marked with PBX_UDP up or down as I expected, but all the actual queue traffic was in Level B under ACK and UDP. hardly any showed up in Level A VoIP despite it being marked from the PBX server fine.

anyway I had to strip out all the marking and queue info anyway as it wasnt working for my setup.

pcunite, in answer to your comment about 1M being a low limit the voice network is setup to have only phones on it, and minimal HTTP traffic should be on it. it was working ok and no prioritising was going on. that idea was really to capture anyone accidently plugging into a voice network floor port and surfing the voice network into a grinding halt.

to be continued...

RB951G2HnD · Mon Mar 24, 2014 8:11 pm

TecnoNet,

Thank you for a good QoS config script. It seems that it's working fine except P2P. In our days the most of P2P clients are using encryption and that is the reason why a simple indicated P2P option is not working in a Mikrotik ROS. I think that to make this QoS config script working with torrent's traffic we need to specify incoming ports in P2P client. For example to use incoming ports from 6881 to 6891. If it so then we need to change Mangle rule for P2P. How to relate this rule with the dedicated ports?

ros code

add action=mark-connection chain=postrouting comment="P2P UP" new-connection-mark=p2pupconn out-interface=ether1 p2p=all-p2p
add action=mark-packet chain=postrouting connection-mark=p2pupconn new-packet-mark=p2pup passthrough=no
add action=mark-connection chain=prerouting comment="P2P DOWN" in-interface=ether1 new-connection-mark=p2pdownconn p2p=all-p2p
add action=mark-packet chain=prerouting connection-mark=p2pdownconn new-packet-mark=p2pdown passthrough=no

RB951G2HnD · Wed Mar 26, 2014 10:36 am

No QoS config provided by TecnoNet is not working because all traffic marked as 'other' including http and etc. So the attached config file is wrong.

RB951G2HnD · Fri Mar 28, 2014 5:36 am

Yesterday I was able to slightly adjust QoS priorities. But somehow torrent traffic clogs channel so that for example in parallel to watch youtube is not possible. Torrent traffic is marked in the Mangle rules correctly. Please prompt me where to look and what needs to be corrected into config?

ros code

/queue tree
add max-limit=2800k name=LEVEL_A_UP parent=ether1 priority=7 queue=default
add max-limit=2800k name=LEVEL_A_DOWN parent=ether2 priority=7 queue=default
add max-limit=2800k name=LEVEL_B_UP parent=ether1 priority=7 queue=default
add max-limit=2800k name=LEVEL_B_DOWN parent=ether2 priority=7 queue=default
add max-limit=2800k name=LEVEL_C_UP parent=ether1 queue=default
add max-limit=2800k name=LEVEL_C_DOWN parent=ether2 queue=default
add name=ACK_U packet-mark=ACK parent=LEVEL_A_UP priority=1 queue=default
add name=ACK_D packet-mark=ACK parent=LEVEL_A_DOWN priority=1 queue=default
add name=DNS_U packet-mark=DNS parent=LEVEL_A_UP priority=2 queue=default
add name=DNS_D packet-mark=DNS parent=LEVEL_A_DOWN priority=2 queue=default
add name=ICMP_U packet-mark=ICMP parent=LEVEL_A_UP priority=3 queue=default
add name=ICMP_D packet-mark=ICMP parent=LEVEL_A_DOWN priority=3 queue=default
add name=UDP_U packet-mark=UDP parent=LEVEL_B_UP priority=1 queue=default
add name=UDP_D packet-mark=UDP parent=LEVEL_B_DOWN priority=1 queue=default
add name=OTHER_U packet-mark=OTHER parent=LEVEL_C_UP priority=1 queue=default
add name=OTHER_D packet-mark=OTHER parent=LEVEL_C_DOWN priority=1 queue=default
add name=HTTP_U packet-mark=HTTP parent=LEVEL_B_UP priority=3 queue=default
add name=HTTP_D packet-mark=HTTP parent=LEVEL_B_DOWN priority=3 queue=default
add name=HTTP_BIG_U packet-mark=HTTP_BIG parent=LEVEL_B_UP priority=3 queue=default
add name=HTTP_BIG_D packet-mark=HTTP_BIG parent=LEVEL_B_DOWN priority=3 queue=default
add name=E-MAIL_U packet-mark=E-MAIL parent=LEVEL_B_UP priority=2 queue=default
add name=E-MAIL_D packet-mark=E-MAIL parent=LEVEL_B_DOWN priority=2 queue=default
add name=TCP_TORRENT_U packet-mark=TCP_TORRENT parent=LEVEL_C_UP priority=2 queue=default
add name=TCP_TORRENT_D packet-mark=TCP_TORRENT parent=LEVEL_C_DOWN priority=2 queue=default
add name=UDP_TORRENT_U packet-mark=UDP_TORRENT parent=LEVEL_C_UP priority=2 queue=default
add name=UDP_TORRENT_D packet-mark=UDP_TORRENT parent=LEVEL_C_DOWN priority=2 queue=default
/ip firewall mangle
add action=mark-connection chain=prerouting comment=DNS connection-state=new new-connection-mark=DNS port=53 protocol=udp
add action=mark-packet chain=prerouting connection-mark=DNS new-packet-mark=DNS passthrough=no
add action=mark-connection chain=postrouting connection-state=new new-connection-mark=DNS port=53 protocol=udp
add action=mark-packet chain=postrouting connection-mark=DNS new-packet-mark=DNS passthrough=no
add action=mark-connection chain=prerouting comment=ICMP connection-state=new new-connection-mark=ICMP protocol=icmp
add action=mark-packet chain=prerouting connection-mark=ICMP new-packet-mark=ICMP passthrough=no
add action=mark-connection chain=postrouting connection-state=new new-connection-mark=ICMP protocol=icmp
add action=mark-packet chain=postrouting connection-mark=ICMP new-packet-mark=ICMP passthrough=no
add action=mark-packet chain=postrouting comment=ACK new-packet-mark=ACK packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=prerouting new-packet-mark=ACK packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-connection chain=prerouting comment=UDP_TORRENT connection-state=new new-connection-mark=UDP_TORRENT port=6881-6891 protocol=udp
add action=mark-packet chain=prerouting connection-mark=UDP_TORRENT new-packet-mark=UDP_TORRENT passthrough=no
add action=mark-connection chain=prerouting comment=UDP connection-state=new new-connection-mark=UDP protocol=udp
add action=mark-packet chain=prerouting connection-mark=UDP new-packet-mark=UDP passthrough=no
add action=mark-connection chain=prerouting comment=E-MAIL connection-state=new new-connection-mark=E-MAIL port=110,995,143,993,25,465,587,2525 protocol=tcp
add action=mark-packet chain=prerouting connection-mark=E-MAIL new-packet-mark=E-MAIL passthrough=no
add action=mark-connection chain=prerouting comment=HTTP connection-mark=!HTTP_BIG connection-state=new new-connection-mark=HTTP port=80,443 protocol=tcp
add action=mark-connection chain=prerouting connection-bytes=500000-0 connection-mark=HTTP connection-rate=200k-100M new-connection-mark=HTTP_BIG protocol=tcp
add action=mark-packet chain=prerouting connection-mark=HTTP_BIG new-packet-mark=HTTP_BIG passthrough=no
add action=mark-packet chain=prerouting connection-mark=HTTP new-packet-mark=HTTP passthrough=no
add action=mark-connection chain=prerouting comment=TCP_TORRENT connection-state=new new-connection-mark=TCP_TORRENT port=6881-6891 protocol=tcp
add action=mark-packet chain=prerouting connection-mark=TCP_TORRENT new-packet-mark=TCP_TORRENT passthrough=no
add action=mark-connection chain=prerouting comment=OTHER connection-mark=no-mark new-connection-mark=OTHER
add action=mark-packet chain=prerouting connection-mark=OTHER new-packet-mark=OTHER passthrough=no

Rudios · Fri Mar 28, 2014 8:22 am

I'm a little curious why you have some rules twice

ros code

/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"

You are marking packets twice based on the same options. In my opinion rule 2 can be removed.
Then first there are two rules marking the connection and setting connection-marks. Then use the connection-mark to mark the packets in one single rule.

mdkberry · Thu May 22, 2014 6:30 am

Ok been a while since I was on this thread but I have tried the above setup and run into a strange problem where marking the packets stops some web sites being available. I am not sure what is causing it and hoped someone could look at the below Mangle rules and tell me.

I have enabled everything except HTTP, HTTP_BIG and one I called 'THE_REST' because when I enabled these no one could access various web sites, such as http://www.adobe.com http://www.sybase.com and a host of others. It was always the same web sites and lots of them, until I disabled those three rules then it works fine, I am not sure if the other traffic like ACK or DNS is having a problem but no one has complained and it has been up a couple of days like this now.

I assume this is because those disabled rules are stopping the traffic flow passing to the dynamic rule set that appeared after I configured the PPPoE TPG fibre gateway. I have added those two dynamic rules in at the end of this post.

should just marking traffic cause it to stop going out the normal route? or have I done something wrong that I cant see here?

my mangle rules:

0   ;;; VOIP - Voip traffic FROM PBX (5060-5061, 10000-20000 udp)
     chain=forward action=mark-connection new-connection-mark=VOIP passthrough=yes connection-state=new protocol=udp
     src-address=10.10.20.5 port=5060-5061,10000-20000

 1   chain=forward action=mark-packet new-packet-mark=VOIP passthrough=no connection-mark=VOIP

 2   ;;; VOIP - Voip traffic TO PBX (5060-5061, 10000-20000 udp)
     chain=output action=mark-connection new-connection-mark=VOIP passthrough=yes connection-state=new protocol=udp
     dst-address=10.10.20.5 port=5060-5061,10000-20000

 3   chain=output action=mark-packet new-packet-mark=VOIP passthrough=no connection-mark=VOIP

 4   ;;; V_GENERAL - other traffic FROM voice network
     chain=forward action=mark-connection new-connection-mark=V_GENERAL passthrough=yes src-address-list=VoIP_Network
     connection-mark=no-mark

 5   chain=forward action=mark-packet new-packet-mark=V_GENERAL passthrough=no connection-mark=V_GENERAL

 6   ;;; V_GENERAL - other traffic TO voice network
     chain=output action=mark-connection new-connection-mark=V_GENERAL passthrough=yes dst-address-list=VoIP_Network
     connection-mark=no-mark

 7   chain=output action=mark-packet new-packet-mark=V_GENERAL passthrough=no connection-mark=V_GENERAL

 8   ;;; DNS
     chain=forward action=mark-connection new-connection-mark=DNS passthrough=yes connection-state=new protocol=udp port=53

 9   chain=forward action=mark-packet new-packet-mark=DNS passthrough=no connection-mark=DNS

10   chain=output action=mark-connection new-connection-mark=DNS passthrough=yes connection-state=new protocol=udp port=53

11   chain=output action=mark-packet new-packet-mark=DNS passthrough=no connection-mark=DNS

12   ;;; UDP
     chain=forward action=mark-connection new-connection-mark=UDP passthrough=yes connection-state=new protocol=udp

13   chain=forward action=mark-packet new-packet-mark=UDP passthrough=no connection-mark=UDP

14   ;;; ICMP
     chain=forward action=mark-connection new-connection-mark=ICMP passthrough=yes connection-state=new protocol=icmp

15   chain=forward action=mark-packet new-packet-mark=ICMP passthrough=no connection-mark=ICMP

16   chain=output action=mark-connection new-connection-mark=ICMP passthrough=yes connection-state=new protocol=icmp

17   chain=output action=mark-packet new-packet-mark=ICMP passthrough=no connection-mark=ICMP

18   ;;; ACK
     chain=output action=mark-packet new-packet-mark=ACK passthrough=no tcp-flags=ack protocol=tcp packet-size=0-123

19   chain=forward action=mark-packet new-packet-mark=ACK passthrough=no tcp-flags=ack protocol=tcp packet-size=0-123

20 X ;;; HTTP
     chain=forward action=mark-connection new-connection-mark=HTTP passthrough=yes connection-state=new protocol=tcp
     port=80,443 connection-mark=!HTTP_BIG

21 X chain=forward action=mark-connection new-connection-mark=HTTP_BIG passthrough=yes protocol=tcp connection-mark=HTTP
     connection-bytes=500000-0 connection-rate=200k-100M

22 X chain=forward action=mark-packet new-packet-mark=HTTP_BIG passthrough=no connection-mark=HTTP_BIG

23 X chain=forward action=mark-packet new-packet-mark=HTTP passthrough=no connection-mark=HTTP

24 X ;;; THE_REST
     chain=forward action=mark-connection new-connection-mark=THE_REST passthrough=yes connection-mark=no-mark

25 X chain=forward action=mark-packet new-packet-mark=THE_REST passthrough=no connection-mark=THE_REST

Below are the dynamic rules in place from the PPPoE gateway , they are the last two rules in my mangle list but dont show when doing a print from command line.

chain=forward
protocol= tcp
in interface = all ppp
TCP MSS = 1441-65535
TCP Flags = syn
action = change MSS
new TCP MSS = 1440
(no traffic through this as yet)

chain=forward
protocol = tcp
out.interface = all ppp
TCP MSS = 1441-65535
TCP Flags = syn
action = change MSS
new TCP MSS = 1440
passthrough= ticked
(quite a lot of traffic has passed through this rule)

pcunite · Sun May 25, 2014 4:25 pm

I'm a little curious why you have some rules twice.
ros code
/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
You are marking packets twice based on the same options. In my opinion rule 2 can be removed.
Then first there are two rules marking the connection and setting connection-marks. Then use the connection-mark to mark the packets in one single rule.

This section is from Option 1. It is marking "src" and then "dst" to the same ip address. Also, unless MikroTik documentation has changed, one must mark the connection and then the packet for performance.

TikUser · Thu May 29, 2014 6:44 pm

Hey mdkberry,
it would be good to give us a visual scheme of your network. So, we could easily see what goes where.

First, do you want to do QoS for traffic going/coming to/from the internet, or for all the traffic?
If it's the Internet, then your mangle rules need to be more precise.
Example (imprecise rule):

add action=mark-connection chain=forward connection-state=new new-connection-mark=UDP protocol=udp

This rule catches ALL the udp traffic going through your router. Not only internet udp traffic. If you have users on ether3, ether4 and ether 5 and they are communicating with each other, then this rule will also catch their udp inside the network traffic.

You said that your internet speed is 5Mb up/down. If your network is connected with Ethernet cables, then you have at least 100Mb of available bandwidth inside your network. QoS for inside traffic is NOT needed, because you have more than enough bandwidth.
If your internet connection is on ether1, then change the rule:

add action=mark-connection chain=forward connection-state=new new-connection-mark=UDP out-interface=ether1 protocol=udp
add action=mark-packet chain=forward connection-mark=UDP new-packet-mark=UDP passthrough=no

With this rule you are cathing all the udp connections going to the internet. You don't need to specify the mark-packet rule, because it uses the data from the mark-connection rule.

Why are you using output chain for the VoIP traffic to PBX and other traffic to voice network? Output chain means only traffic that is generated by the Mikrotik router.
If you have a scheme: PBX VOIP <-> Mikrotik-router <-> Internet, then the output chain will NOT catch this traffic, unless you have modified the ROS to redirect the VoIP traffic to the router itself and then to other interfaces.
Try with this rules:

add action=mark-connection chain=forward connection-state=new new-connection-mark=VOIP out-interface=ether1 port=5060-5061,10000-20000 protocol=udp src-address=10.10.20.5 
add action=mark-connection chain=forward connection-state=new dst-address=10.10.20.5 in-interface=ether1 new-connection-mark=VOIP port=5060-5061,10000-20000 protocol=udp

First mark-connection rule catches voip connections initiated from 10.10.20.5 and going to the internet(ether1). Second mark-connection rule catches connections initiated from the internet(ether1) and going to 10.10.20.5.
If on 10.10.20.5 you only have the PBX, you can remove ports and protocol from these rules. Also replace the connection-mark=no-mark with connection-state=new in rules 4 and 6.

If I were at your place, I would remove the udp rules 12 and 13 completely because, for your configuration, they don’t make any sense.
And I would integrate the ACK rules with the HTTP and HTTP_BIG rules. Like this:

add action=mark-packet chain=forward connection-mark=HTTP_BIG new-packet-mark=ACK-HTTP-BIG packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=forward connection-mark=HTTP new-packet-mark=ACK-HTTP packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack

These rules catch the ack packets from HTTP & HTTP_BIG connections. Put them AFTER the HTTP & HTTP_BIG mark-connection rules, and BEFORE the HTTP & HTTP_BIG mark-packet rules.
Example:
1. HTTP mark-connection rule
2. HTTP_BIG mark-connection rule
3. ACK-HTTP-BIG mark-packet rule
4. ACK-HTTP mark-packet rule
5. HTTP_BIG mark-packet rule
6. HTTP mark-packet rule

About the PPPOE. You will need to play with this.

I don't have a PPPOE configuration (yet), so I can't help you in this field.
- Disable all the static mangle rules.
- Check if traffic is flowing through both dynamic pppoe rules.
- Change the MSS size, if needed.
- Change the Max UDP Packet size in DNS Settings, if needed.
- Try with putting the dynamic mangle rules above all static mangle rules.
- Search this forum for more information about ppp dynamic rules and mss size.

beb · Thu Jun 26, 2014 3:58 am

How Buffering and bufferbloat in ISP supplied equipment affects Qos and latency sensitive protocols ...

Thank you for this great explanation!

Am I correct in my conclusion that without a reasonable estimate of my wan bandwidth, it's impossible to implement qos?

Specifically - I have Comcast (cable) and the download speed varies between 60Mbps and 5Mbps, depending on the time-of-day, phase of the moon, and Comcast's share price. If I understand correctly, if I want to implement qos I need to set the maximum limit to <5Mbps. This of course suffices for VOIP, but gives me much less than available bandwidth most of the time.

A bit sobering, but at least I am not wasting my time trying to fix something I cannot.

Correct?

pcunite · Fri Jun 27, 2014 9:09 pm

Am I correct in my conclusion that without a reasonable estimate of my wan bandwidth, it's impossible to implement qos? Specifically - I have Comcast (cable) and the download speed varies between 60Mbps and 5Mbps

That is quite a variance! Yes, you are correct ... you can not use "static Qos" techniques to maintain your traffic integrity. There are "dynamic Qos" ways of doing things but that is beyond the scope of this thread and my expertise.

war3boy · Sun Jun 29, 2014 4:16 pm

Hi Guys,

Need some light for the Latency QoS. I try to shape but seem it failed to do so.
I knew we can use bandwidth control to guarantee the bandwidth for gaming , but i wish can fully utilize the bandwidth when the game is not in play.
But when the game is in play, the QoS will do it work to keep the game latency as usual.

ros code

# jun/29/2014 21:38:22 by RouterOS 6.12
# software id = AF8C-ZI5T
#
/ip firewall mangle
#Skype Layer7 Marking
add action=mark-packet chain=prerouting comment=Skype in-interface=PPPoE-UniFi layer7-protocol=skypetoskype new-packet-mark=QoS_1_In passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=skypetoskype new-packet-mark=QoS_1_Out out-interface=PPPoE-UniFi passthrough=no

#VPN Layer 7 Marking
add action=mark-packet chain=prerouting comment=VPN in-interface=PPPoE-UniFi new-packet-mark=QoS_2_In passthrough=no protocol=gre
add action=mark-packet chain=postrouting new-packet-mark=QoS_2_Out out-interface=PPPoE-UniFi passthrough=no protocol=gre

#QoS_4 Steaming Layer 7 Marking
add action=mark-packet chain=prerouting comment="------------QoS_4 [Streaming_Services]------------" in-interface=PPPoE-UniFi layer7-protocol=Streaming new-packet-mark=QoS_4_In passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=Streaming new-packet-mark=QoS_4_Out out-interface=PPPoE-UniFi passthrough=no
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi layer7-protocol=video new-packet-mark=QoS_4_In passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=video new-packet-mark=QoS_4_Out out-interface=PPPoE-UniFi passthrough=no

#QoS_8 Torrent Layer 7 Marking
add action=mark-packet chain=prerouting comment="------------QoS_8 [Torrent_Services]------------" in-interface=PPPoE-UniFi layer7-protocol=Torrent-wwws new-packet-mark=QoS_8_In passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=Torrent-wwws new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi passthrough=no
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi layer7-protocol=torrentDNS new-packet-mark=QoS_8_In passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=torrentDNS new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi passthrough=no
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi new-packet-mark=QoS_8_In p2p=all-p2p passthrough=no
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi p2p=all-p2p passthrough=no

#QoS_1 Steam
add action=mark-packet chain=prerouting comment="------------QoS_1 [Steam]------------" in-interface=PPPoE-UniFi new-packet-mark=QoS_1_In passthrough=no protocol=tcp src-port=27014-27050
add action=mark-packet chain=postrouting dst-port=27014-27050 new-packet-mark=QoS_1_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi new-packet-mark=QoS_1_In passthrough=no protocol=udp src-port=3478,4379,4380,28960,27000-27030
add action=mark-packet chain=postrouting dst-port=3478,4379,4380,28960,27000-27030 new-packet-mark=QoS_1_Out out-interface=PPPoE-UniFi passthrough=no protocol=udp

#QoS_2 DNS
add action=mark-packet chain=prerouting comment="------------QoS_2 [DNS+NTP_PPTP_Services]------------" in-interface=PPPoE-UniFi new-packet-mark=QoS_2_In passthrough=no protocol=udp src-port=53,123,1723
add action=mark-packet chain=postrouting dst-port=53,123,1723 new-packet-mark=QoS_2_Out out-interface=PPPoE-UniFi passthrough=no protocol=udp
add action=mark-packet chain=prerouting connection-state=new in-interface=PPPoE-UniFi new-packet-mark=QoS_2_In passthrough=no protocol=tcp src-port=52,123,1723
add action=mark-packet chain=postrouting dst-port=52,123,1723 new-packet-mark=QoS_2_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp

#QoS_3 WWW Services + General_Services
add action=mark-packet chain=prerouting comment="------------QoS_3 [WWW_Services]------------" connection-bytes=0-1500000 in-interface=PPPoE-UniFi new-packet-mark=QoS_3_In passthrough=no protocol=tcp src-port=80,443
add action=mark-packet chain=postrouting connection-bytes=0-1500000 dst-port=80,443 new-packet-mark=QoS_3_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp
add action=mark-packet chain=prerouting comment="------------QoS_3 [General_Services]------------" in-interface=PPPoE-UniFi new-packet-mark=QoS_3_In passthrough=no protocol=tcp src-port=20,21,22,23,25,110,143,465,587,993,995,2525,3535
add action=mark-packet chain=postrouting dst-port=20,21,22,23,25,110,143,465,587,993,995,2525,3535 new-packet-mark=QoS_3_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp

#QoS_5 WWW_Heavy
add action=mark-packet chain=prerouting comment="------------QoS_5 [WWW_Services_Heavy]------------" connection-bytes=1500000-0 in-interface=PPPoE-UniFi new-packet-mark=QoS_5_In passthrough=no protocol=tcp src-port=80,443
add action=mark-packet chain=postrouting connection-bytes=1500000-0 dst-port=80,443 new-packet-mark=QoS_5_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp

#QoS_8 Other BULK
add action=mark-packet chain=prerouting comment="------------QoS_8 [Other_Services]------------" in-interface=PPPoE-UniFi new-packet-mark=QoS_8_In passthrough=no protocol=tcp
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi passthrough=no protocol=tcp
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi new-packet-mark=QoS_8_In passthrough=no protocol=udp
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi passthrough=no protocol=udp
add action=mark-packet chain=prerouting in-interface=PPPoE-UniFi new-packet-mark=QoS_8_In passthrough=no
add action=mark-packet chain=postrouting new-packet-mark=QoS_8_Out out-interface=PPPoE-UniFi passthrough=no

ros code

# jun/29/2014 21:27:09 by RouterOS 6.12
# software id = AF8C-ZI5T
#
/queue tree

#Upload
add max-limit=4700k name=QoS_Global_Upload parent=global queue=default
add limit-at=512k max-limit=3M name="QoS_1_Out(Steam)" packet-mark=QoS_1_Out parent=QoS_Global_Upload priority=1 queue=default
add limit-at=100k max-limit=1M name="QoS_2_Out(DNS+NTP+PPTP)" packet-mark=QoS_2_Out parent=QoS_Global_Upload priority=2 queue=default
add limit-at=1500k max-limit=4M name="QoS_3_Out(WWW)" packet-mark=QoS_3_Out parent=QoS_Global_Upload priority=3 queue=default
add burst-limit=3800k burst-time=3s max-limit=3M name="QoS_4_Out(Streaming)" packet-mark=QoS_4_Out parent=QoS_Global_Upload priority=4 queue=default
add burst-limit=3800k burst-time=3s max-limit=3M name="QoS_5_Out(WWW_Heavy)" packet-mark=QoS_5_Out parent=QoS_Global_Upload priority=5 queue=default
add burst-limit=4300k burst-time=3s max-limit=3500k name="QoS_8_Out(Default)" packet-mark=QoS_8_Out parent=QoS_Global_Upload queue=pcq-upload-default

#Download
add max-limit=4800k name=QoS_Global_Download parent=global queue=default
add limit-at=512k max-limit=3M name="QoS_1_In(Steam)" packet-mark=QoS_1_In parent=QoS_Global_Download priority=1 queue=default
add limit-at=100k max-limit=500k name="QoS_2_In(DNS+NTP+PPTP)" packet-mark=QoS_2_In parent=QoS_Global_Download priority=2 queue=default
add burst-limit=3M burst-threshold=2M burst-time=5s limit-at=1500k max-limit=2M name="QoS_3_In(WWW)" packet-mark=QoS_3_In parent=QoS_Global_Download priority=3 queue=default
add burst-limit=2500k burst-threshold=1M burst-time=5s max-limit=1M name="QoS_4_In(Streaming)" packet-mark=QoS_4_In parent=QoS_Global_Download priority=4 queue=default
add burst-limit=3800k burst-time=2s max-limit=1M name="QoS_5_In(WWW_Heavy)" packet-mark=QoS_5_In parent=QoS_Global_Download priority=5 queue=default
add burst-limit=4300k burst-threshold=4M burst-time=3s max-limit=3M name="QoS_8_In(Default+Torrent)" packet-mark=QoS_8_In parent=QoS_Global_Download queue=pcq-download-default

ceather93 · Fri Sep 12, 2014 5:56 am

Hi,

I am getting a bit confused with this. Wondering if someone could help me out.

I am trying to achieve the following in terms of QoS - in that order

1) All WAN related UDP connections
2) All Connections from and to Certain Address List
3) All Connections from and to a different address List
4) All Other Traffic
5) File Sharing/Torrents

I think I am stumbling on the packet flow part and why you need to set a limit on the LAN side of things in the queuing?
Other question is for the mangle do you need to make a separate rule for both outgoing and incoming traffic eg:

 2 X ;;; LYNC | Mark new source connections
     chain=forward action=mark-connection new-connection-mark=Lync-Connected
     passthrough=yes connection-state=new src-address-list=Lync in-interface=TPG PPPoe

 3 X ;;; LYNC | Mark Packet
     chain=forward action=mark-packet new-packet-mark=Lync_Packet passthrough=yes
     connection-mark=Lync-Connected

 4 X ;;; LYNC | Mark new dest connections
     chain=forward action=mark-connection new-connection-mark=Lync-Connected
     passthrough=yes connection-state=new dst-address-list=Lync
     out-interface=TPG PPPoe

 5 X ;;; LYNC | Mark Packet
     chain=forward action=mark-packet new-packet-mark=Lync_Packet passthrough=no
     connection-mark=Lync-Connected

Interaces:

Bridge Called 'Bridge' (Ether2 in it - connected to switch)
PPPoE Client called 'PPPoE' assigned to Ether1

vamose · Tue Mar 03, 2015 7:51 pm

Guys,

I bought the Mikrotik router and used AP and PPOE settings to enable the router and my ISP provider.

I have 10MBs service, but when I use speediest websites such as testmy.net net performance maxes out at 3.2MBps.

I need your help with streamlining my configuration and with QOS. The requirement for QOS is as per the priority listed, can any one help me.

VOIP
Streaming video content - You tube
SSH
FTP
Downloading
Torrent downloads.

toxicfusion · Tue Mar 17, 2015 8:57 pm

Hi

I've followed this guide... and have made adjustments to try and fix issues.

However, when ever I have queue tree rules created for 'no-mark'. The router is ALSO clamping the LAN network file transfer speeds... not cool.

/queue tree
add max-limit=4M name=LEVEL_A_UP parent=ether1_wan01 queue=default
add max-limit=22M name=LEVEL_A_DOWN parent=TRNK_LAN queue=default
add limit-at=3799k max-limit=3880k name=VOIP_UP packet-mark=VOIP parent=\
LEVEL_A_UP priority=1 queue=default
add limit-at=20M max-limit=22M name=VOIP_DWN packet-mark=VOIP parent=\
LEVEL_A_DOWN priority=1 queue=default
add name=DNS_UP packet-mark=DNS parent=LEVEL_A_UP priority=2 queue=default
add name=DNS_DWN packet-mark=DNS parent=LEVEL_A_DOWN priority=2 queue=default
add max-limit=60M name=LEVEL_B_DOWN parent=TRNK_LAN queue=default
add max-limit=3800k name=LEVEL_B_UP parent=ether1_wan01 queue=default
add limit-at=2600k max-limit=3M name=HTTP_UP packet-mark=HTTP parent=LEVEL_B_UP \
priority=2 queue=default
add limit-at=59M max-limit=60M name=HTTP_DWN packet-mark=HTTP parent=\
LEVEL_B_DOWN priority=2 queue=default
add limit-at=2800k max-limit=3M name=HTTP_Traff packet-mark=HTTP_Traff parent=\
LEVEL_B_UP priority=2 queue=default
add limit-at=2800k max-limit=3M name=HTTPS_up packet-mark=HTTPS parent=\
LEVEL_B_UP priority=2 queue=default
add limit-at=58M max-limit=60M name=HTTPS_Down packet-mark=HTTPS parent=\
LEVEL_B_DOWN priority=2 queue=default
add limit-at=55M max-limit=58M name=IPSEC_Down packet-mark=IPSEC parent=\
LEVEL_B_DOWN priority=2 queue=default
add limit-at=2800k max-limit=3M name=IPSEC_OUT_IN packet-mark=IPSEC parent=\
LEVEL_B_UP priority=3 queue=default
add disabled=yes limit-at=58M max-limit=60M name=misc_down packet-mark=no-mark \
parent=LEVEL_B_DOWN priority=3 queue=default

kivimart · Thu Mar 19, 2015 10:46 pm

This is my queue tree, no limits set only trying to learn how to mark packet and queue then then later set limits.

I do not use VOIP in my setup...

If you post your Mangle rules there will be easier to help you with your problem on local traffic hitting queues.
I am no expert on queues but will help you as much as i can.

My routerboard is a RB850Gx2

Gateway interface Name=GW1

/ip firewall layer7-protocol
add name=bittorrent regexp="^(\\x13bittorrent protocol|azver\\x01\$|get /scrape\\\?info_hash=ge\
t /announce\\\?info_hash=|get /client/bitcomet/|GET /data\\\?fid=)|d1:ad2:id20:|\\x08'7P\\)\
[RP]"
add name=streaming regexp=videoplayback|video|stream
add name=streaming-audio regexp=audioplayback|audio

/ip firewall mangle
add action=mark-connection chain=prerouting comment=DNS-IN new-connection-mark=DNS port=53 \
protocol=udp
add action=mark-packet chain=prerouting connection-mark=DNS new-packet-mark=DNS passthrough=no
add action=mark-connection chain=output comment=DNS-UT new-connection-mark=DNS_UP port=53 \
protocol=udp
add action=mark-packet chain=output connection-mark=DNS_UP new-packet-mark=DNS_UP passthrough=\
no
add action=mark-connection chain=prerouting comment=ICMP-IN in-interface=GW1 \
new-connection-mark=ICMP-CON protocol=icmp
add action=mark-packet chain=prerouting connection-mark=ICMP-CON new-packet-mark=ICMP \
passthrough=no
add action=mark-connection chain=postrouting comment=ICMP-UT new-connection-mark=ICMP_UP-CON \
out-interface=GW1 protocol=icmp
add action=mark-packet chain=postrouting connection-mark=ICMP_UP-CON new-packet-mark=ICMP_UP \
passthrough=no
add action=mark-connection chain=prerouting comment="WinBox, Sniffer" new-connection-mark=\
WinBox-CON port=8291,8081 protocol=tcp
add action=mark-packet chain=prerouting connection-mark=WinBox-CON new-packet-mark=WinBox \
passthrough=no
add action=mark-connection chain=postrouting comment="WinBox, Sniffer-UT" new-connection-mark=\
WinBox-CON_UP port=8291,8081 protocol=tcp
add action=mark-packet chain=postrouting connection-mark=WinBox-CON_UP new-packet-mark=\
WinBox_UP passthrough=no
add action=mark-connection chain=prerouting comment=SlingBox-IN in-interface=GW1 \
new-connection-mark=SLINGBOX-CON port=5001,5757 protocol=tcp
add action=mark-packet chain=prerouting connection-mark=SLINGBOX-CON new-packet-mark=SLINGBOX \
passthrough=no
add action=mark-connection chain=postrouting comment=SlingBox-UT new-connection-mark=\
SLINGBOX_UP out-interface=GW1 port=5001 protocol=tcp
add action=mark-packet chain=postrouting connection-mark=SLINGBOX_UP new-packet-mark=\
SLINGBOX_UP passthrough=no
add action=mark-connection chain=prerouting comment=Stream-AUDIO layer7-protocol=\
streaming-audio new-connection-mark=STREAM-CON_AUDIO
add action=mark-packet chain=prerouting connection-mark=STREAM-CON_AUDIO new-packet-mark=\
STREAM_AUDIO passthrough=no
add action=mark-connection chain=prerouting comment=Stream-VIDEO layer7-protocol=streaming \
new-connection-mark=STREAM-CON
add action=mark-packet chain=prerouting connection-mark=STREAM-CON new-packet-mark=STREAM \
passthrough=no
add action=mark-connection chain=prerouting comment=HTTP-IN connection-mark=!HTTP_BIG \
in-interface=GW1 new-connection-mark=HTTP port=80,443,8080 protocol=tcp
add action=mark-connection chain=prerouting connection-bytes=500000-0 connection-mark=HTTP \
new-connection-mark=HTTP_BIG protocol=tcp
add action=mark-packet chain=prerouting connection-mark=HTTP_BIG new-packet-mark=ACK-HTTP-BIG \
packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=prerouting connection-mark=HTTP new-packet-mark=ACK-HTTP \
packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=prerouting connection-mark=HTTP_BIG new-packet-mark=HTTP_BIG \
passthrough=no
add action=mark-packet chain=prerouting connection-mark=HTTP new-packet-mark=HTTP passthrough=\
no
add action=mark-connection chain=postrouting comment=HTTP_UT connection-mark=!HTTP_BIG_UT \
new-connection-mark=HTTP_UT out-interface=GW1 port=80,443,8080 protocol=tcp
add action=mark-connection chain=postrouting connection-bytes=500000-0 connection-mark=HTTP_UT \
new-connection-mark=HTTP_BIG_UT protocol=tcp
add action=mark-packet chain=postrouting connection-mark=HTTP_BIG_UT new-packet-mark=\
ACK-HTTP-BIG_UP packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=postrouting connection-mark=HTTP_UT new-packet-mark=ACK-HTTP_UT \
packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=postrouting connection-mark=HTTP_BIG_UT new-packet-mark=\
HTTP_BIG_UT passthrough=no
add action=mark-packet chain=postrouting connection-mark=HTTP_UT new-packet-mark=HTTP_UT \
passthrough=no
add action=mark-connection chain=prerouting comment=SNMP new-connection-mark=SNMP-CON port=161 \
protocol=udp
add action=mark-packet chain=prerouting connection-mark=SNMP-CON new-packet-mark=SNMP
add action=mark-connection chain=postrouting comment=SNMP_UP new-connection-mark=SNMP-CON_UP \
port=161 protocol=udp
add action=mark-packet chain=postrouting connection-mark=SNMP-CON_UP new-packet-mark=SNMP_UP
add action=mark-connection chain=prerouting comment=BITTORRENT layer7-protocol=bittorrent \
new-connection-mark=BITTORRENT
add action=mark-packet chain=prerouting connection-mark=BITTORRENT new-packet-mark=BITTORRENT \
passthrough=no
add action=mark-connection chain=postrouting comment=BITTORRENT_UP layer7-protocol=bittorrent \
new-connection-mark=BITTORRENT_UP out-interface=GW1
add action=mark-packet chain=postrouting connection-mark=BITTORRENT_UP new-packet-mark=\
BITTORRENT_UP passthrough=no
add action=mark-connection chain=prerouting comment=THE_REST connection-mark=no-mark \
in-interface=GW1 new-connection-mark=THE_REST-CON
add action=mark-packet chain=prerouting connection-mark=THE_REST-CON new-packet-mark=THE_REST \
packet-mark=!Work passthrough=no
add action=mark-connection chain=postrouting comment=THE_REST-UP connection-mark=no-mark \
new-connection-mark=THE_REST_UP-CON out-interface=GW1
add action=mark-packet chain=postrouting connection-mark=THE_REST_UP-CON new-packet-mark=\
THE_REST_UP passthrough=no

/queue tree
add name=Down parent=global queue=default
add name=Up parent=global queue=default
add name=THE_REST packet-mark=THE_REST parent=Down priority=7 queue=default
add name=THE_REST_UP packet-mark=THE_REST_UP parent=Up priority=7 queue=default
add name=HTTP packet-mark=HTTP parent=Down priority=3 queue=default
add name=HTTP_UP packet-mark=HTTP_UT parent=Up priority=3 queue=default
add name=HTTP_BIG_UP packet-mark=HTTP_BIG_UT parent=Up priority=6 queue=default
add name=HTTP_BIG packet-mark=HTTP_BIG parent=Down priority=7 queue=default
add name=ACK packet-mark=ACK-HTTP parent=Down priority=1 queue=default
add name=ACK_UP packet-mark=ACK-HTTP_UT parent=Up priority=1 queue=default
add name=DNS packet-mark=DNS parent=Down priority=2 queue=default
add name=DNS_UP packet-mark=DNS_UP parent=Up priority=2 queue=default
add name=ICMP packet-mark=ICMP parent=Down priority=2 queue=default
add name=ICMP_UP packet-mark=ICMP_UP parent=Up priority=2 queue=default
add name=SLINGBOX packet-mark=SLINGBOX parent=Down priority=6 queue=default
add max-limit=128k name=SLINGBOX_UP packet-mark=SLINGBOX_UP parent=Up queue=default
add name=BITTORRENT packet-mark=BITTORRENT parent=Down queue=default
add max-limit=64k name=BITTORRENT_UP packet-mark=BITTORRENT_UP parent=Up queue=default
add name=Stream packet-mark=STREAM parent=Down priority=5 queue=pcq-download-default
add name=STREAM_UP packet-mark=STREAM_UP parent=Up priority=4 queue=default
add name=STREAM-AUDIO packet-mark=STREAM_AUDIO parent=Down priority=4 queue=default
add name=WinBox packet-mark=WinBox parent=Down priority=2 queue=default
add name=WinBox_UP packet-mark=WinBox_UP parent=Up priority=2 queue=default
add name=ACK-HTTP-BIG packet-mark=ACK-HTTP-BIG parent=Down priority=1 queue=default
add name=ACK-HTTP-BIG_UP packet-mark=ACK-HTTP-BIG_UP parent=Up priority=1 queue=default
add name=SNMP packet-mark=SNMP parent=Down priority=2 queue=default
add name=SNMP_UP packet-mark=SNMP_UP parent=Up priority=2 queue=default

--------------------

toxicfusion · Fri Mar 27, 2015 8:04 pm

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

kivimart · Fri Mar 27, 2015 8:17 pm

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

toxicfusion · Wed Apr 01, 2015 5:17 pm

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?

EngineerAustin · Sat Jun 20, 2015 7:41 pm

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

alaskanjackal · Tue Sep 29, 2015 1:57 pm

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

freemannnn · Tue Sep 29, 2015 7:56 pm

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

alaskanjackal · Tue Sep 29, 2015 8:35 pm

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.

alaskanjackal · Wed Sep 30, 2015 2:00 am

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.

freemannnn · Wed Sep 30, 2015 8:39 am

connection-rate is broken from firmware 6.28 and after. i dont understand why mikrotik dont fix it.
http://forum.mikrotik.com/viewtopic.php ... te#p501644
downgrade to 6.28 and you will see that it works!
thank you for the nice qos script

alaskanjackal · Fri Oct 02, 2015 10:03 pm

connection-rate is broken from firmware 6.28 and after. i dont understand why mikrotik dont fix it.
http://forum.mikrotik.com/viewtopic.php ... te#p501644
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.

haffari · Mon Dec 28, 2015 11:38 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6
Option 3 ... coming soon

Hi
Waiting for next parts.......................................

freemannnn · Wed Feb 24, 2016 11:55 am

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?

MikroTikOkay · Mon Mar 07, 2016 5:34 pm

connection-rate is broken from firmware 6.28 and after. i dont understand why mikrotik dont fix it.
http://forum.mikrotik.com/viewtopic.php ... te#p501644
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.

alaskanjackal,

Would you mind sharing your revised script? Thanks!

porch · Sat Mar 12, 2016 10:24 am

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!!!!!

MosquitoCR · Mon Aug 01, 2016 4:49 am

alaskanjackal,

Please send me the updated MK script .

IntrusDave · Mon Aug 01, 2016 7:54 am

Try using pure DSCP
http://forum.mikrotik.com/viewtopic.php?f=9&t=110717

nichky · Mon Sep 05, 2016 12:08 am

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

Thanks

mrjurek · Mon Dec 19, 2016 12:01 am

alaskanjackal,

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

Thanks.

mltobing · Wed Dec 21, 2016 4:33 am

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

freemannnn · Wed Dec 21, 2016 9:31 am

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

49er · Wed Dec 21, 2016 12:39 pm

Hi,
This is a very interesting topic.
I want to use it on a transparent mikrotik device.
So no router.
Is that also possible?
And than make difference in up and download

satskiy · Thu Dec 22, 2016 9:40 am

if i hawe spf as WAN and all lan+ wifi are in bridge
then
Ether-WAN= SPF
Ether-LAN=Bridge right ?

mltobing · Mon Dec 26, 2016 4:22 am

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

RouterOS v6.36.4 working properly, then upgrade to 6.37.3. Bug fix confirmed

Thanks freemannnn

alaskanjackal · Mon Mar 20, 2017 1:12 am

alaskanjackal,

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

Thanks.

Sorry for my long absence here.

Here's an updated version of the script (from another device I have deployed, so I think the interface names might be different than my first script and the connection speed is also different--adjust as necessary) that's been running for >1y without any issues.

I do see the report that connection-rate may be fixed in a newer release, but I have not re-incorporated it into my scripts. Perhaps I will someday. For now, here is my latest operating script:

# Date: March 19, 2017
# Version: 1.4, based on work by pcunite
# Tested with RouterOS 6.38.5
# 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 action=mark-connection chain=prerouting comment=DNS connection-state=new new-connection-mark=DNS passthrough=yes port=53 protocol=udp
add action=mark-connection chain=postrouting connection-state=new new-connection-mark=DNS passthrough=yes port=53 protocol=udp
add action=mark-packet chain=postrouting connection-mark=DNS new-packet-mark=DNS passthrough=no

# Mark all VoIP traffic based on DSCP marking 46 and 26.
add action=mark-connection chain=prerouting comment=VOIP dscp=46 new-connection-mark=VOIP-TCP passthrough=yes protocol=tcp
add action=mark-connection chain=prerouting dscp=46 new-connection-mark=VOIP-UDP passthrough=yes protocol=udp
add action=mark-connection chain=prerouting new-connection-mark=VOIP-UDP passthrough=yes port=4500 protocol=udp
add action=mark-connection chain=prerouting dscp=26 new-connection-mark=VOIP-TCP passthrough=yes protocol=tcp
add action=mark-connection chain=prerouting dscp=26 new-connection-mark=VOIP-UDP passthrough=yes protocol=udp
add action=mark-packet chain=prerouting connection-mark=VOIP-TCP new-packet-mark=VOIP-TCP passthrough=no
add action=mark-packet chain=prerouting connection-mark=VOIP-UDP new-packet-mark=VOIP-UDP passthrough=no

# Mark all UDP traffic. Mark different UDP streams if you want more granularity.
add action=mark-connection chain=prerouting comment=UDP connection-state=new new-connection-mark=UDP passthrough=yes protocol=udp
add action=mark-packet chain=prerouting connection-mark=UDP new-packet-mark=UDP passthrough=no

# Ping replies. Mark in two places because ICMP is sent out by the router (itself) too.
add action=mark-connection chain=prerouting comment=ICMP connection-state=new new-connection-mark=ICMP passthrough=yes protocol=icmp
add action=mark-connection chain=postrouting connection-state=new new-connection-mark=ICMP passthrough=yes protocol=icmp
add action=mark-packet chain=postrouting connection-mark=ICMP new-packet-mark=ICMP passthrough=no

# ACK traffic. Based on viewtopic.php?f=2&t=67965
add action=mark-packet chain=postrouting comment=ACK new-packet-mark=ACK packet-size=0-123 passthrough=no protocol=tcp tcp-flags=ack
add action=mark-packet chain=prerouting new-packet-mark=ACK packet-size=0-123 passthrough=no protocol=tcp tcp-flags=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 action=mark-connection chain=prerouting comment=HTTP connection-state=new new-connection-mark=HTTP passthrough=yes port=80,443,8080 protocol=tcp
add action=mark-connection chain=prerouting connection-bytes=500000-0 connection-mark=HTTP new-connection-mark=HTTP_BIG passthrough=yes protocol=tcp
add action=mark-packet chain=prerouting connection-mark=HTTP new-packet-mark=HTTP passthrough=no
add action=mark-packet chain=prerouting connection-mark=HTTP_BIG new-packet-mark=HTTP_BIG passthrough=no

# Mark everything else that has no mark applied.
add action=mark-connection chain=prerouting comment=OTHER connection-mark=no-mark new-connection-mark=OTHER passthrough=yes
add action=mark-packet chain=prerouting connection-mark=OTHER new-packet-mark=OTHER passthrough=no

###############################################################################
# HTB Queue Tree a unidirectional queue
#
# Based on 50M down / 5M up connection (measured at 54000k/54.0M down, 5600k/5.6M 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 max-limit=5500k name=MASTER_UP parent=ether1-gateway queue=default
add max-limit=53M name=MASTER_DOWN parent=bridge-local queue=default
add limit-at=200k max-limit=5M name=VOIP-TCP_U packet-mark=VOIP-TCP parent=MASTER_UP priority=1 queue=default
add limit-at=200k max-limit=45M name=VOIP-TCP_D packet-mark=VOIP-TCP parent=MASTER_DOWN priority=1 queue=default
add limit-at=200k max-limit=5M name=ACK_U packet-mark=ACK parent=MASTER_UP priority=2 queue=default
add limit-at=4M max-limit=45M name=ACK_D packet-mark=ACK parent=MASTER_DOWN priority=2 queue=default
add limit-at=200k max-limit=5M name=DNS_U packet-mark=DNS parent=MASTER_UP priority=3 queue=default
add limit-at=4M max-limit=45M name=DNS_D packet-mark=DNS parent=MASTER_DOWN priority=3 queue=default
add limit-at=200k max-limit=5500k name=UDP_U packet-mark=UDP parent=MASTER_UP priority=4 queue=default
add name=UDP_D packet-mark=UDP parent=bridge-local priority=4 queue=default
add limit-at=200k max-limit=5M name=ICMP_U packet-mark=ICMP parent=MASTER_UP priority=5 queue=default
add limit-at=4M max-limit=45M name=ICMP_D packet-mark=ICMP parent=MASTER_DOWN priority=5 queue=default
add limit-at=200k max-limit=5500k name=HTTP_U packet-mark=HTTP parent=MASTER_UP priority=6 queue=default
add limit-at=4M max-limit=53M name=HTTP_D packet-mark=HTTP parent=MASTER_DOWN priority=6 queue=default
add limit-at=200k max-limit=5500k name=HTTP_BIG_U packet-mark=HTTP_BIG parent=MASTER_UP priority=7 queue=default
add limit-at=4M max-limit=53M name=HTTP_BIG_D packet-mark=HTTP_BIG parent=MASTER_DOWN priority=7 queue=default
add limit-at=200k max-limit=5500k name=OTHER_U packet-mark=OTHER parent=MASTER_UP queue=default
add limit-at=4M max-limit=53M name=OTHER_D packet-mark=OTHER parent=MASTER_DOWN queue=default
add name=VOIP-UDP_D packet-mark=VOIP-UDP parent=bridge-local priority=1 queue=default
add limit-at=200k max-limit=5M name=VOIP-UDP packet-mark=VOIP-UDP parent=MASTER_UP priority=1 queue=default

Note that the limit-at amounts could probably use some playing around with, and (as I mentioned above) connection-rate could probably be re-implemented. But this ruleset seems to be working pretty bulletproof for me--allowing me access to very, very near my max possible throughput while preventing any sort of connection issues on VoIP calls.

nichky · Wed Apr 19, 2017 12:11 am

Can i implement PCQ on that script? i mean..for e.g.

add limit-at=200k max-limit=5M name=ACK_U packet-mark=ACK parent=MASTER_UP priority=2 queue=PCQ_U

And also i would like to specified any IP_Subnet for e.g. (address list) can i do this?

if it is posible will be exselent

)

Thanks a lot

nichky · Thu Apr 20, 2017 4:47 am

just I'm wondering it' possible to do, on second part of QoS on this post, i wold like to do with Address List.Can anyone help me?

Thanks

korcom · Mon Aug 07, 2017 10:48 am

@alaskanjackal your scripts are incredible.

How would I implement it with 2 WANs both with different speeds?

Thank you

marwooj · Wed Mar 07, 2018 7:23 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6 – Option 2

If I have s2s ipsec VPN will it go into "OTHER"?

marwooj · Wed Mar 07, 2018 7:36 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6 – Option 2

I also do not understand how LEVEL_A_ gets priority over LEVEL_B_ and then over LEVEL_C_.
Would somebody be so kind explain this?

sindy · Sun Mar 11, 2018 10:55 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6 – Option 2

If I have s2s ipsec VPN will it go into "OTHER"?

In my opinion, the only way to understand how the traffic prioritization works is to try to implement a simple one on your own and debug it, not to try to understand someone else's complex example like the one above. Once you understand how it works using your simple case, reading the complex example becomes much easier.

So as I wrote in the other thread, you have to prioritize VoIP traffic among everything you send through the uplink. To do that, you have to set a DSCP mark (better to use the standard one, i.e. 46, for VoIP media and maybe also signalling) as DSCP is the only attribute of the packet which remains unchanged after IPsec encryption and encapsulation.

To answer your question - when talking about the classifier rules in the example above, the IPSec transport packets would definitely fall into the OTHER group, while the packets before encryption and encapsulation could fall into any of the groups depending on the criteria. So if you would use that script without modification of the classifier rules, you would prioritize VoIP traffic among everything that is going to be sent encrypted, but that would be useless because you would give the lowest (OTHER) priority to all the encrypted traffic.

So the whole implementation would have to include

for the upload direction:
- mangle rules setting DSCP value for anything which is going to be sent via the IPsec tunnel (it is possible that the phones already do that, but you also need to eventually remove priority marking from other than VoIP packets should it eventually be set on them)
- mangle rules marking connections and packets going to be sent via the uplink, including the IPsec transport packets, based on DSCP and other criteria
- queue setup prioritizing the packets going to be sent via the uplink based on the marks assigned in the step above
for the download direction:
- mangle rules marking connections and packets received based on protocol type and, possibly, DSCP marking (if it survives transit through internet as stated earlier)
- queue setup throttling the low priority packets in such a way that the necessary amount of download bandwidth is kept free for the priority packets.

The download margin you have to reserve for the priority packets will differ significantly depending on whether the DSCP markings survive the transit or not. If they do, you may keep the margin only as big as to accommodate the incoming VoIP traffic; if they don't, you have to limit the IPsec transport bandwidth as a whole on the remote site upload and reserve enough space for all of it at local download because in such case, there is no way to freely distribute the "non-VoIP" download bandwidth between the tunnelled and non-tunnelled traffic.

marwooj · Mon Mar 12, 2018 1:47 pm

I think I will forget about putting VoIP into VPN, this definitely sounds to complicated. And I will try to tune the example I have already implemented. Just after I understood how LEVEL_A_ gets priority over LEVEL_B_ and then over LEVEL_C_

sindy · Mon Mar 12, 2018 2:55 pm

I think I will forget about putting VoIP into VPN, this definitely sounds to complicated. And I will try to tune the example I have already implemented. Just after I understood how LEVEL_A_ gets priority over LEVEL_B_ and then over LEVEL_C_

Funny. To me the idea of setting the DSCP field doesn't sound complicated at all as it is basically a single mangle rule. What may be complicated is to distinguish VoIP packets from non-VoIP ones but if you reserve an address range or subnet on each site for your VoIP devices, or if you can ask the VoIP devices to set the DSCP themselves, it is also not very complex. Softphones are a problem unless they can set DSCP themselves because they cannot be identified by IP address and the PCs they run at generate both kinds of traffic.

I mean, once you pushstart the prioritization as such, adding VoIP needs just a tiny bit compared to the overall effort.

What I still have to try is to practically deploy the queues, I didn't have the need so far.

But I've had a look at the setup with LEVEL_X and it seems to me that LEVEL_A and LEVEL_B have no priority over each other, they simply each have their dedicated share of the total bandwidth as they have a common parent queue which doesn't have any bandwidth limits set. So both LEVEL_A and LEVEL_B may reach their limits simultaneously, so the summary traffic may be 7800k up and 82M down, but none of them may "borrow" the other one's bandwidth even if it is completely unused. So GROUP_A and GROUP_B would be more appropriate names.

marwooj · Mon Mar 12, 2018 3:10 pm

Looks like my PBX boxes are adding DSCP = 40 already, I just afraid that by putting this traffic into VPN will add unnecessary overheat and I will end up with having bigger disaster that I have now.

So to make LEVEL_B and LEVEL_C always lower priority than LEVEL_A I will change parent of B and C to A?

sindy · Mon Mar 12, 2018 3:39 pm

Looks like my PBX boxes are adding DSCP = 40 already, I just afraid that by putting this traffic into VPN will add unnecessary overheat and I will end up with having bigger disaster that I have now.

Do you use VoIP phones or analog/ISDN phones and only the PBXes would talk VoIP to each other? If VoIP phones, do the PBXes tell the phones to send media to each other directly or do they force themselves into the media path? All that plays a role - if VoIP phones send media directly to each other, they must set DSCP or you must do it on their behalf when forwarding the packets to the remote site.

So to make LEVEL_B and LEVEL_C always lower priority than LEVEL_A I will change parent of B and C to A?

Yes but not only, you must also give the LEVEL_B queue the lowest priority among all the other child queues of LEVEL_A. And LEVEL_C must have the lowest priority among all child queues of LEVEL_B.

The queues play two roles - one is speed limitation and another one is prioritization. Speed limit doesn't allow more data to be sent even if bandwidth is available. Priority determines the order of searching through the queues at each level for the next packet to be sent once the "line" gets free after the previous packet has been sent.

On the upload, it is basically enough for QoS to do the prioritization, speed limitation is only necessary if you want to guarantee some minimum bandwidth to individual users.

On the download, you cannot actually affect the priority with which the ISP is sending the packets down your connection, so you must make use of the TCP's flow control - if you limit the speed with which received TCP packets are delivered from WAN to LAN, the remote senders limit their sending speed accordingly as they wait for ACKs from the recipients before sending another burst of packets. There is no point in throttling incoming UDP as it has no effect on the sender. So the trick is to limit the bandwidth for TCP in download direction and leave the rest for the peak amount of UDP you can expect (which is some 100k per audio RTP stream, but you have to inspect your traffic to see what else on top of RTP, DNS responses, NTP responses arrives to you as UDP). You'll likely also see some icmp there.

marwooj · Mon Mar 12, 2018 3:59 pm

I also have ipsec s2s not for the purpose of VoIP, to completely different site. It is mostly RDP.
Since IPsec s2s is also UDP (I think), how I can put it "to not disturb" my VoIP but not to go into LEVEL_C / OTHER?

sindy · Mon Mar 12, 2018 4:43 pm

I also have ipsec s2s not for the purpose of VoIP, to completely different site. It is moatly RDP.
Since IPsec s2s is also UDP (I think), how I can put it "to not disturb" my VoIP but not to go into LEVEL_C / OTHER?

That's the role of DSCP as mentioned in the other (s2s) thread. The "plaintext" traffic on the WAN can be classified as "TCP" and "other protocols" directly; the IPsec transport packets will either be ESP ones or UDP ones (depending on existence of NAT in the path) with a particular source and destination; whether "TCP" or "other" is encrypted inside them can only be determined if the sending side sets the DSCP field and the transit through internet doesn't destroy it completely.

On upload, you have to send the packets to the IPsec machinery without any throttling, only set their DSCP. The outgoing prioritization will take place on the plaintext and IPsec transport packets together, where the DSCP shows to which group or level the IPsec transport packets belong.

On download, there is a special situation - the IPsec transport packet and its decapsulated an decrypted payload are treated as two separate packets which came in via the same interface. As you do not want to queue the same actual packet twice, you can

either inspect the remainders of DSCP (if any) on the IPsec transport packets and choose a queue for them on that basis, but in such case you have to exclude from the queueing the decapsulated an decrypted payload
or exclude from queueing the IPsec transport packets, but in such case you have to inspect the protocol type and other attributes of the decapsulated and decrypted packets and choose the queue for them on that basis

I am afraid that "exclude from queueing" actually means to put them into a topmost queue with highest priority and no speed limits.

Classification of IPsec transport packets by DSCP in download saves CPU because the classification rules are simpler as the class has already been determined by the sending Mikrotik.

marwooj · Tue Mar 13, 2018 11:19 am

So to make LEVEL_B and LEVEL_C always lower priority than LEVEL_A I will change parent of B and C to A?
Yes but not only, you must also give the LEVEL_B queue the lowest priority among all the other child queues of LEVEL_A. And LEVEL_C must have the lowest priority among all child queues of LEVEL_B.

Should LEVEL_A as a parent of everything have

priority=1

?
Does priority is valid only among members of the same branch. So all children in sub branch will always step down to traffic if they parent priority is smaller than priority of an other branches on the same level. Does not mutter they have 1 but there is another purrent that have 7 ant they parrent has 8?

Regarding bandwidth, how to make C not to stal everything from B, and then B not to eat everything of A.
Do I need to change theirs max-limit to be smaller from each other?

and the example of proper "do not disturb my VoIP" should look like:

add name="LEVEL_A_UP"   parent=ether-WAN  queue=default max-limit=900k [b]priority=1
[/b]add name="LEVEL_A_DOWN" parent=bridge-LAN queue=default max-limit=4M [b]priority=1
[/b]add name="VOIP_U"       parent="LEVEL_A_UP"    packet-mark="VOIP"     queue=default priority=1
add name="VOIP_D"       parent="LEVEL_A_DOWN"  packet-mark="VOIP"     queue=default priority=1

add name="LEVEL_B_UP"   parent=LEVEL_A_UP  queue=default max-limit=[b]something smaler than parent A[/b] [b]priority=2
[/b]add name="LEVEL_B_DOWN" parent=LEVEL_A_DOWN queue=default max-limit=something smaler than parent A [b]priority=2
[/b]
add name="ACK_U"        parent="LEVEL_B_UP"    packet-mark="ACK"      queue=default priority=1
add name="ACK_D"        parent="LEVEL_B_DOWN"  packet-mark="ACK"      queue=default priority=1
add name="SOMETHING"        parent="LEVEL_B_UP"    packet-mark="SOMETHING"      queue=default [b]priority=7
[/b]add name="SOMETHING"        parent="LEVEL_B_DOWN"  packet-mark="SOMETHING"      queue=default [b]priority=7
[/b]
add name="LEVEL_C_UP"   parent=[b]LEVEL_B_UP[/b]  queue=default max-limit=[b]something smaler than parent B[/b] [b]priority=8
[/b]add name="LEVEL_C_DOWN" parent=[b]LEVEL_B_UP[/b] queue=default max-limit=[b]something smaler than parent B[/b] [b]priority=8
[/b]
add name="HTTP_U"       parent="LEVEL_C_UP"    packet-mark="HTTP"     queue=default [b]priority=1
[/b]add name="HTTP_D"       parent="LEVEL_C_DOWN"  packet-mark="HTTP"     queue=default [b]priority=1
[/b]
add name="OTHER_U"      parent="LEVEL_C_UP"    packet-mark="OTHER"    queue=default priority=8
add name="OTHER_D"      parent="LEVEL_C_DOWN"  packet-mark="OTHER"    queue=default priority=8

sindy · Tue Mar 13, 2018 12:01 pm

So to make LEVEL_B and LEVEL_C always lower priority than LEVEL_A I will change parent of B and C to A?
Yes but not only, you must also give the LEVEL_B queue the lowest priority among all the other child queues of LEVEL_A. And LEVEL_C must have the lowest priority among all child queues of LEVEL_B.
Should LEVEL_A as a parent of everything have
Code: Select all
priority=1
?
Does priority is valid only among members of the same branch. So all children in sub branch will always step down to traffic if they parent priority is smaller than priority of an other branches on the same level. Does not mutter they have 1 but there is another purrent that have 7 ant they parrent has 8?

Regarding bandwidth, how to make C not to stal everything from B, and then B not to eat everything of A.
Do I need to change theirs max-limit to be smaller from each other?

and the example of proper "do not disturb my VoIP" should look like:
Code: Select all
add name="LEVEL_A_UP"   parent=ether-WAN  queue=default max-limit=900k [b]priority=1
[/b]add name="LEVEL_A_DOWN" parent=bridge-LAN queue=default max-limit=4M [b]priority=1
[/b]add name="VOIP_U"       parent="LEVEL_A_UP"    packet-mark="VOIP"     queue=default priority=1
add name="VOIP_D"       parent="LEVEL_A_DOWN"  packet-mark="VOIP"     queue=default priority=1

add name="LEVEL_B_UP"   parent=LEVEL_A_UP  queue=default max-limit=[b]something smaler than parent A[/b] [b]priority=2
[/b]add name="LEVEL_B_DOWN" parent=LEVEL_A_DOWN queue=default max-limit=something smaler than parent A [b]priority=2
[/b]
add name="ACK_U"        parent="LEVEL_B_UP"    packet-mark="ACK"      queue=default priority=1
add name="ACK_D"        parent="LEVEL_B_DOWN"  packet-mark="ACK"      queue=default priority=1
add name="SOMETHING"        parent="LEVEL_B_UP"    packet-mark="SOMETHING"      queue=default [b]priority=7
[/b]add name="SOMETHING"        parent="LEVEL_B_DOWN"  packet-mark="SOMETHING"      queue=default [b]priority=7
[/b]
add name="LEVEL_C_UP"   parent=[b]LEVEL_B_UP[/b]  queue=default max-limit=[b]something smaler than parent B[/b] [b]priority=8
[/b]add name="LEVEL_C_DOWN" parent=[b]LEVEL_B_UP[/b] queue=default max-limit=[b]something smaler than parent B[/b] [b]priority=8
[/b]
add name="HTTP_U"       parent="LEVEL_C_UP"    packet-mark="HTTP"     queue=default [b]priority=1
[/b]add name="HTTP_D"       parent="LEVEL_C_DOWN"  packet-mark="HTTP"     queue=default [b]priority=1
[/b]
add name="OTHER_U"      parent="LEVEL_C_UP"    packet-mark="OTHER"    queue=default priority=8
add name="OTHER_D"      parent="LEVEL_C_DOWN"  packet-mark="OTHER"    queue=default priority=8

I don't like to provide theoretical-only answers and as I've stated several times, I didn't have a strong enough reason to test this practically so far. So already my previous response was wrong, as the manual says the following:
priority (1..8 ) : Prioritize one child queue over other child queue. Does not work on parent queues (if queue has at least one child). One is the highest, eight is the lowest priority. Child queue with higher priority will have chance to reach its max-limit before child with lower priority. Priority have nothing to do with bursts.

I have assumed that the priority works among all children of the same queue and recursively, but it seems not to be the case. So either you have to split the total available banwidth into subbands which do not affect each other, or you have to manage everything within the 8 priority levels of the common band. I just remind that in download direction there is basically no other way than throttling the traffic which can be throttled to leave a "fast lane" always free for the real-time traffic.

SamWCL · Tue Mar 27, 2018 10:09 am

Did anyone figure out MPLS/VPLS QoS using DSCP/EXP bits?

mixig · Tue Nov 06, 2018 9:29 pm

I'm a little curious why you have some rules twice
ros code
/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
 
You are marking packets twice based on the same options. In my opinion rule 2 can be removed.
Then first there are two rules marking the connection and setting connection-marks. Then use the connection-mark to mark the packets in one single rule.

This two rules are not the same... src/dst address are in use

Chupaka · Tue Jan 08, 2019 10:31 am

Should this topic be moved to Useful user articles forum?

pcunite · Wed Jan 09, 2019 12:18 am

Should this topic be moved to Useful user articles forum?

I would like to rewrite it, make it a little easier to follow.

pegasus123 · Fri Jan 25, 2019 12:27 pm

I'm a little curious why you have some rules twice
ros code
/ip firewall mangle
add chain=forward action=mark-connection protocol=udp   src-address=192.168.100.5 connection-state=new new-connection-mark="VOIP" comment="IP-PBX"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
add chain=forward action=mark-connection protocol=udp   dst-address=192.168.100.5 connection-state=new new-connection-mark="VOIP"
add chain=forward action=mark-packet     passthrough=no connection-mark="VOIP"    new-packet-mark="VOIP"
 
You are marking packets twice based on the same options. In my opinion rule 2 can be removed.
Then first there are two rules marking the connection and setting connection-marks. Then use the connection-mark to mark the packets in one single rule.
This two rules are not the same... src/dst address are in use

isn't it enough to just mark it once? once a packet is read, it will be marked with connection mark, connection mark works both ways upload and download in which case you can mark the packet and be used in queue tree.

is my understanding correct?

sindy · Fri Jan 25, 2019 4:33 pm

is my understanding correct?

Your understanding is correct in terms that the rule translating connection-mark into packet-mark may be there only once (as the last one after the two assigning the connection-mark). Regarding the need for two rules assigning the connection-mark, it is a more complex question.

One approach would be to have only one such rule (for src- or dst-address) and say that if a single packet in the "wrong" direction doesn't get connection-marked, it causes no harm as the first subsequent packet in the opposite direction will fix this. The other approach, however, is to save CPU by having the connection-mark->packet-mark translation rule before the connection-marking rules so that these rules would only handle packets belonging to not yet marked connections. And this is usually combined with allowing these rules to handle only the initial packet of each connection (connection-state=new), so then you need to use both rules because you don't know in advance which RTP packet will be the first one in a given call.

And of course, the translation rules have to be doubled in the latter case - the first one handles packets belonging to already marked connections early in the chain, and the other one has to be there to handle the translation for the initial packets after the connection-mark has been just assigned.

pegasus123 · Sat Jan 26, 2019 5:49 am

is my understanding correct?
Your understanding is correct in terms that the rule translating connection-mark into packet-mark may be there only once (as the last one after the two assigning the connection-mark). Regarding the need for two rules assigning the connection-mark, it is a more complex question.

One approach would be to have only one such rule (for src- or dst-address) and say that if a single packet in the "wrong" direction doesn't get connection-marked, it causes no harm as the first subsequent packet in the opposite direction will fix this. The other approach, however, is to save CPU by having the connection-mark->packet-mark translation rule before the connection-marking rules so that these rules would only handle packets belonging to not yet marked connections. And this is usually combined with allowing these rules to handle only the initial packet of each connection (connection-state=new), so then you need to use both rules because you don't know in advance which RTP packet will be the first one in a given call.

And of course, the translation rules have to be doubled in the latter case - the first one handles packets belonging to already marked connections early in the chain, and the other one has to be there to handle the translation for the initial packets after the connection-mark has been just assigned.

Thanks for the detailed explanation!

denisun · Fri Feb 08, 2019 8:56 am

I am also writing here because I have not found a solution.
Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line?
My problem is this.

pcunite · Fri Feb 08, 2019 3:13 pm

I am also writing here because I have not found a solution. Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line? My problem is this.

Someday, I hope to do another write up on this subject, when I get time. I had hoped that one would not need to be an expert to get this correct, but as of 2019, it still does. However, I think a better article would help.

From the moment that audio transmits from your equipment, until it gets back, there must not be greater than a 150ms interruption (or thereabout) otherwise you will notice the delay. Now, think about everything that an audio packet has to go through to make that happen. When you understand that, you'll have solved your VoIP issue.

The permanent fix, a separate Internet service line. Can't do that? Then fast hardware performing QoS where VoIP packets get the best treatment when bad things happen (and they will).

denisun · Fri Feb 08, 2019 4:13 pm

I am also writing here because I have not found a solution. Has anyone managed to give priority to VoIP, and to work with no problem, with full load on the line? My problem is this.

Someday, I hope to do another write up on this subject, when I get time. I had hoped that one would not need to be an expert to get this correct, but as of 2019, it still does. However, I think a better article would help.

From the moment that audio transmits from your equipment, until it gets back, there must not be greater than a 150ms interruption (or thereabout) otherwise you will notice the delay. Now, think about everything that an audio packet has to go through to make that happen. When you understand that, you'll have solved your VoIP issue.

The permanent fix, a separate Internet service line. Can't do that? Then fast hardware performing QoS where VoIP packets get the best treatment when bad things happen (and they will).

I have a CRS109-8G.
I can not believe that my provider's simple modem/router equipment work perfect with VoIP packets and full load
and the MT have problem.
My question is...
- Have i somewhere wrong in mangles, tree or queue types?
- Is MT hw low specifications and can't process the load?
- Is ROS bug?
With ubiquity the result is much perfect.

pcunite · Fri Feb 08, 2019 4:50 pm

I have a CRS109-8G. With ubiquity the result is much better.

I would not use the CRS109 for QoS tasks. Too under powered in my opinion. However, there are many variables.

denisun · Fri Feb 08, 2019 7:26 pm

I have a CRS109-8G. With ubiquity the result is much better.

I would not use the CRS109 for QoS tasks. Too under powered in my opinion. However, there are many variables.

I don't believe that the problem is the hw specifications of CRC.
My ISPs equipment cost ~20-50e and work perfect with traffic (VoIP and dw).

bolean · Sat Feb 23, 2019 3:08 pm

version 3, running smooth

pcunite · Sat Feb 23, 2019 6:43 pm

Version 3, running smooth

@bolean,

How does this test compared to what you're doing?

/queue tree

# DOWN
add max-limit=90M name=DOWN parent=bridge1 queue=default

add name="1. VOIP" packet-mark=VOIP parent=DOWN priority=1 queue=default
add name="2. ACK" packet-mark=ACK parent=DOWN priority=1 queue=default
add name="3. DNS" packet-mark=DNS parent=DOWN priority=2 queue=default
add name="4. UDP" packet-mark=UDP parent=DOWN priority=3 queue=default
add name="5. ICMP" packet-mark=ICMP parent=DOWN priority=4 queue=default
add name="6. HTTP" packet-mark=HTTP parent=DOWN priority=5 queue=default
add name="7. HTTP_BIG" packet-mark=HTTP_BIG parent=DOWN priority=6 queue=default
add name="8. QUIC" packet-mark=QUIC parent=DOWN priority=7 queue=default
add name="9. OTHER" packet-mark=OTHER parent=DOWN priority=8 queue=default

# UP
add max-limit=90M name=UP parent=ether1 queue=default

add name="1. VOIP_" packet-mark=VOIP parent=UP priority=1 queue=default
add name="2. ACK_" packet-mark=ACK parent=UP priority=1 queue=default
add name="3. DNS_" packet-mark=DNS parent=UP priority=2 queue=default
add name="4. UDP_" packet-mark=UDP parent=UP priority=3 queue=default
add name="5. ICMP_" packet-mark=ICMP parent=UP priority=4 queue=default
add name="6. HTTP_" packet-mark=HTTP parent=UP priority=5 queue=default
add name="7. HTTP_BIG_" packet-mark=HTTP_BIG parent=UP priority=6 queue=default
add name="8. QUIC_" packet-mark=QUIC parent=UP priority=7 queue=default
add name="9. OTHER_" packet-mark=OTHER parent=UP priority=8 queue=default

ros code

ros code

ros code

ros code

ros code

ros code

ros code

ros code

ros code

Who is online