OSPF Not Behaving Correctly

RouterOS Forwarding Protocols
1

Hello everyone,

I recently upgraded my edge router from v6 to v7 by manually configuring a new router and not doing an in place upgrade. When I swap the routers I get an undesirable outcome on my OSPF routing decision. I have two DCs that both use MikroTiks as edge routers, and I have two GRE tunnels between them one with a symmetric cost of 100 and the other 200. The v7 router, instead of choosing the least cost for the networks advertised, load-balances the traffic between the two GRE tunnels (192.168.106.20/30), and even installs multiples of the routes advertised by my NSX routers (192.168.119.0/24). This behavior is the same with redistributed routes, connected routes advertised from the other router. Configuration and routing output posted:

# 2023-07-23 11:07:51 by RouterOS 7.10.2
# model = CCR1072-1G-8S+

/ip address
add address=192.168.102.89/30 interface=DC2-MPLS-GRE network=192.168.102.88
add address=192.168.102.85/30 interface=DC2-Internet-GRE network=192.168.102.84

/routing ospf instance
add disabled=no name=ospf-instance-1 out-filter-chain=ospf-out redistribute=static router-id=192.168.99.1

/routing ospf interface-template
add area=ospf-area-0 cost=100 dead-interval=10s disabled=no hello-interval=3s interfaces=DC2-MPLS-GRE priority=250 type=ptp
add area=ospf-area-0 cost=200 dead-interval=10s disabled=no hello-interval=3s interfaces=DC2-Internet-GRE priority=250 type=ptp
add area=ospf-area-0 cost=100 dead-interval=10s disabled=no hello-interval=3s interfaces=vlan391-NSXT-Uplink priority=250

/ip/route/print detail
   DAo + dst-address=192.168.106.20/30 routing-table=main gateway=192.168.102.90%DC2-MPLS-GRE immediate-gw=192.168.102.90%DC2-MPLS-GRE distance=110 scope=20 target-scope=10 
         suppress-hw-offload=no 

   DAo + dst-address=192.168.106.20/30 routing-table=main gateway=192.168.102.90%DC2-MPLS-GRE immediate-gw=192.168.102.90%DC2-MPLS-GRE distance=110 scope=20 target-scope=10 
         suppress-hw-offload=no 

   DAo + dst-address=192.168.106.20/30 routing-table=main gateway=192.168.102.86%DC2-Internet-GRE immediate-gw=192.168.102.86%DC2-Internet-GRE distance=110 scope=20 target-scope=10
         suppress-hw-offload=no
   DAo + dst-address=192.168.119.0/24 routing-table=main gateway=192.168.118.162%vlan391-NSXT-Uplink immediate-gw=192.168.118.162%vlan391-NSXT-Uplink distance=110 scope=20 target-scope=10 suppress-hw-offload=no 

   DAo + dst-address=192.168.119.0/24 routing-table=main gateway=192.168.118.162%vlan391-NSXT-Uplink immediate-gw=192.168.118.162%vlan391-NSXT-Uplink distance=110 scope=20 target-scope=10 suppress-hw-offload=no

I should mention that similar configuration using CHRs in lab does not reproduce the issue.

Any help or tip is appreciated.

2

hello msanaii,

is this setup - a triangle shaped between those 3 devices?

   |-------- mt1 path 100
nsx          | |
   |-------- mt2 path 200

am i correct?

are you just want to drive the traffic to use mt1 as main, and mt2 as backup?

just use lower path priority for the mt2.
ie. mt1 128, mt2 64.

hope this helps.

3

Here is my diagram:
https://postimg.cc/jDMw01wW

The issue I’m having is although I have set the cost as 100 and 200, the traffic is load-balanced between the two tunnels. This seems like a bug on v7 because it doesn’t happen on the CHR. And regarding the NSX part, I don’t mind if the traffic is load-balanced, but I see duplicates of the same network with the same next-hop, which is another issue on its own.

Thanks.

4

hello,

for this part,

have two GRE tunnels between them one with a symmetric cost of 100 and the other 200. The v7 router, instead of choosing the least cost for the networks advertised, load-balances the traffic between the two GRE tunnels (192.168.106.20/30),

use path priority instead of path cost.
128 higher preference.
64 lesser preference.

for this part,

and even installs multiples of the routes advertised by my NSX routers (192.168.119.0/24).

it is a correct behavior since the ecmp routes are there.

don’t worry, ospf knows which interface to forward the traffic - by that path priority.

hope this helps.

5

As far as I know, priority is used to determine DR and BDR roles…

For the ECMP part you mentioned, I should see two different next-hops and not the same.

6

hello,

As far as I know, priority is used to determine DR and BDR roles…

that’s router-id in ospf instance config.

I was referring to interface path priority - not related to any dr-bdr roles.

For the ECMP part you mentioned, I should see two different next-hops and not the same.

two different next hop they are - you have 2 redundant links. do you have any other thoughts?

7

My dear Wiseroute,

I’m not sure if you’re referring to /routing/ospf/interface-template:priority which is in fact for DR and BDR election according to OSPF documentation:
https://help.mikrotik.com/docs/display/ROS/OSPF

Now, getting back to the topic at hand, the router is behaving as expected after a reboot, but I cannot trust it enough to move load to it again.

I have send MikroTik support an email and included the support.rif file and am waiting for a response. Will update if I find anything else.

Thank you.

8

hello,

you might want to read this post, i have made a simple ospf interface path priority lab - almost similar to your problem.

http://forum.mikrotik.com/t/ospf-wireguard-and-multiple-path-problem/167204/1

hope this helps.

9

According to SUP-123027, there was a routing protocol crash. When it happens old routes stay in the routing table, router reboot will get rid of all the bogus routes.

10

I have a similar issue with OSPF, when changing address of the interface or manipulating with the physical interface the routing remains suspended. Sometimes even it chooses the wrong gateway. Only a reboot helped.

Do you know if the fix will be released in the next releases?