Weird OSPF route redistribute behavior

[HamRadio]

Hey guys,

I noticed some weird ospf redistribution behavior yesterday, and I’m trying to find out if it’s a bug, feature, or just the way MikroTik has programmed things, and if it’s going to change in the future, or what’s going on.

1. A blackhole route is getting automatically pushed into OSPF, regardless of route filters, and redistribute rules being checked in OSPF Instance. If I put in a blackhole route, and if there’s no specific filter, even if there is an out-filter selected, in the instance, but the subnet isn’t in the out-filter, that blackhole route is being redistributed in OSPF, and everything under redistribute is unchecked.

2. Everything under “Redistribute” is unchecked. I have a Public IP on a vlan, a /30. That vlan is not on an interface under Interface templates. That /30 is getting redistributed into OSPF because the entire /22 of that Public IP block is in the OSPF route filters. If I was to remove the /22 from the route filter, the /30 will go away.

This doesn’t seem to be normal, but maybe it’s normal for MikroTik? Any ideas?

[cstarritt]

Can you post your route filter rules?

It sounds like you are accepting “dst in x.x.x.x/22” which will also match more specific prefixes inside that /22. You can either switch to something like “dst == x.x.x.x/22” if you only want to match that specific /22, or you can match a specific range of prefix lengths with something like “dst in x.x.x.x/22 && dst-len<24”.

[HamRadio]

Can you post your route filter rules?

It sounds like you are accepting “dst in x.x.x.x/22” which will also match more specific prefixes inside that /22. You can either switch to something like “dst == x.x.x.x/22” if you only want to match that specific /22, or you can match a specific range of prefix lengths with something like “dst in x.x.x.x/22 && dst-len<24”.

add chain=ospf-out comment=“All Public IP’s” disabled=no rule=“if (dst in 38.141.40.0/22 && dst-len in 0-32) { accept; }”

So this is where that rule is “dst in” instead of “dst ==”

[cstarritt]

Can you post your route filter rules?

It sounds like you are accepting “dst in x.x.x.x/22” which will also match more specific prefixes inside that /22. You can either switch to something like “dst == x.x.x.x/22” if you only want to match that specific /22, or you can match a specific range of prefix lengths with something like “dst in x.x.x.x/22 && dst-len<24”.

add chain=ospf-out comment=“All Public IP’s” disabled=no rule=“if (dst in 38.141.40.0/22 && dst-len in 0-32) { accept; }”

So this is where that rule is “dst in” instead of “dst ==”

“dst in 38.141.40.0/22 && dst-len in 0-32” will match any prefix inside 34.141.40.0/22, such as 34.141.1.0/24 and 34.141.41.4/30 for instance. That is the normal expected behavior. You can change it to “dst == 38.141.40.0/22” to only match that exact prefix and no other more specific prefixes inside of it, or you can change it to something like “dst in 38.141.40.0/22 && dst-len in 22-24” to also match the /23 and /24 prefixes inside that /22, but not any /25 or longer prefixes.