Question about OSPF route filtering

Hi there,
I’m encountering an issue with OSPF redistribution. I’ve configured an ospf-out ruleset to filter specific routes, but it seems that 10.242.99.X/32 routes are not being filtered.
Based on my understanding, this shouldn’t happen, as there’s a catch-all reject rule at the end and the given subnet and mask doesn’t match any accept rules. The ruleset is enabled and selected as Out Filter in the instance configuration.
Could someone please shed light on why these 10.242.99.X/32 routes are escaping the filter?
Config is from a CCR2004 running 7.13rc2.

/routing/filter/rule> pr where chain=ospf-out
Flags: X - disabled, I - inactive 
 0   chain=ospf-out rule="if (dst in 10.255.255.0/24 && dst-len == 32) { accept; }" 
 1   chain=ospf-out rule="if (dst in 10.13.37.0/24 && dst-len == 32) { accept; }" 
 2   chain=ospf-out rule="if (dst in 169.254.0.0/16 && dst-len == 24) { accept; }" 
 3   chain=ospf-out rule="reject;"

If you add an explicit rule before the catch-all reject such as

chain=ospf-out rule="if (dst in 10.242.99.0/24 && dst-len == 32) { reject; }"

Does it work as intended?

Something else to try … I don’t know if Mikrotik likes “naked statements” - does this work?

/routing/filter/rule> pr where chain=ospf-out
Flags: X - disabled, I - inactive 
 0   chain=ospf-out rule="if (dst in 10.255.255.0/24 && dst-len == 32) { accept; }" 
 1   chain=ospf-out rule="if (dst in 10.13.37.0/24 && dst-len == 32) { accept; }" 
 2   chain=ospf-out rule="if (dst in 169.254.0.0/16 && dst-len == 24) { accept; } else {reject;}"

Hi vingjfg,
thank you for the suggestions. I tried both, but unfortunately it didn’t make any difference.
The catch-all rule generally works, so I’ve looked at the OSPF configuration again.

It seems that subnets assigned to interfaces that are added using interface-templates cannot be excluded by any route filters.
IMO, route filters should have precedence over anything that is configured under /routing/*.

While the presence of the /32 routes on the remote router doesn’t have any real impact, it’s completely unnecessary.
Route in-filters are ineffective due to the default display of filtered routes, which is another questionable design decision..

I’ll reconsider the network design in the hope of finding a better solution.

Thanks for the feedback. I will play with this tomorrow

Confirmed - I was able to reproduce this.

The OSPF instance has an interface-template for 192.168.0.0/16 which matches several local interfaces on my router, a filter out to remove one of them does not work.

I am looking into the select rules.

That did not work either.

I guess a support ticket is in order.