Fix for BUGS, ERRORS on default RouterOS firewall rules and firewall changes from 6.43 to 7.22beta3
*** removed ***
I create separate topic for that:
1 Like
Most of these changes are only cosmetic. The in-interface=lo just followed exposing the loopback and the connection-state=new just removed an unnecessary (and not very logical) additional matcher.
The traceroute port/dst-port was a genuine issue, though. It's a shame that anything like this basically cannot be fixed during upgrade for risk of breaking modified configurations...
@jaclaz: looks nice.
1 Like
Yes, in the separate topic I also put the rest that I hadn't written here,
One thing I pick up here:
I also use the Anav way.
Drop all the rest: Chain=forward action=drop. Done. No if/but/else/what/...
Already for years.
When downgrade to 6.49.17
You may need to change some /ip settings
(Or reset to default)
"Allow fast path" and "Route Cache" need to be enabled.
This along with fasttrack enabled (from default config).
Performance should be back.
Also rstp enabled (default), disables bridge hardware offload in v6.
(eg. when using lan ports as a hardware switch)
v7 does nothing permanent and irreversible that might cause a drop in performance.
Netinstall one unit with the latest v6 to confirm.
You might also try OpenWrt on them.
I created a support ticket with the link to your benchmark post above and asking MikroTik to consider evaluating cheaper conditions first, and to apply short-circuit evaluation. They have posted an answer to the ticket:
Hello,
Thank you for your inquiry. We will investigate and make adjustments if possible.
1 Like
I would think this is just standard Linux kernel functionality and you can look in the kernel sources to see how it works.
MikroTik changing that is only going to make it more difficult to ever migrate to a newer kernel version.
Indeed, when you want to evaluate some condition first, put it in a jump rule.
Well, short-circuit evaluation is being done, and the tests confirm that.
@pe1chl "It's done this way in the kernel" is not the whole story. The kernel modules (both iptables and nftables) evaluate the criteria in the order that they are presented in the rule, which comes from the (user space) mechanism programming it.
Mikrotik's configuration system doesn't really have an order amongst attributed, so an internally present ordering is always used. Based on the limited number of tests, this seems to roughly align with the way the matchers are presented in Winbox.
It is not always clear what the optimal order of evaluation is, because not only must we consider how long performing the match takes, but also how many packets it disqualifies.
As I see it, basically the only rational (micro-)optimization here that's potentially worth it is bringing connection-state matching to the front, simply because of the large number of rules that only apply to new connections, primarily in the mangle prerouting and output chains. (But mostly the same optimization may be achieved by creating a custom chain only for new connections, or accepting established/related, etc.) It would still make sense to implement this though...
Would mean that connection tracking (ntables ct) matcher would always be prioritized. It is not clear if a conntrack lookup is less expensive than e.g. checking for src-port.
It isn't. (It's roughly the same cost.)
If I understand correctly, @CGGXANNX's line of thought is that the connection-state rule would disqualify many more packets. To be fair, this is generally true (but of course, not always.)