I think this is a serious bug in RouterOS wich is affecting my entire netowrk as of now, consider the following:
/ip firewall mangle
add action=change-dscp chain=forward comment="DSCP EF RTP in" new-dscp=46 protocol=udp src-address-list=voip
add action=change-dscp chain=forward comment="DSCP EF RTP out" new-dscp=46 protocol=udp dst-address-list=voip
add action=change-dscp chain=forward comment="DSCP CS4 SIP" new-dscp=32 port=5060-5061 protocol=udp
add action=change-dscp chain=forward comment="DSCP AF21 ACKs 0-123" new-dscp=18 packet-size=0-123 protocol=tcp tcp-flags=ack
add action=set-priority chain=forward comment="Set Priority based on DSCP high 3 bits" new-priority=from-dscp-high-3-bits
add action=set-priority chain=forward comment="Set Priority 8 on packets with no tag at all" dscp=0 new-priority=8
This is what i would expect:
According to these mangle rules athe RTP traffic should go into the " Priority 3 Critical" queue, the SIP traffic into the “Priority 4 Flash Override”.
Instead they respectively go into “Priority 4 Flash Override” and “Priority 5 Flash”…
In fact this is instead what RouterOS does:
DSCP-----Priority
0-7---------8 Routine
8-15-------1 Network Control
16-23-----2 Internetwork Control
24-31-----3 Critical
32-39-----4 Flash Override
40-47-----5 Flash
48-55-----6 Immediate
56-63-----7 Priority
EF should go to 5 and CS4 should go to 4.
That’s the standard that major vendors use in their switches.
The table you posted shows this to be the case as well.
CSx is basically a 1:1 map to COS (802.1p) values.
In Mikrotik, AFAIK there is no “built-in” priority queue handling based on DSCP/dot1p - you must implement queues yourself, and they tend to work on packet marks.
I could be way off-base here, for instance the wlan interfaces may naturally honor DSCP/dot1p values like Ubuquiti does… but my current understanding is that there is no QoS in ROS unless you define it with queues.
The situation is a bit messy because the term “priority” is used in different ways and the range and relative
priority differs between these contexts. Please explain what you mean by “priority” and how you want
the relative priorities to be.
(for example, in the above table you suggest that CS1 and CS2 have higher priority than CS0 but it
is custom that they are lower)
With this one I’m just instructing the RB to take the highest 3 bits in every DSCP header and convert them to “RouterOS priority” (from 8 the lowest priority to 1 the highest)
/ip firewall mangle
add action=set-priority chain=forward comment="Set Priority based on DSCP high 3 bits" new-priority=from-dscp-high-3-bits
According the the latest DSCP RFC in this case (name CS4, decimal 32) the highest 3 bits of the binary string are “100”.
The problem is that there is not a “conversion table” between the DSCP header and what RouterOS will transform it into its internal priority.
The weird thing is that it appears to do the conversion in this form:
DSCP decimal----------RouterOS Priority (1 highest to 8 lowest)
0-7---------8 Routine
8-15-------1 Network Control
16-23-----2 Internetwork Control
24-31-----3 Critical
32-39-----4 Flash Override
40-47-----5 Flash
48-55-----6 Immediate
56-63-----7 Priority
I think the new-priority=from-dscp-high-3-bits just copies the top 3 bits to the priority field of the packet,
value range 0..7. The 8 comes from another rule that you mention in your first posting, I think.
In this world, priority 0 is lowest and 7 is highest.
But, when you then want to use queues you end up in another world where the priority field has
range 1..8 and 1 is highest, 8 is lowest. That is something different.
To make the crossover between these worlds, as far as I know the only way is to put packet marks
on each packet by matching with the packet priority field and then use those packet marks in the
queue tree to assign them to the correct priority queue, with the mapping you desire.
E.g.:
2->8
1->7
0->6
3->5
4->4
5->3
6->2
7->1
The priority setting in Mikrotik queues has nothing to do with the TOS byte or the dot1p header (only present in tagged frames, as I’m sure you already know)
That value does not mean: “hey, match packets with priority X”
It defines the priorities of the queues themselves when there is contention for service.
Basically, whenever two queues are both above their CIR (this is called “limit-at” in Mikrotik parlance), then the higher-priority queue will get serviced before the lower-priority one (and as you noted, the lower value = higher priority)
You match priorities in the mangle table and apply packet marks.
Queues match based on target + packet mark
If you specify multiple packet marks in a queue, then this is an OR list - packets may only have one mark at any given time, so specifying multiple marks on the queue will match any of them.
The actions you’re performing - setting DSCP/Dot1P values are pretty much there to manupulate how the packets look on the wire to other devices (qos-aware switches, for instance)
/ip firewall mangle
add [b]action=set-priority[/b] chain=forward comment="Set Priority based on DSCP high 3 bits" new-priority=from-dscp-high-3-bits
instruct the routerOS to apply a priority to thi specific packet, and with “priority” I mean the internal priority, the one from 1 to 8.; that’s what priority means in RouterOS.
The SIP traffic is correctly queue into the queue, so the action “set-priority” assign the internal priority, the routeros one from 1 to 8 (highest to lowest).
Oh and I forgot to say I’m pretty proficient with routerOS in general, I just don’t understand why this configuration doesn’t work as expected.
Do not mix priority of queues with priority assigned to packets. Priorities of queues work separately and specify “importance” of queue and has meaning only within particular queue setup. Think of packet priority as of some kind of mark, that gets attached to packet by rules. Also take into account that this mark currently is only used for outgoing packets when going over WMM enabled link, and in case VLAN tagged packet is sent out (no matter if that packet is tagged locally or bridged).
I.e. the set-priority action merely sets the value on the packet itself. The WMM processing of the wlan interface will honor this. Otherwise, the Mikrotik simply outputs the frame with the dot1p value set (the egress interface must be a tagged vlan interface) so that the attached device (a dot1p-aware switch) can make use of it.
As I explained and what ZeroByte also writes: there is no “what priority means in RouterOS”.
There are different fields named priority and they have different value ranges and meaning.
I think you confuse the two meanings and that is the reason why it does not work.
I use this method to convert from DSCP to queue priority. Note there is a bug in this, it assigns CS2 a higher priority than CS0. Will fix that sometime.
Excuse me, maybe I expressed a wrong concept…
I forgot to mention that if i use a “set-priority” on a packet I also use another rule with “mark-packet” in order to apply a mark on it and use later on in the queue.
add action=set-priority chain=forward comment="Set Priority based on DSCP high 3 bits" new-priority=from-dscp-high-3-bits
I expect that the highest 3 bits are 100 in this case (from 100 000 of the complete DSCP binary)
At this point, what “priority” will assign it to? 0,1,2,3,4,5,6 or 7?
dscp high 3 bits 000 - what priority?
dscp high 3 bits 001 - what priority?
dscp high 3 bits 010 - what priority?
dscp high 3 bits 011 - what priority?
dscp high 3 bits 100 - what priority?
dscp high 3 bits 101 - what priority?
dscp high 3 bits 110 - what priority?
dscp high 3 bits 111 - what priority?
It just copies those 3 bits, IMHO. See my example above that I edited while you were replying to it.
And understand: “assigning a priority” does nearly nothing. It only is copied into 802.11q VLAN headers.
Maybe it is your use of set-priority=8? I have never seen that value used in set-priority before. I think it should be priority 0-7 for the software packet tag called ‘priority’.
1-8 is the scale used for queue priorities, which is a totally different concept.
Very interesting discussion here. Few days ago I started to learn WMM and DSCP to set internal priority. If we have packets with known resource like ethernet, we can easily configure priority using queue. But on wireless interface performance, which depends on client distance, interference so on… I cant use queue, because I dont know what will be the client throughput at that moment. So in this case MT AP need to transmit important packets first. As my understanding, WMM means internal priority, which naturally set in operating system code to handle such important traffics. Unfortunately there is no clear example on wiki.
I configured set priority in mangle with src-address-list, but test fails. If I understood correctly, when I download regular packets on my wifi client, if try to make VoIP (important packets) call, existing regular packet rate should go down and VoIP call should pass in first priority. But it doesn`t.
Again - don’t conflate packet (frame) priority with queue priority. They might as well have called the queue priority some other word, like “importance” or “tiebreaker” or any other word.
The word “priority” in the mangle table is referring to the Dot1P priority / WMM priority, which has nothing to do with queue priority.
“priority” is just another stamp - like marking a box “fragile” or “really fragile” or “let a gorilla throw me around the cage”. If the package handler throws the “really fragile” box into the gorilla cage, then expect to hear the tinkling of shattered glass…
However, the short answer to the question is: priority 4. Just don’t expect to see the re-marked packet go through queue priority_4 unless you also re-mark the packet with the packet mark priority_4.
I gather from other posts in the thread that WMM will honor the priority value of the frames, so whatever WMM does for priority 4 would take place on wireless links.
Other than that, though, all this would do is set the COS value of the 802.1q header to be 4 (binary 100) and it would be up to the connected switch to handle this value.
Mikrotik Priority: a software based tag applied to every packet traversing router. Normal range 0-7, lowest to highest, like IP precedence. Set by set-priority action in mangle or bridge filter rule.
Mikrotik Queue Priority: the order of processing queues when congestion occurs, higher priority queues in HTB are processed first. Queue Priority scale is different from packet Priority scale : 1-8 instead of the packet Priority 0-7, and the scale is reversed - lower queue priority values are higher.
In packet priority, 0 is lowest and 7 is highest
In queue priority, 1 is highest and 8 is lowest
Mapping of packet priority to queue priority can currently only be done by marking the packets and using those marks to place the packets into the correct queues.
In most scenarios users will probably want to place packets of a certain priority into queues of a certain priority, for example, a typical mapping might be:
PP 0 placed in priority 8 queue
PP 1 placed in priority 7 queue
PP 2 placed in priority 6 queue
…
PP 7 placed in priority 1 queue
You might swap 0 and 1 if you wish to use CS1 for scavenger traffic.
Of course for all above, you also need to mark the packets because this direct translation is currently not available.
Regardless of what that says, the priority in practical terms does only have 0-7 range. Things that you use this value to set, like MPLS EXP bits, WMM priority, VLAN priority, are only three bit structures. It probably lets you enter values from 0-63 but I don’t know what effect entering 8 would have for setting MPLS-EXP bits for instance (although it would probably mod 8 it down to 0).
