I am trying to implement QoS on an RB2011UiAS-2HnD-IN and having some difficulty. I mark the packets based on their source address (ip address of the phone) as voip and mark all other traffic as be for best effort. I then implement a simple queue.
Here is the packet marking with source address 192.168.88.32/28 marked voip and all other traffic as be:
Here’s the queue - It’s a simple queue to give the packets marked voip a 1 Mbps CIR and limit traffic marked be to a 10 Mbps CIR. Here is the queue config:
In firewall mangle, Byte and Packets, the number of packets being marked does not coincide with the amount of voice or best effort traffic being generated
In the Queue, I don’t see any traffic being matched. My downstream is 125 Mbps and upstream is 25 Mbps - traffic from speedtest runds at 125/25 and not the expected 10/10
What am I doing wrong here? I’m pretty conversant with QoS on Cisco routers and switches, but this is all new to me here.
Don’t forget that you need a rule to match traffic with the phone’s IP as the destination must also be marked as priority.
You should probably match based on connection and not packet-by-packet
Thanks for the reply but, alas, I am only further confused. Reading your entry below, this is what it looks like to me:
Prerouting chain:
0: If a packet comes in without any mark, jump to classify (how would a packet be marked at this point - wouldn’t this catch all?)
1: If a packet come in with connection-mark=voip, re-mark it as voip (why does it have to be re-marked - does Mikrotik strip the mark?)
2: mark any other packet be
I added what you have and the entire mangle looks like this:
0 D ;;; special dummy rule to show fasttrack counters
chain=prerouting
1 D ;;; special dummy rule to show fasttrack counters
chain=forward
2 D ;;; special dummy rule to show fasttrack counters
chain=postrouting
3 chain=prerouting action=jump jump-target=classify connection-mark=no-mark log=no log-prefix=“”
4 chain=prerouting action=mark-packet new-packet-mark=voip passthrough=no connection-mark=voip log=no log-prefix=“”
5 chain=prerouting action=mark-packet new-packet-mark=be passthrough=yes log=no log-prefix=“”
6 chain=classify action=mark-connection new-connection-mark=voip passthrough=yes src-address=192.168.88.32/28 log=no log-prefix=“”
7 chain=classify action=mark-connection new-connection-mark=voip passthrough=yes dst-address=192.168.88.32/28 connection-mark=no-mark log=no log-prefix=“”
8 chain=classify action=mark-connection new-connection-mark=be passthrough=yes connection-mark=no-mark log=no log-prefix=“”
9 chain=classify action=return log=no log-prefix=“”
On a VoIP call of 1 minute, entry 4 marked 16 packets, entry 6 marked 1 packet, and entry 7 marked none. This seems like a very low number of packets as VoIP is generally 50 packets/second. What am I not understanding?
Anyway, haven’t even gotten to the queue yet - still trying to understand marking.
I now understand the marking process and what you were trying to show me.I have the voice packets marking correctly passed and source & destination addresses. The general traffic is also being marked correctly as be. Thank you for your help.
With regard to the queue, I have this in place (queue tree):
Our connection is 20 down and 10 up. Will the setting here work or should I shave some off the be limit to take into consideration that we won’t always get a true 20/10.
Thanks once again.
Queue tree can only limit traffic in one direction - that being OUTPUT on the interface it’s parented to. So your BE queue is shown to guarantee 20M upstream… (Limit-at = guaranteed minimum)
Try setting this to something like 5M
Sure - two things.
First, on the mangle rules, I would suggest adding the criteria “connection-mark=be” to your rule which marks packets as “be” by default. (it’s just good practice to be explicit in this case because if you ever add more classes and are depending on the “no passthrough” above, then it’s easier to make a mistake)
Then there’s the queue tree.
Your BE queue is configured as such:
no burst
max-limit=5M
limit-at=9M
— this means “the most they can do when not bursting is 5M. Guarantee a minimum of 9M” - I wish limit-at had a different name because it’s quite misleading. Limit-at is a guaranteed minimum available bandwidth.
Also, your queues are built using a strategy that’s appropriate for simple queues, not for queue trees.
With queue trees, you need to make a single queue that is parented to a particular interface, say LAN for instance, which will govern the download QoS. If you place it on the WAN interface, then it will govern the upload traffic. A queue tree queue only governs traffic that is being sent out of whatever interface it’s tied to. (I’m not quite sure what the behavior is for a tree that is parented to global - perhaps someone else can chime in on that point).
You should basically have two trees containing three queues each. (a parent with two children)
So build your queues like this:
Call one queue “upstreamQOS” and one queue “downstreamQOS”
Set the upstreamQOS with parent=wan interface, max-limit=your available upstream speed, no limit-at / burst / etc.
Set the downstreamQOS with parent=lan interface, max-limit=your available downstream bandwidth, no limit-at / burst / etc.
These are the queues which track total consumption of your bandwidth in each direction. They need to know how much of each class of traffic is flowing so that combined, they may never total more than the actual bandwidth you have available.
Then you make 2 VoIP queues (one for upstream and one for downstream)
These you will configure just as you did your current VoIP queue - everything looks great on that queue
set these two VoIP queues the same way and parent one of them to the upstreamQOS queue, and parent the other to downstreamQOS.
Configure two BE queues as follows:
max-limit=100M (yes 100Meg)
limit-at=5M
priority=8
Finally, set one queue’s parent to the upstreamQOS queue, and the other to the downstreamQOS queue.
so the obvious question is “why 100M?” The answer is that you’re actually limiting the speed with the upstreamQOS/downstreamQOS parent queues, NOT with the sub-queues. The sub queues simply define the min-guarantee (limit-at) and the priority - which priority ONLY comes into play after two queues at the same level have both been granted their guaranteed minimum bandwidth. (so the BE queue will take priority over VoIP queue if VoIP is above its limit-at speed, but BE is below its limit-at speed, regardless of priority - but this is actually what you want)
Basically, think of the parent queue as a shared bank account, and it’s the sub-queues that actually do the spending. As long as there is remaining bandwidth in the main queue, any sub-queue may spend it, but only up to the sub queue’s limits. If a sub queue has a higher limit than the parent queue, that doesn’t mean that it can spend MORE than the parent, because the parent just doesn’t have it to spend…
It seems that the queue isn’t working like I want as we still seem to get some packet loss on voice upstream. When that was happening, there was a moderate amount of upstream traffic and only 2 voice calls.
Depending on how the ISP is limiting the 20 upstream bandwidth (that’s how the queues are set currently, I assume that your statement of 50up / 20down was flip-flopped), you may actually have slightly less than 20… especially if they’re doing policing and if the interface is physically running at 1Gbps…
Try throttling the upstream down to 18M (90%) and see if this helps - if not, try something silly like 10M. Basically, when the line rate is significantly faster than a policed rate, the simple passing of packets can place the link “over budget” if the policer is using too small of a time interval because each 1500-byte frame is actually crossing the wire at 1Gbps, which doesn’t take long to push a very small-interval’s average rate above 20M…
Also, the policer is going to consider packet overhead, whereas the queue might be considering only IP payload…
Also - it’s possible that there is packet loss on the ISP’s transport - meaning that the available bandwidth in your area might be getting congested, and it’s not your own packets stepping on each other, but your neighbors’ packets stepping on yours.
