I’m trying to create a rather advanced setup with a lot of mangle rules, lots of routing-marks, packet marks etc. Many of these rules are somewhat equal, and the outgoing interface is a part of the packet mark.
Example from a router on a big boat:
connection-mark = adminlan_vsat_high + outgoing → mark-packet adminlan_vsat_high_out
connection-mark = adminlan_vsat_general + outgoing → mark-packet adminlan_vsat_general_out
connection-mark = adminlan_4g_high + outgoing → mark-packet adminlan_4g_high_out
connection-mark = adminlan_4g_general + outgoing → mark-packet adminlan_4g_general_out
If I could use the interface-name (or routing-mark) as a variable in the mark-packet (and connection) mangle rule, we could GREATLY simplify our mangle rules.
Something like this would be perfect:
add action=mark-packet chain=“mark packets” connection-mark=ADMIN-{$interface}-HIGH
new-packet-mark=ADMIN_OUT_HIGH1_{$interface} passthrough=no src-address-list=
ADMIN-LAN
or maybe even use multiple variables to simplify even more, like this:
In the underlying Linux system this is sort of possible because a mark is just a 32-bit value that can be
treated as a bitmask, in which you can set and clear bits and check for bit combinations (masking then checking).
This also allows for multiple marks on the same packet or connection, for different purposes.
(e.g. I have used this for separate marks to indicate that a connection is to be NATted and for marking high-priority traffic)
In your case you could put a mark in one bitfield and an interface number in another.
However, in the MikroTik configuration there is a translation layer that allows you to use symbolic names instead
of numeric values, and it appears that this flexibility has been lost in that layer.
Another feature that would be useful is to match connection-marks including, starting with (or regex), and not only exact matches. Even multiple selections would help a lot, that is matching multiple connection-marks in one rule.
Yeah, but that would be impossible in the underlying mechanism unless all matchings you would
want to do would be known beforehand.
It looks like the marks are just translated to incrementing numbers internally, and that is why you
can only have one mark per packet and they can only be fully matched.
Of course it would be possible to translate marks to a bit, but then you can have only 32 different
marks. Probably somebody would stand up and complain loudly when such a restriction was present…
When marks are bits, matches can be done on many combinations even wildcards on the mark
name (but not always, depends on your naming convention).