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
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.
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.
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.
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.
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.
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”
@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 }"
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
