Community discussions

MikroTik App
 
complete2006
Member Candidate
Member Candidate
Topic Author
Posts: 254
Joined: Tue Feb 07, 2006 7:18 pm

QSPF question for experts

Sun Jun 12, 2016 8:58 am

Hi all.

Maybe someone can help me. I have the following problem: I have customers with a main fiber connection and a backup wireless connectings. Both lines are terminated at different of our locations. In the main connection I did the routing of the customer network with a static route with normal metric. In the backup location I use also a static route but with metric 200. Both locations are in the backbone ospf area. Everything is working as excepted. The static route in backup location is not active and the route is coming over OSPF. In case of fail of the primary line the backup route is going active and everything is fine. 

The problem: After the returning of the main line the backup route stays active regardless that there is an OSPF route with lower metric.  Is this by design? Who can help?
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: QSPF question for experts

Tue Jun 14, 2016 6:15 pm

floating static backup routes are a normal thing, and it sounds like you've done it properly. However, I've seen this behavior in ROS implementation of OSPF. In my case, it had to do with a floating static backup default GW that wouldn't go away when the primary returns to service. This is a bug in ROS. You may want to send an email to support about this.
 
complete2006
Member Candidate
Member Candidate
Topic Author
Posts: 254
Joined: Tue Feb 07, 2006 7:18 pm

Re: QSPF question for experts

Sat Jun 18, 2016 10:42 am

Thanks for your reply. I made a service call. I will inform here when I will get an answer.
 
complete2006
Member Candidate
Member Candidate
Topic Author
Posts: 254
Joined: Tue Feb 07, 2006 7:18 pm

Re: QSPF question for experts

Sat Jun 25, 2016 10:47 am

mikrotik support said that this is no bug. The implementation should prevent routing loop. This mean if a active static route is in the routing table the ospf route will not be installed. 

Who has solved this without script? As a second try I did a setup with with ospf and a stub customer area. This will not work too because the two backone routers don't know about the other. So the route is installed on both, regardless of interface cost. 
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: QSPF question for experts

Tue Jun 28, 2016 8:08 pm

mikrotik support said that this is no bug. The implementation should prevent routing loop. This mean if a active static route is in the routing table the ospf route will not be installed. 

Who has solved this without script? As a second try I did a setup with with ospf and a stub customer area. This will not work too because the two backone routers don't know about the other. So the route is installed on both, regardless of interface cost. 
Okay - it's time for me to lab this up in GNS3 to make sure I'm talking about the same thing I found with default route injection.....
And Mikrotik support initially told me the same thing "it's not a bug, it's there to prevent routing loops" and I told them that they've mis-interpreted the behavior a bit, and demonstrated the correct behavior in Cisco, to which they replied simply "ok - it's a bug and will be fixed in future ROS" - I guess that ticket got closed and forgotten about.  :?
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: OSPF question for experts - BUG!

Tue Jun 28, 2016 9:08 pm

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.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: QSPF question for experts

Tue Jun 28, 2016 9:23 pm

I also dug up my previous report of this bug, and Mikrotik stated that this behavior will be fixed in ROSv7.

This seems like too large of a bug to leave un-fixed in ROSv6.
 
User avatar
bajodel
Long time Member
Long time Member
Posts: 551
Joined: Sun Nov 24, 2013 8:30 am
Location: Italy

Re: QSPF question for experts

Wed Jul 13, 2016 11:20 pm

I also dug up my previous report of this bug, and Mikrotik stated that this behavior will be fixed in ROSv7.

This seems like too large of a bug to leave un-fixed in ROSv6.
I Absolutely agree with you! Thanx for your lab works and detailed report.
 
StefanM
newbie
Posts: 49
Joined: Sun Dec 13, 2015 1:49 am

Re: QSPF question for experts

Sun Jul 17, 2016 9:15 pm

I also dug up my previous report of this bug, and Mikrotik stated that this behavior will be fixed in ROSv7.

This seems like too large of a bug to leave un-fixed in ROSv6.
i wasn't aware of this, thanks! And am joining to a list that this needs to be fixed in next stabile update of ROSv6, not to wait till ROSv7 as who knows when can we see it in RC version..
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4047
Joined: Wed May 11, 2011 6:08 pm

Re: QSPF question for experts

Mon Jul 18, 2016 4:52 pm

Replies from support make it seem pretty certain that Mikrotik does not intend to address this issue in ROSv6 due to underlying OSPF implementation issues. In other words, v7 is going to feature a major code overhaul in the way routing is implemented, and that such a thing is required to fix this behavior, therefore it must be done in ROSv7.
(sadly)
 
JJT211
Frequent Visitor
Frequent Visitor
Posts: 56
Joined: Sun Apr 28, 2019 9:01 pm

Re: QSPF question for experts

Sun May 16, 2021 3:24 am

BUMP

5 years later and we're finally in ROSv7 territory. Im curious if this issue has been addressed in a previous ROSv6 release or the current ROSv7 Beta.

EDIT:
I figure it better to update this thread than to necro another. According to this post, it has not been addressed and still remains. But there is a workaround.

It's 2020 and the problem still exists.

A work around for whoever finds this article:

Inject two smaller routes on the router with the preferred link, smaller routes should always win over bigger routes.

eg:
Use the static routes 10.2.3..0/25 + 10.2.3.128/25
instead of 10.2.3.0/24 on the preferred link.

Who is online

Users browsing this forum: GoogleOther [Bot], onnyloh and 20 guests