Since routeros version 7.2.2. mark routing has a higher priority than routing/rules. version 7.2.3 and 7.3 also like this.
Is this a bug or a feature change?
its not clear yet, i believe bug no much information about that in changelog also, i stay in 7.2.1 until this bug fix
Mangle has now strictly the highest priority.
Why isn’t there any information about this in the changelog.
This is a big change. Many people think this is a bug.
Mangle on Forward happen after Routing decision.
Is perfectly normal the behaviour that what is done on Routing can be replaced on Mangle.
Then the actual behavior on v7 is what is expected.
On previous v6, is like a bug, following the packet flow.
@rextended routing can be marked only in prerouting and output
For explanation how it works see this:
http://forum.mikrotik.com/t/v7-3-and-v7-3-1-stable-is-released/158530/87
The change was made to fix the problems marking VRF traffic with the mangle.
It was always not recommended to override mangle with routing rules, if you had this setup previously, then yes unfortunately you have a broken setup now.
I never really played with it there, but AFAIK Linux has this configurable (see “ip rule”) and default is what RouterOS had previously. It’s not necessarily the only right choice, it can be what RouterOS has now. The bad thing is changing something like this without any warning whatsoever. I’m pretty sure that many people with load balancing previously marked routing without excluding router as destination, something like:
/ip route
add dst-address=0.0.0.0/0 gateway=xx routing-table=wan1
add dst-address=0.0.0.0/0 gateway=xx routing-table=wan2
/ip firewall mangle
add chain=prerouting in-interface=LAN connection-state=new per-connection-classifier=something/0 action=mark-connection new-connection-mark=wan1
add chain=prerouting in-interface=LAN connection-state=new per-connection-classifier=something/1 action=mark-connection new-connection-mark=wan2
add chain=prerouting in-interface=LAN connection-mark=wan1 action=mark-routing new-routing-mark=wan1
add chain=prerouting in-interface=LAN connection-mark=wan2 action=mark-routing new-routing-mark=wan2
And why not, it always worked. But now if they upgrade, they suddenly won’t be able to access router. Most will probably have enabled access using MAC address, but it will still cause a lot of confusion. And again, the main problem, there was no warning.
Your mentioned setup will not break, there is no routing rules
Well, then maybe it’s not exactly this but something related and unintended, but it does break. If destination is local address, then packet with routing marked like this no longer goes in chain=input, but in chain=forward. Something that previously was possible only using action=route.
And the intended change in routing rules, it’s also slightly annoying. If I understand it correctly, it means that my handy foolproof shortcut (= use main routing table for selected destination no matter what routing mark it has):
/ip route rule
add dst-address=192.168.0.0/16 action=lookup-only-in-table table=main
is now dead. With a config like I posted, it nicely handled both other LAN subnets and hairpin NAT. It can be done differently by adding dst-address-list=!LANs dst-address-type=!local to mangle rules, so I guess it won’t be a problem. But it will requires some config fixes. Oh well..
@Sob thanks for mention this problem, most of us choosing MikroTik because load balance, now the change break something important like this i will considered not upgrading to newer version, mrz say that change for fix VRF marking but honestly most of us dont even use VRF just a simple load balance like in version 6, the reason i upgrade to ROS v7 is wireguard and new queue type (Codel, Cake etc) well maybe is pain the ass
but i will bear it
![]()
It was curious what was up with this and it indeed a nasty one. My config was also broken. Looking in the mangle pre-routing routing marking the counters did not increase. Only the one catching traffic that should be mangled but has not been not mangled and setting the TTL to zero, to avoid traffic going out a wrong exit.
In the new-mark-routing lines, I had the condition that traffic should be routing table main. Now traffic is not automatically put in table main first, and then you can change that to an other routing table.
My routing table looks like this:
Name FIB
aaa yes
bbb yes
D main yes
wg-1 yes
wg-2 yes
I have had to remove all checks on routing table main and I have no replacement for main on the moment.
Is this the way to get the previous working back to have all traffic be default “main”?
/routing rule
add action=lookup disabled=no table=main
@dioeyandika: Well, it definitely needs clarification what’s intended and what isn’t. But it’s not hopeless, you should be able to do what you need, you’ll just have to be more careful with what you mark routing for.
hem i thought remove all checks in FIB it wont show in mangle routing mark, and how about 0.0.0.0/0 destination are we need to delete this too in ip route?
If traffic is not route marked main by default anymore how do I see what the assigned routing mark is. Mikrotik writes the one with the strictly order/priority.
Then having a “no-mark” routing-mark in the mangle like as with connection-mark could then detect traffic not yet routing marked. Main is an mark, and now the same status as other routing marks except it dynamically generated. If I look in /ip/route loads of lines have main as default routing table.
@msatter: Can you give some more understandable simple example? I’m trying different things and so far I didn’t find any problem with main routing table. Even if I do action=mark-routing new-routing-mark=main, it seems to work as if I didn’t do any marking.
Filtering on active routing-mark:
add action=mark-routing chain=prerouting new-routing-mark=WireGuard routing-mark=main
Looking at routing-mark=main to see if there is already a routing mark present. When not then route-mark traffic
I don’t see any change there. If I do this:
/ip firewall mangle
add chain=prerouting routing-mark=main action=log log-prefix=1-main
add chain=prerouting routing-mark=!main action=log log-prefix=1-notmain
add chain=prerouting new-routing-mark=test action=mark-routing
add chain=prerouting routing-mark=main action=log log-prefix=2-main
add chain=prerouting routing-mark=!main action=log log-prefix=2-notmain
add chain=prerouting action=mark-routing new-routing-mark=main
add chain=prerouting routing-mark=main action=log log-prefix=3-main
add chain=prerouting routing-mark=!main action=log log-prefix=3-notmain
Then I get: 1-notmain, 2-notmain, 3-main in 7.4beta2 as well as in 6.49.6.
before: 1-main 2-not-main 3-main
now: 1-not-main 2-not-main 3-main
My problem is 1-not-main now because before all traffic was main. That is why we don’t have no no-mark option in routing…as it is always marked according to ROS. That has been changed now since 7.2rc6 and before.
It looks like there was change between v6 and v7 and later in v7 there was another. I now tested two (edit: four) more and I see:
1-notmain, 2-notmain, 3-main in 6.48.6
1-main, 2-notmain, 3-main in 7.1.5
1-main, 2-notmain, 3-main in 7.2.1
1-notmain, 2-notmain, 3-main in 7.2.2
So yes, it’s also between 7.2.1 and 7.2.2. And nothing in changelog that would warn you. ![]()