I have replicated the problem with the following setup:
ospf.png
R1 and R2 are configured as ASBR routers - redistributing static into OSPF as Type-1 external routes.
R1 has a static blackhole route for 172.16.0.0/16
R2 has a floating static backup route for 172.16.0.0/16 with distance set to 200.
OSPF uses area 0 on the 192.168.1.0/24 network.
R3 is present just as a client showing what other nodes will see advertised from R1 and R2.
Here are the configurations of the routers:
R1
[admin@R1] > export compact
# jun/28/2016 17:59:17 by RouterOS 6.36rc13
# software id =
#
/interface bridge
add name=loop
/interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=10.10.10.1
/ip address
add address=10.1.1.1/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=10.10.10.1 interface=loop network=10.10.10.1
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
/ip route
add distance=1 dst-address=172.16.0.0/16 type=blackhole comment="test route primary"
/routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/system identity
set name=R1
R2
[admin@R2] > export compact
# jun/28/2016 17:29:51 by RouterOS 6.36rc13
# software id =
#
/interface bridge
add name=loop
/interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=10.10.10.2
/ip address
add address=10.1.1.2/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=10.10.10.2 interface=loop network=10.10.10.2
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
/ip route
add distance=200 dst-address=172.16.0.0/16 type=blackhole comment="test route backup"
/routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/system identity
set name=R2
R3:
[admin@R3] > /export compact
# jun/28/2016 17:30:17 by RouterOS 6.36rc13
# software id =
#
/interface bridge
add name=loop
/interface ethernet
set [ find default-name=ether4 ] comment=mgmt
/routing ospf instance
set [ find default=yes ] router-id=10.10.10.3
/ip address
add address=10.1.1.3/24 comment=mgmt interface=ether4 network=10.1.1.0
add address=192.168.1.3/24 interface=ether1 network=192.168.1.0
add address=10.10.10.3 interface=loop network=10.10.10.3
/routing ospf network
add area=backbone network=10.10.10.0/24
add area=backbone network=192.168.1.0/24
/system identity
set name=R3
While everything is normal, R3 shows:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.1 110
If I disable the route to 172.16.0.0/16 in R1, then R2 takes over properly:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.2 110
When I re-enable the static route on R1, then R2 refuses to drop its advertisement based on a 200-distance static route, and R3 now has an ECMP balance route installed:
[admin@R3] /ip route> print where dst-address=172.16.0.0/16
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.2 110
192.168.1.1
Obviously, the ECMP could be fixed by modifying the base metric injected at R2, but this is beside the point - the point is that clearly the lower distance path to reach 172.16.0.0/16 at R2 is the OSPF path, which has a distance of 110.
However, OSPF is IMPROPERLY ignoring this update due to the fact that it is already originating this route based on its own static route.
[admin@R2] /ip route> print where dst-address=172.16.0.0/16
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 A SB 172.16.0.0/16 200
(note the missing OSPF route - it's not even present-but-disabled)
If I disable the static route and re-activate it in R2, then it returns to normal:
[admin@R2] /ip route> print where dst-address=172.16.0.0/16
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADo 172.16.0.0/16 192.168.1.1 110
1 SB 172.16.0.0/16 200
This faulty behavior also holds true when the routers are injecting default-information into OSPF based on some other protocol. (static, BGP, etc)
------
If I create the same topology in Cisco, then the expected behavior occurs: When R1 re-asserts connectivity to 172.16.0.0/16, R2 withdraws its own external-type-1 route from OSPF, and installs the new external-type-1 route via R1 from OSPF into the RIB. I am not saying that ROS must do everything that Cisco does - they're different platforms, but when ROS has broken behavior, it is useful to show that other platforms do not behave in this way.
I will send another bug report to Mikrotik referencing this post for details.
You do not have the required permissions to view the files attached to this post.