Is frequently needed the used of Unicast Reverse Path Forwarding.
On ISPs:
The major use of that is to avoid Spoofing coming from your networks, especially on BNGs / B-RAS.
Bu also frequently used combined with Black-Hole Routes to protect (with low computational cost) internal networks from packets coming from malicious packets.

On several other routing platforms this feature / resource can be activated on a per interface scenario.

On RouterOS, unfortunately, this can be activated globally, to all the interfaces.

I would like to suggest / request that this resource be activated on a per interface choice.

For example, on a B-RAS that is connected with more than one uplink point to different points of the network, with destination dynamically naturally changing… It's impossible to activate rp-filter=strict because it affects destinations that are in other interfaces then the Uplink(default-route) and the subscriber's interfaces with their direct connected routes, PDs, or static routes.

If it would be possible to activate this on a per interface choice these issues would be solved.

As complementary suggestions, I think that this could be deployed in two possible scenarios:
a) Inheritance, as it's used on ARP timeout, where if not defined on each interface, it takes the global definition (My preferred methodology.).
b) Interface-Lists, where the URPF would be activated or not depending on the interfaces that are in a interface-list.

P.S.: I also created a feature request for that on MikroTik servicedesk. SUP-122253.
I'm creating a topic here also, so that other users could suggest improvements to that.

Strict mode never works in large networks. The proper solution is feasible mode.

You can enable global feasible mode and never need to think again per-interface loose vs strict.

https://datatracker.ietf.org/doc/html/rfc8704

Strict mode never works in large networks. The proper solution is feasible mode.
You can enable global feasible mode and never need to think again per-interface loose vs strict.

Yep! RIB Lookup, ou Feasible mode is "the dream".

From de point of view of de URPF itself, It would solve almost all of the issues.
But the extra work of looking up a table with many more routes is a performance challenge.

But Feasible mode is not what I'm asking for here!

I'm just asking to be able to choose what interfaces will have the URPF enabled and what will not!

From the point of view of programing, this is much simpler than feasible mode.
It is a feature that already is available on several other vendors since 20 years ago(or more).

On a B-RAS / BNG, Is really needed that the subscribers(access-users) interfaces be with rp-filter in strict mode.
But de Uplink interfaces, especially if the topology demands several PTPs to multiple other routers, is not acceptable that URPF be strict mode.

Just disabling the rp-filter on those interfaces is enough.

Hello

Agree with the request and makes total sense to have uRPF control per interface. The current model limits scenarios as the mentioned with BNG with multiple uplinks for example. Enabling strict more in a BNG just for the customer interfaces is a very effective way and welcome way to reduce spoofing.

Important is that this support should be not only for physical interfaces or vlans but also for dynamic interfaces like pppoe.

Adding another voice to the importance of this being implemented. The linux kernel already supports per-interface rp-filters of off, loose, and strict. Maybe there will be some challenges with certain switch chips not supporting per-interface RPF for L3 offload, but giving us the knob to pick a global mode and a per-interface override would be preferable. Maybe something like: Without per-interface control, Mikrotik devices can really only act as client-facing devices (with strict mode) if they only require one uplink and no VRRP peer. Most circumstances with two or more links quickly run into asymmetry issues. Seems a shame considering the advanced feature-set of RouterOS that a couple of trivial knobs aren't there to open up more use cases.

Even if the firewall can cover same cases, it would be useful have rp-filter as a backstop. The global-ness of rp-filter does limit its use today.

A specific example of where per-interface rp-filter very useful is LTE interface using Verizon in the US. Verizon drops the session if assigned address does not match the one coming from the router – they essentially expect the router to use rp-filter=strict. But "strict" isn't possible if there are multiple uplinks. While "invalid" fw filter mostly covers... It's actually various router services that can use the "wrong" src-address (e.g. MMDP and/or CDP) – if a kernel rp-filter could catch that & that prevent a misconfiguration in /ip/neighbors from sending valid, but unwanted discovery, out an interface. But that's just one example, likely others...

e.g. I know what interface can/should use rp-filter=strict, but it's rarely ALL of them...

Even if possible in fw, per-interface rp-filter seems good like a "backstop" to misconfiguration & may reduce error-prone/performance-reducing firewall rules in same cases.