All of the routing on our network is done with Mikrotiks (RB1100AHx2 and CCR mostly). I am trying to implement VoIP prioritization without having to set reservations on speeds. Links between the routers range from 50Mb/s to 2Gb/s (aggregate) and setting a speed could cause problems if a main link goes down and OSPF/MPLS moves traffic to a slower connection.
Here is the current Queues I have set up (we flag VoIP traffic with DSCP 46 and all last mile equipment use that mark to apply their shaping):
/ip firewall mangle
add chain=input comment="Do not QoS Input"
add chain=output comment="Do not QoS Output"
add action=jump chain=forward comment="Jump to already marked packets" connection-mark=!no-mark jump-target=already-marked
add action=mark-connection chain=forward comment="Mark VoIP Connections" connection-mark=no-mark connection-state=new dscp=46 new-connection-mark=VOIP
add action=mark-connection chain=forward comment="Mark other Data Connections" connection-mark=no-mark connection-state=new new-connection-mark=Other
add action=jump chain=forward comment="Jump to already marked packets" jump-target=already-marked
add action=mark-packet chain=already-marked comment="Mark VoIP Packets" connection-mark=VOIP new-packet-mark=VoIP passthrough=no
add action=mark-packet chain=already-marked comment="Mark Other Data Packets" connection-mark=Other new-packet-mark=Other passthrough=no
add action=return chain=already-marked comment="Return to the forward chain"
/queue tree
add name=Global-Queue parent=global queue=default
add name=VoIP packet-mark=VoIP parent=Global-Queue priority=2 queue=default
add name=Data packet-mark=Other parent=Global-Queue queue=default
So here are the questions:
Will this work as intended, giving priority to VoIP and allowing all other traffic to flow without enforcing a set speed limit?
Is there a easier/less processor intensive way for us to do this?
I’ve just seen the mangle option to set the priority, is this a comparable solution, or should I not bother? Reading the manual, it looks like this is not a maintainable solution to me.
There are two things wrong with this queue tree setup.
Firstly, the lower number is the higher priority.
(so 8 is the “least important” while 1 is the “most important”)
Secondly, priority only works as a tiebreaker whenever some maximum is being exceeded, or when all CIR (guaranteed minimums) are met.
So basically, this queue tree doesn’t know when to start using the priority because the parent queue reports that it has infinite bandwidth.
Instead of using the global HTB as the parent of the parent queue, you should replicate this tree for each interface where you want QoS, and then set the parent’s max-limit to be whatever the bandwidth of that particular interface is.
Another thing to consider is that you don’t want to allow the priority traffic to be able to hog the entire pipe - so you should set some max-limit on it.
Another way to go about this is to use CIRs - minimum guaranteed available bandwidth.
Give the VoIP queue some CIR like 2Mbps (or whatever is sane for your network and traffic expectations)
and some CIR like ~ 50% of the smallest-possible pipe (if you’re going to keep using the global HTB as the parent) on the “best effort” queue.
The way CIR works (it’s called “limit-at” in RouterOS configurations) is that every queue will be allowed to reach CIR utilization, guaranteed.
Suppose you have an unlimited priority 1 queue and an unlimited best effort queue with CIR=5Mbps.
Even if you have so much priority traffic that the link is 100% capacity, if some stream of low priority traffic comes along, it can “steal” up to 5Mbps from the priority queue.
–
So I suppose that the easiest thing for you to do is put a CIR on the VoIP queue, and leave the rest alone - and try to see if that works out for you.
(you may also want another CIR queue for management traffic such as OSPF, management access from the NOC, etc)
You can use that as part of the solution but unfortunately MikroTik does not allow you to match on the priority directly in the queue system.
I am using it like this:
/ip firewall mangle
add action=set-priority chain=postrouting comment=“From dscp high 3 bits”
new-priority=from-dscp-high-3-bits
But that only sets the priority field in the 802.11q VLAN tag when you use VLANs, and to
use the same value in a queue you still need to use marking.
Setting the priority by itself does not do much w.r.t. prioritizing traffic, as ZeroByte already explained.