Hello.
Is it possible to “overwrite” locally inserted default-gateway with the one got via ospf ?
I mean if I have 2 mikrotiks with ospf running and both boxes have different default-gateways. I want all the traffic go through only one of them until it goes down.
RGDS
Sure!
Your default route should be set as “distribute-default=if-installed-as-type1” and the static gateways should have check-gateway=ping to disable it if it’s not reachable. Of course if the gateway is a ADSL router, you should use a recursive gateway to ensure the check gateway to work properly.
It doesn’t work.
I put 2 mikrotik boxes, both 6.27.
Each has it’s own default-gateway - both are different ones. Both have OSPF running.
All works fine until I turn on “redistributedefult route” on second router. After that is use ONLY it’s own static default-gw. Ospf injection does’t work 
Here configs
/interface ethernet
set [ find default-name=ether1 ] name=ether1-OUT1
set [ find default-name=ether2 ] name=ether2-R2
/routing ospf instance
set [ find default=yes ] distribute-default=if-installed-as-type-1 name=R1 \
redistribute-connected=as-type-1 router-id=255.255.255.255
/ip address
add address=192.168.0.2/24 interface=ether1-OUT1 network=192.168.0.0
add address=10.255.0.6/30 interface=ether2-R2 network=10.255.0.4
add address=192.168.90.1/24 interface=ether4 network=192.168.90.0
/ip route
add distance=1 gateway=192.168.0.1
/routing ospf network
add area=backbone network=10.255.0.4/30
/system identity
set name=R1
/interface ethernet
set [ find default-name=ether5 ] name=ether5-OUT2
set [ find default-name=ether6 ] name=ether6-R1
/routing ospf area
set [ find default=yes ] name=R2
/routing ospf instance
set [ find default=yes ] distribute-default=if-installed-as-type-1 \
metric-default=100 name=R2 redistribute-connected=\
as-type-1
/ip address
add address=192.168.88.1/24 interface=ether8 network=192.168.88.0
add address=10.255.0.5/30 interface=ether6-R1 network=10.255.0.4
add address=192.168.1.23/24 interface=ether5-OUT2 network=192.168.1.0
/ip route
add check-gateway=ping distance=200 gateway=192.168.1.1
/routing ospf network
add area=R2 network=10.255.0.4/30
/system identity
set name=R2
But on R2 we see
[admin@R2] > routing ospf neighbor pr
0 instance=R2 router-id=255.255.255.255 address=10.255.0.6 interface=ether6-R1
priority=1 dr-address=10.255.0.6 backup-dr-address=10.255.0.5 state="Full"
state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=13m54s
[admin@R2] >
But R2 uses it’s own default gw!
[admin@R2] > ip rou pr
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 S 0.0.0.0/0 192.168.1.1 200
1 ADC 10.255.0.4/30 10.255.0.5 ether6-R1 0
2 ADo 192.168.0.0/24 10.255.0.6 110
3 ADC 192.168.1.0/24 192.168.1.23 ether5-OUT2 0
4 DC 192.168.88.0/24 192.168.88.1 ether8 255
[admin@R2] >
Just for info
[admin@R2] > routing ospf route pr
# DST-ADDRESS STATE COST GATEWAY INTERFACE
0 0.0.0.0/0 imported-ext-1 100
1 10.255.0.4/30 intra-area 10 0.0.0.0 ether6-R1
2 192.168.0.0/24 ext-1 30 10.255.0.6 ether6-R1
3 192.168.1.0/24 imported-ext-1 100
[admin@R2] >
Is the OSPF learned default route you are trying to use being imported from another routing table (VRF/Route Mark)?
Nope.
You see the whole configuration of mikrotiks - they are just standing on my table.
In my experience, working with ROS v6.17 (and a few earlier versions of 6), it’s sort of possible to get this to happen, but it will require manual (or scripted) intervention after network topology changes.
On R1 (the primary out), you would continue as you have it set up – the static default route has a cost of less than 110 and is set to check gateway (ping or arp, depending on how the gateway is setup), OSPF is set up to redistribute if installed (as either t1 or t2, doesn’t make any difference in a 2 default route setup).
On R2 (the secondary out), you set up the static route with a cost of more than 110 and check gateway, set up OSPF to redistribute if installed. But, in order to get it to actually install the OSPF route in the local router’s routing table, you must disable the static route first. If the static default route is disabled, OSPF will install its learned default route in the local routing table. After the OSPF route installs, you can then enable the static default route, which will sit there unused (and not redistribute into OSPF) until the R1 route fails.
However, you will have to manually disable the static default route on R2 after every time it becomes active – once R1 comes back up, you’ll still have both static routes active until the R2 route is disabled & re-enabled as above.
I already found this circus with manual enable/disable default route on R2 but I think that’s incorrect!
BTW do you have a working script to mange this issue ?
The only place I use it at, manual intervention is sufficient for my needs, so I haven’t done any scripting work towards trying to automate the recovery.
Please post the output of
routing ospf lsa print detail
[admin@R2] > routing ospf lsa pr de
instance=R2 area=R2 type=router id=192.168.88.1 originator=192.168.88.1
sequence-number=0x80000006 age=32 checksum=0x3F67 options="E"
body=
flags=EXTERNAL
link-type=Transit id=10.255.0.2 data=10.255.0.1 metric=10
instance=R2 area=R2 type=router id=192.168.89.1 originator=192.168.89.1
sequence-number=0x80000002 age=953 checksum=0x3D6C options="E" body=
flags=
link-type=Transit id=10.255.0.2 data=10.255.0.2 metric=10
instance=R2 area=R2 type=router id=255.255.255.255
originator=255.255.255.255 sequence-number=0x80000003 age=951
checksum=0xB76E options="E" body=
flags=EXTERNAL
link-type=Transit id=10.255.0.6 data=10.255.0.6 metric=10
instance=R2 area=R2 type=network id=10.255.0.2 originator=192.168.89.1
sequence-number=0x80000001 age=953 checksum=0xC83E options="E"
body=
netmask=255.255.255.252
routerId=192.168.89.1
routerId=192.168.88.1
instance=R2 area=R2 type=network id=10.255.0.6 originator=255.255.255.255
sequence-number=0x80000001 age=951 checksum=0x6B1F options="E"
body=
netmask=255.255.255.252
routerId=255.255.255.255
routerId=192.168.88.1
instance=R2 area=external type=as-external id=0.0.0.0
originator=192.168.88.1 sequence-number=0x80000001 age=963 checksum=0x6771
options="E" body=
netmask=0.0.0.0
forwarding-address=0.0.0.0
metric=10000
route-tag=0x0
type2
instance=R2 area=external type=as-external id=0.0.0.0
originator=255.255.255.255 sequence-number=0x80000001 age=993
checksum=0x69E8 options="E" body=
netmask=0.0.0.0
forwarding-address=0.0.0.0
metric=1
route-tag=0x0
type1
instance=R2 area=external type=as-external id=192.168.0.0
originator=255.255.255.255 sequence-number=0x80000001 age=993
checksum=0x765F options="E" body=
netmask=255.255.255.0
forwarding-address=0.0.0.0
metric=20
route-tag=0x0
type1
instance=R2 area=external type=as-external id=192.168.1.0
originator=192.168.88.1 sequence-number=0x80000001 age=1003
checksum=0xEE23 options="E" body=
netmask=255.255.255.0
forwarding-address=0.0.0.0
metric=20
route-tag=0x0
type1
On R2, set the distance to 200 on your static default gateway.
(double check this - note the distance on other routes learned by OSPF, and make sure that your backup default GW statement is a higher number than that distance)
You don’t need scripts, etc.
The problem is the metric for your static default gateway.
By default, static routes are “better” than dynamic routes.
DLNoah’s solution is correct. One thing I would add is to make sure that your test pings from R1 cannot successfully go out R2, and cause R1 to think it is still connected to the Internet. Your connection will flap up and down while the connection on R1 is broken. (Filter them on R2, or make /32 route on R1 forcing ISP1)
Another thing you can do in your design (if you have other routers R3, R4, R5, etc) is to make R2 generate default information with a “worse” metric than R1 so that in case both routers are announcing default routes into your network, the network will prefer the ones from R1. Remember: OSPF chooses Type 1 external routes before Type 2 no matter what the metrics are.
No help anyway.
[admin@R2] > ip rou pr
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 S 0.0.0.0/0 192.168.1.1 200
1 ADC 10.255.0.0/30 10.255.0.1 ether7-R3 0
2 DC 10.255.0.4/30 10.255.0.5 ether6-R1 255
3 ADC 192.168.1.0/24 192.168.1.23 ether5-OUT2 0
4 DC 192.168.88.0/24 192.168.88.1 ether8 255
[admin@R2] >
Both boxes are on the table connected with 1 m cable only. So pings are going without any problems.
I know that. But the goal is to force R2 to mandatory use R1 as a default gw while R1 has default gw installed.
That part was an “extra” - how to get purely ospf routers to decide automatically…
Anyway, I just thought of something that might be the problem with this:
Scope.
(Route scope is something that hasn’t just clicked in my head yet, but I’m trying)
Static routes go into scope 10, and igp protocols like OSPF work in scope 20.
I wonder if you made the floating backup static route use scope 20, if that would fix the problem…
You loose!
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
0 A S dst-address=0.0.0.0/0 gateway=192.168.1.1
gateway-status=192.168.1.1 reachable via ether5-OUT2
check-gateway=ping distance=200 scope=20 target-scope=20
1 ADC dst-address=10.255.0.0/30 pref-src=10.255.0.1 gateway=ether7-
gateway-status=ether7-R3 reachable distance=0 scope=10
2 DC dst-address=10.255.0.4/30 pref-src=10.255.0.5 gateway=ether6-
gateway-status=ether6-R1 unreachable distance=255 scope=10
3 ADC dst-address=192.168.1.0/24 pref-src=192.168.1.23 gateway=ethe
gateway-status=ether5-OUT2 reachable distance=0 scope=10
4 DC dst-address=192.168.88.0/24 pref-src=192.168.88.1 gateway=eth
gateway-status=ether8 unreachable distance=255 scope=10
[admin@R2] >
Rats! I was sure that was it. 
If you disable the static to get the OSPF route, what scope does it get?
[admin@R2] > ip rou pr de
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
0 ADo dst-address=0.0.0.0/0 gateway=10.255.0.6
gateway-status=10.255.0.6 reachable via ether6-R1 distance=110
scope=20 target-scope=10 ospf-metric=11 ospf-type=external-type-1
1 S dst-address=0.0.0.0/0 gateway=192.168.1.1
gateway-status=192.168.1.1 reachable via ether5-OUT2
check-gateway=ping distance=200 scope=20 target-scope=20
2 DC dst-address=10.255.0.0/30 pref-src=10.255.0.1 gateway=ether7-R3
gateway-status=ether7-R3 unreachable distance=255 scope=10
3 ADC dst-address=10.255.0.4/30 pref-src=10.255.0.5 gateway=ether6-R1
gateway-status=ether6-R1 reachable distance=0 scope=10
4 ADo dst-address=192.168.0.0/24 gateway=10.255.0.6
gateway-status=10.255.0.6 reachable via ether6-R1 distance=110
scope=20 target-scope=10 ospf-metric=30 ospf-type=external-type-1
5 ADC dst-address=192.168.1.0/24 pref-src=192.168.1.23 gateway=ether5-OUT2
gateway-status=ether5-OUT2 reachable distance=0 scope=10
6 DC dst-address=192.168.88.0/24 pref-src=192.168.88.1 gateway=ether8
gateway-status=ether8 unreachable distance=255 scope=10
[admin@R2] >
This is one thing about Mikrotik that frustrates me - some things that “just work” in other platforms either do not work, or require some strange configuration in Mikrotik.
Don’t get me wrong, I love the platform, but sometimes I just end up pulling my hair.
When I get to my office later this morning, I’m going to try some experimentation on this matter.
I can send you mk configs if you wish to.
If I get different results than you do, I’ll have a look at you configs.
I’m running v6.27 as well, so results should be similar.