I am using packet marks for high priority queue for selected users. For that I have created connection marks , one for upload and one for download.
The packets are then using these connection marks to be marked.
Can I use the same connection marks for both up- and download?
It’s the other way round - you can not use separate connection-marks for upload and download, because any single connection has a single connection-mark at a time, which does not depend on packet direction. So if you assign the connection-mark to the connection when handling a packet in one direction, re-assigning it when handling the packet in the opposite direction would replace the one previously assigned.
Either first or second OP’s mark rules doesn’t do anything … the rules differ only by comparing address list against dst-address or src-address respectively. But in both rules the critera includes out-interface=WAN … and depending on contents of HighPriority address list (are those WAN addresses or LAN addresses) only one of rules will actually mark connections.
Edit: scrap that … if the address list contains a mix of LAN and WAN addresses, both rules will have something to do.
When running a speedtest both up and downloads are limited, even if I disable the upload connection marks.
I’ve also removed the interfaces - seems like an unnecessary check.
I’ve put the connection marks in the forward chain. Not sure if it makes any difference.
Yes, this is often quite unfortunate, and the underlying mechanism in Linux would allow multiple marks, so it is only a limitation in RouterOS.
I think it has been promised one time to solve this in v7 (as so many things have been promised for v7) but I have not seen it appear yet.
It could be tricky to convert existing setups. Connection-mark (like packet-mark) is a 32-bit field that allows bitfield operations. It appears that the mark names currently just are converted to numbers stored in that (entire) field, allowing many different marks but only one mark at a time.
When the bit field would be used as 1-bit-per-mark (values 1,2,4,8 etc) there could be any combination of marks, but only 32 different marks (names).
So converting a setup that currently has more than 32 different mark names would run into trouble, and a global single/multi mark option setting would be required when all existing configs need to be supported…
For now it appears there is no progress. I sure would like to use marks for parallel purposes like priority, multiple internet connections, etc.