Community discussions

 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Fri Feb 14, 2014 4:20 pm, edited 9 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Fri Sep 29, 2017 4:35 am, edited 15 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Fri Sep 29, 2017 4:34 am, edited 21 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

Fri May 31, 2013 9:45 pm

Implementing VoIP traffic prioritization (Qos) with RouterOS v6
Option 3 ... coming soon
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Thu Sep 05, 2013 5:42 pm, edited 18 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

Sat Jun 01, 2013 6:02 pm

Reserved
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8140
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

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 :)
Russian-speaking forum: https://forum.mikrotik.by/. Welcome!

For every complex problem, there is a solution that is simple, neat, and wrong.

MikroTik. Your life. Your routing.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Tue Jun 04, 2013 10:26 pm, edited 1 time in total.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 23592
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

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.
No answer to your question? How to write posts
 
deejayq
Member Candidate
Member Candidate
Posts: 195
Joined: Wed Feb 23, 2011 8:33 am

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

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
newbie
Posts: 27
Joined: Sun Sep 16, 2012 4:11 pm

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

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.
You do not have the required permissions to view the files attached to this post.
 
WiPoint
just joined
Posts: 5
Joined: Fri Nov 16, 2012 6:47 pm

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

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
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
 
User avatar
whiely
just joined
Posts: 1
Joined: Wed Apr 27, 2011 2:33 am

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

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 ?
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

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?
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

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
Forum Guru
Forum Guru
Posts: 1513
Joined: Mon Sep 19, 2005 6:12 pm

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

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?
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
Forum Guru
Forum Guru
Posts: 1513
Joined: Mon Sep 19, 2005 6:12 pm

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

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.
 
User avatar
Craftylover
just joined
Posts: 1
Joined: Fri Jun 21, 2013 7:22 am

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

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
just joined
Posts: 1
Joined: Tue Feb 22, 2011 8:56 am

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

Tue Oct 15, 2013 11:17 am

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

thanks
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
just joined
Posts: 4
Joined: Fri Oct 11, 2013 1:55 am

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

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
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Apr 15, 2013 10:39 pm

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

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
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Apr 15, 2013 10:39 pm

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

Tue Nov 26, 2013 11:37 pm

Cant wait for version 3....

good job, working nice here!
 
arpiska
just joined
Posts: 17
Joined: Thu Jun 09, 2011 2:54 pm

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

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
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

Mon Feb 10, 2014 3:20 am

[Solved]
Last edited by TikUser on Thu Feb 20, 2014 12:17 pm, edited 1 time in total.
 
mdkberry
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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!
just joined
Posts: 4
Joined: Fri Sep 28, 2007 4:50 pm

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

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
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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.
Last edited by pcunite on Fri Feb 14, 2014 8:13 pm, edited 2 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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.
Last edited by mdkberry on Tue Feb 18, 2014 7:39 am, edited 1 time in total.
 
mdkberry
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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?
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

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. :D
 
SyCo
just joined
Posts: 2
Joined: Mon Feb 10, 2014 8:41 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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
You do not have the required permissions to view the files attached to this post.
 
TikUser
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

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. :D
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.
You do not have the required permissions to view the files attached to this post.
 
TikUser
newbie
Posts: 47
Joined: Thu Jul 04, 2013 2:40 pm
Location: EU

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

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. :D 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.
Last edited by TikUser on Thu Feb 20, 2014 3:26 am, edited 7 times in total.
 
User avatar
pcunite
Long time Member
Long time Member
Topic Author
Posts: 634
Joined: Sat May 25, 2013 5:13 am
Location: USA

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

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
just joined
Posts: 2
Joined: Sat Feb 22, 2014 9:51 am

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

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 :D
You do not have the required permissions to view the files attached to this post.
 
mdkberry
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Tue Jan 14, 2014 4:39 am

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

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
newbie
Posts: 28
Joined: Mon Oct 21, 2013 9:52 am

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

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
---------------
Andrew
 
RB951G2HnD
newbie
Posts: 28
Joined: Mon Oct 21, 2013 9:52 am

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

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.
---------------
Andrew
 
RB951G2HnD
newbie
Posts: 28
Joined: Mon Oct 21, 2013 9:52 am

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

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
---------------
Andrew
 
Rudios
Forum Veteran
Forum Veteran
Posts: 966
Joined: Mon Mar 11, 2013 12:58 pm
Location: The Netherlands

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

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.
Testing setup with: 2 x RB750UP | 2 x RB750GL | 1 x RB951G-2HnD | 1 x RB2011UiAS-IN

Who is online

Users browsing this forum: No registered users and 7 guests