Control OSPF static redistribution (ROS v6 vs v7)

pamribeirox · Thu Mar 24, 2022 7:34 pm

Hello,
I have some use cases that require some static routes kept local to the device and other static routes redistributed via OSPF.
In ROS 6 the solution I had was "tagging" the static routes with some special ( 65511:1 ) BGP community and then using a routing filter on ospf-out that filtered the redistribution of the static routes only allowing the tagged ones.

Example (ROS 6.49.5):

/ip route add bgp-communities=65111:1 comment="route to be redistributed" dst-address=10.1.0.0/22 type=blackhole
/ip route add comment="pure local static route" dst-address=10.1.8.0/23 gateway=10.2.0.1
/routing ospf instance set [ find default=yes ] redistribute-static=as-type-1
/routing filter add action=accept bgp-communities=65511:1 chain=ospf-out comment="redistribute tagged routes" protocol=static
/routing filter add action=discard chain=ospf-out comment="discard all other static routes" protocol=static

The "untagged" static routes are being suppressed and not present in the routing tables of the other OSPF area routers.

After upgrading to ROS 7.1.5, The way I was tagging with a BGP community is no longer accepted by the syntax. I've tried to keep the behavior but the routes seem to be redistributed anyway even when the action "reject" is applyed.

Example (ROS 7.1.5):

/ip route add blackhole comment="route to be redistributed" disabled=no distance=2 dst-address=10.1.0.0/22 routing-table=main suppress-hw-offload=no
/ip route add comment="pure local static route" disabled=no distance=10 10.1.8.0/23 gateway=10.2.0.1 routing-table=main suppress-hw-offload=no
/routing ospf instance add name=default-v2 out-filter-chain=ospf-out redistribute=static
/routing filter rule add chain=ospf-out comment="redistribute only static routes with distance lower than 10" disabled=no rule="if (protocol static && active && distance < 10 ) { set ospf-ext-tag 9; accept; }"
/routing filter rule add chain=ospf-out comment="don''t redistribute other static routes" disabled=no rule="if (protocol static ) { set ospf-ext-tag 10; reject; }"

With this in place, listing the routing table in another router (from the OSPF area), I'm seeing that routes listed as OSPF external (as expected) but even the route "rejected" is present and with the ospf-ext-tag=10 confirming the filter rule is being matched. (the ospf-ext-tag are only being used to help the debug)

Is this a bug? I'm I doing something wrong? Is there any simple/clean way of doing this tagging and filtering behavior?

Note the code above is only an reduced example, my real setup is using more routes from IPv4 & IPv6

regards.

BrateloSlava · Fri Mar 25, 2022 12:22 pm

In my opinion, something broke in this (7.1.5) update. In version 7.1.3 this configuration worked correctly for me.

/routing id add disabled=no id=172.22.99.254 name=id-slava select-dynamic-id=""
/routing ospf instance add name=rt-slava out-filter-chain=ospf-out redistribute=connected router-id=id-slava
/routing ospf area add instance=rt-slava name=backbone

/routing filter rule add chain=ospf-out comment="Allow LAN users to access OSPF routes" disabled=no rule="if ( dst in 172.22.99.0/24 ) { accept }"
/routing filter rule add chain=ospf-out comment="Allow VPN users to access OSPF routes" disabled=no rule="if ( dst in 172.16.0.0/16 ) { accept }"
/routing filter rule add chain=ospf-out comment="Block Guest users" disabled=no rule="if ( dst in 192.168.99.0/24 ) { reject }"

/routing ospf interface-template add area=backbone cost=100 networks=10.10.0.0/16 type=ptp
/routing ospf interface-template add area=backbone cost=101 networks=10.11.0.0/16 type=ptp
/routing ospf interface-template add area=backbone cost=103 networks=10.12.0.0/16 type=ptp

With this configuration, I blocked the network 192.168.99.0/24. But, after the update, this network became "visible" to the rest.

Let me explain. I am using the previous version (6.49.5) on some (90%) hosts on my network. And 10% - host with new (7.1.5). And the following situation is observed after the current update.
Host A (172.22.31.254, ROS 6.49.5).
Host B (172.22.99.254, ROS 7.1.5).
The node configuration with version 7.1.5 is listed above.
From node A, all devices that are located behind B are visible (both on the 172.22.99.0 network and on the 192.168.99.0 network). Although the network 192.168.99.0 should be hidden.
However, because of node B, the devices that are behind A are not visible. Some kind of nonsense.

On version 7.1.3 everything worked.

Is this a bug?

I think yes.

aleksis · Fri Mar 25, 2022 1:42 pm

"redistribute=..." overrides filter decision now so try to unset that.

BrateloSlava · Fri Mar 25, 2022 4:40 pm

"redistribute=..." overrides filter decision now so try to unset that.

Working. Thanks.

However, one problem remained.

Host A (172.22.31.254, ROS 6.49.5).
Host B (172.22.99.254, ROS 7.1.5).

Ping from A to B - working. But ping from B to A - not.
I repeat, that everything worked before updating to 7.1.5. Those, no new firewall rules or etc. were not add to config.

P.S.
I apologize to the author of the topic for starting a discussion of my problem here.

BrateloSlava · Sat Mar 26, 2022 8:21 am

However, one problem remained.
Host A (172.22.31.254, ROS 6.49.5).
Host B (172.22.99.254, ROS 7.1.5).
Ping from A to B - working. But ping from B to A - not.

I will answer myself.

Given, that on devices with version 6.49.5, I use the PTMP type - changing for devices with version 7.1.5 to PTMP Broadcast gave the result I needed.

/routing id add disabled=no id=172.22.99.254 name=id-slava select-dynamic-id=""
/routing ospf instance add name=rt-slava out-filter-chain=ospf-out router-id=id-slava
/routing ospf area add instance=rt-slava name=backbone

/routing filter rule add chain=ospf-out comment="Allow LAN users to access OSPF routes" disabled=no rule="if ( dst in 172.22.99.0/24 && dst-len in 24-32 ) { accept }"
/routing filter rule add chain=ospf-out comment="Allow VPN users to access OSPF routes" disabled=no rule="if ( dst in 172.16.0.0/16 && dst-len in 24-32 ) { accept }"
/routing filter rule add chain=ospf-out comment="Block Guest users" disabled=no rule="if ( dst in 192.168.99.0/24 ) { reject }"

/routing ospf interface-template add area=backbone comment=pool-L2TP cost=100 networks=10.10.0.0/16 type=ptmp-broadcast
/routing ospf interface-template add area=backbone comment=pool-SSTP cost=101 networks=10.11.0.0/16 type=ptmp-broadcast
/routing ospf interface-template add area=backbone comment=pool-PPTP cost=103 networks=10.12.0.0/16 type=ptmp-broadcast
/routing ospf interface-template add area=backbone comment="pool for EoIP & IPIP" cost=104 networks=10.13.0.8/30 type=ptp

aseques · Fri Apr 08, 2022 2:59 pm

"redistribute=..." overrides filter decision now so try to unset that.

Hi @aleksis, do you know where can I read more about this? Afaik in v6 the out-filter was applied after choosing the redstribute type.
So now I should remove the redistribute=connected and create the rules for the routes I want to propagate?

Thanks

sirbryan · Tue Apr 12, 2022 8:53 pm

"redistribute=..." overrides filter decision now so try to unset that.
Hi @aleksis, do you know where can I read more about this? Afaik in v6 the out-filter was applied after choosing the redstribute type.
So now I should remove the redistribute=connected and create the rules for the routes I want to propagate?

That is what support explained to me as well. But they neglected to mention it in the release notes and did not (at the time) update the documentation.

JoshDi · Tue Jul 26, 2022 8:44 pm

"redistribute=..." overrides filter decision now so try to unset that.

since which version is this true?

Will the following ospf-out-mesh filters redistribute rules if they are connected or protocol vpn?

/routing filter rule
add chain=ospf-in-mesh disabled=no rule="set distance 205;\
    \nset bgp-communities 65000:110;\
    \naccept;"
add chain=ospf-out-mesh disabled=no rule="if (dst in 10.70.72.1/32 && dst-len == 32) {\
    \n  reject;\
    \n}"
add chain=ospf-out-mesh disabled=no rule="if (dst in 10.70.91.1/32 && dst-len == 32) {\
    \n  reject;\
    \n}"
add chain=ospf-out-mesh disabled=no rule=\
    "if (dst in 10.0.0.0/8 && dst-len in 18-32 && (protocol connected || protocol vpn) ) {\
    \n  set ospf-ext-type type1; accept;\
    \n}"
add chain=ospf-out-mesh disabled=no rule="if (dst == 0.0.0.0/0 && (protocol connected || protocol vpn) ) {\
    \n  set ospf-ext-type type1; accept;\
    \n}"
add chain=ospf-out-mesh disabled=no rule="reject;"

BrateloSlava · Tue Jul 26, 2022 10:17 pm

As for me

/routing id add disabled=no id=172.22.1.254 name=id-tp select-dynamic-id=""
/routing ospf instance add disabled=no name=rt-tp originate-default=never redistribute=static router-id=id-tp

JoshDi · Tue Jul 26, 2022 10:23 pm

As for me

/routing id add disabled=no id=172.22.1.254 name=id-tp select-dynamic-id=""
/routing ospf instance add disabled=no name=rt-tp originate-default=never redistribute=static router-id=id-tp

I re-read the v7 OSPF documentation around redistribution and filters... I believe this thread is correct that anything set a redistribute, will be accepted and ignore filter rules that reject those routes.

https://help.mikrotik.com/docs/display/ ... faultRoute

Since redistribution is controlled by "originate-default" and "redistribute" parameter, it introduces some corner-cases for default route filtering.

if redistribute is enabled, then pick all routes matching redistribute parameters
If originate-default=never, default route will be rejected
run selected routes through out-select-chain (if configured)
run selected routes through out-filter-chain (if configured)
if originate-default is set to always or if-installed:
OSPF creates a fake default route without attributes;
runs this route through out-filter-chain where attributes can be applied, but action is ignored (always accept);

The last line is important in that block above.

Anyway, looking at ospf set up extract you sent, @BrateloSlava, all static routes will be redistributed no matter what ospf-out filters you have set up. Since you didnt share any OSPF-Out filters, I cannot debug if anything conflicts. The point here is that you could remove the redistribute static from the OSPF instance and then accept/reject static routes based on OSPF-Out filters. You can see in my post above, my filters accept certain IP ranges that are connected or created via VPN. If you wanted to do a similar thing with STATIC routes, you can filter based on "protocol STATIC"

BrateloSlava · Wed Jul 27, 2022 3:23 pm

@JoshDi
It seems to me, that incoming and outgoing filters should be used only when fine-tuning is necessary. Therefore, in most cases, I refused this option:

/routing filter rule add chain=ospf-out comment="redistribute default route - never, redistribute static routes - as type 1" disabled=yes rule="if ( dst != 0.0.0.0/0 && protocol static ) { set ospf-ext-metric 15; set ospf-ext-type type1; accept }"

JoshDi · Wed Jul 27, 2022 3:55 pm

@JoshDi
It seems to me, that incoming and outgoing filters should be used only when fine-tuning is necessary. Therefore, in most cases, I refused this option:
Code: Select all
/routing filter rule add chain=ospf-out comment="redistribute default route - never, redistribute static routes - as type 1" disabled=yes rule="if ( dst != 0.0.0.0/0 && protocol static ) { set ospf-ext-metric 15; set ospf-ext-type type1; accept }"

Yes, that is correct. Im part of a mesh network that has a relatively large and complicated PTMP network so fine tuning is required. However, that is not the case for everyone

Control OSPF static redistribution (ROS v6 vs v7)

Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)

Re: Control OSPF static redistribution (ROS v6 vs v7)