In
/ip(v6) firewall mangle action=set-priority
one can pick on of these special values.
I understand from-dscp-high-3-bits follows RFC8235, but how is it different from from-dscp?
And what is from-ingress? is it Layer 2 priority (such as 802.11 UP)?
from-dscp uses the three low bits instead of the high three bits. The mapping difference is as follows:
from-dscp-high-3-bits:
DSCP 0-7 → priority 0
DSCP 8-15 → priority 1
DSCP 16-23 → priority 2
DSCP 24-31 → priority 3
DSCP 32-39 → priority 4
DSCP 40-47 → priority 5
DSCP 48-55 → priority 6
DSCP 56-63 → priority 7
from-dscp:
DSCP 0,8,16,24,32,40,48,56 → priority 0
DSCP 1,9,17,25,33,41,49,57 → priority 1
DSCP 2,10,18,26,34,42,50,58 → priority 2
… etc, I’m sure you can work out the rest.
Needless to say, you should probably use from-dscp-high-3-bits.
from-ingress tries to set the priority based on some value for a packet arriving at the device from another device. VLAN priority, WMM Priority and NV2 priority can work for this.
In general, when is the “set priority” considered?
In particular I have the following layout:
WAN ← untagged → bridge ← tagged → vlan interface (bridge vlan-filtering) ← tagged → RouterOS switches ← tagged → wlan (WMM enabled, vlan is set on the interface) ((( untagged ))) WMM and DSCP aware clients
I want WMM and DSCP to be retained and converted within LAN boundaries and drop priority on WAN ingress and egress.
“set priority” is only considered on the device that is actually potentially applying the priority setting to either a VLAN priority (CoS), WMM, NV2, or MPLS packet. In the case of VLAN priority (CoS) that is the device that is actually adding the tag to the packet, and the set priority has to happen prior to the point that the device adds the tag or it won’t work. The VLAN priority will survive through other switches/bridges so you shouldn’t need to set it on each layer 2 hop within a broadcast domain, only on the device that first adds the VLAN tag. In the case of WMM or NV2, the device that actually creates the WMM or NV2 packet (i.e. the wireless AP or SU) will need to be the one with the set priority action - however with WMM and NV2 priority this is extremely local and only survives this particular wireless link and not multiple wireless links in a chain. For MPLS, the router that applies the first MPLS label onto the packet must be the router that has the set priority action - when the packet moves from router to router, it will inherit the priority from the MPLS label.
I don’t know what you mean by CoS->DSCP conversion. There is no automatic CoS->DSCP conversion that takes place to my knowledge. The packet will retain the DSCP marking it originally has unless you actually use a change-dscp mangle rule to change it. There is no easy way to map CoS back to DSCP to my knowledge, without using a series of change-dscp mangle rules.
The VLAN priority will survive through other switches/bridges so you shouldn’t need to set it on each layer 2 hop within a broadcast domain, only on the device that first adds the VLAN tag.
http://forum.mikrotik.com/t/bridge-is-resetting-cos-to-0-was-setting-cos-from-dscp-on-pppoe-server/131109/1 points that CoS may be cleared on a bridge. Although I’m not sure whether it applies to packets that go from one VLAN to another (both ports are part of the bridge, but with different tags) or even when VLAN header is untouched (both bridge ports belong to the same VLAN).
I would take this with a grain of salt and confirm everything by doing packet captures. A MikroTik switch doing simple bridging should not result in the VLAN priority being changed for any VLAN tag that might be present. What I would expect to see is that the VLAN priority will be retained across all hops.
A lot can also depend on how you use bridges. It is possible to have a bridge that removes and reapplies a VLAN tag, for instance! So configuration can make a huge difference.
It is possible to have a bridge that removes and reapplies a VLAN tag, for instance!
Do you mean that in this case CoS must be set “manually” via a set-priority from-ingress Bridge Filter rule?
Probably - I mean it is possible to have a bridge that connects two different interface VLANs on two different interfaces, and in this particular setup, I could understand the device treating them as two different VLANs where it would remove one tag and add the next. This is not the normal situation though.
For instance on ether4 you could have an interface VLAN 444 and on ether5 you could have another interface VLAN 444 and you could have a bridge called bridge-vlan-444 that has both the interface VLAN 444 on ether4 and interface vlan 444 on ether5 as ports. In this case I could understand the device potentially treating it as removing a tag and adding another.
a bridge that connects two different interface VLANs on two different interfaces
Ah I see, a bridge where ports are VLAN interfaces (/interface vlan) and not a bridge with vlan-filtering=yes and differently tagged physical interfaces.
Assuming that clients do not utilize DSCP, where would you suggest to convert WMM priority from clients into CoS? I understand it must happen on the device that receives a wlan packet and then tags, but cannot quite grasp at what point exactly.
Since it’s wlan interface that does tagging, should it be a rule on a wlan interface? What chain? IP Firewall Mangle or Bridge Filter?
Yes, precisely, I could see this configuration potentially being seen as removing a VLAN tag and adding a new one, and therefore behaving differently than a bridge with vlan-filtering set to yes.
So if you want to convert WMM priority to CoS you will need to add a set priority to ingress priority rule on the device that is receiving the packet over wireless and applying a VLAN tag at the same time. If it is bridging you can use a bridge filter rule for this, forward chain. If it is routing you would use a mangle rule in the firewall, also forward chain.
wlan is part of a bridge, so IP Firewall is probably too late: mangle doesn’t even allow to pick the wlan interface, since it’s a slave of the bridge.
But bridge filter rule also might be too late, since at this point packets already vlan tagged (wlan interface does tagging).