OSPF area id 0.0.0.0 does not consider interface cost

szuwaaar · Wed Mar 19, 2025 3:24 pm

Hi,

I have 4 routers, connected to each other like so:

. Every router runs 7.18.2

In this scenario traffic from A to D will always go A - C - D ( area 1.1.1.1).

Even if I set up interface cost to 700 on interfaces: A - C and C - D traffic from A to D is not routed through router B ( area 0.0.0.0)

It starts to work, as expected , when I change area ID from 0.0.0.0 to something else, for example 7.7.7.7. Then I can manipulate the traffic using interface cost.

Why area ID 0.0.0.0 is not used even if the interface cost is lower than in area 1.1.1.1?

Both areas type: default

kind regards

mrz · Wed Mar 19, 2025 3:59 pm

This is by OSPF design. An area where the prefix originated is more preferred.

szuwaaar · Wed Mar 19, 2025 4:24 pm

So there is no way that I can force communication between A to D through B using area id 0.0.0.0? Prefix 10.0.0.1/32 or 10.0.0.4/32 does not belong to any area. Its addressed on ABRs ( on loopback interface - bridge with no ports assigned to it )

szuwaaar · Wed Mar 19, 2025 5:30 pm

I think I can see my error now. I was using redistribute="connected" in /routing/ospf/instance to add loopback address to OSPF instead of configure it under : /routing/ospf/interface-template with the proper area parameter

Larsa · Wed Mar 19, 2025 5:54 pm

No need to use multiple areas, loopback interfaces, Stub, NSSA, or filters. In your scenario, just use a single area, and costs will work as expected. (Routing->OSPF->Interface Templates)

szuwaaar · Thu Mar 20, 2025 1:02 pm

I have over 500 Mikrotik routers in my network, some of them connected using l2tp links over LTE, generating a lot of disconnects and topology changes, thats why I consider implementing areas. I just encounter a problem and build a small lab to isolate this problem.

Right now, loopback address of router D 10.0.0.4/32 ( which belongs to backbone area ) is not accessible from router A ( 10.0.0.1/32 also backbone area) when link A - B or B - D goes down. Which is strange, because router C has 10.0.0.4/32 in his routing table, but does not pass it do routera A.

routers configuration:
router A:

/routing ospf instance
add disabled=no name=ospf-instance-1 redistribute="" router-id=10.0.0.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=backbone
add area-id=1.1.1.1 disabled=no instance=ospf-instance-1 name=test
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether2 networks=172.16.13.0/30
add area=test disabled=no interfaces=ether3 networks=172.16.11.0/30
add area=backbone disabled=no interfaces=loopback networks=10.0.0.1/32

-
router B:

/routing ospf instance
add disabled=no name=ospf-instance-1 redistribute="" router-id=10.0.0.2
/routing ospf area
add disabled=no instance=ospf-instance-1 name=backbone
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether3 networks=172.16.13.0/30
add area=backbone disabled=no interfaces=ether2 networks=172.16.13.4/30
add area=backbone disabled=no interfaces=loopback networks=10.0.0.2/32

-
router C:

/routing ospf instance
add disabled=no name=ospf-instance-1 redistribute="" router-id=10.0.0.3
/routing ospf area
add area-id=1.1.1.1 disabled=no instance=ospf-instance-1 name=test
/routing ospf interface-template
add area=test disabled=no interfaces=ether3 networks=172.16.11.0/30
add area=test disabled=no interfaces=ether2 networks=172.16.11.4/30
add area=test disabled=no interfaces=loopback networks=10.0.0.3/32

-
router D:

/routing ospf instance
add disabled=no name=ospf-instance-1 redistribute="" router-id=10.0.0.4
/routing ospf area
add disabled=no instance=ospf-instance-1 name=backbone
add area-id=1.1.1.1 disabled=no instance=ospf-instance-1 name=test
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether2 networks=172.16.13.4/30
add area=test disabled=no interfaces=ether3 networks=172.16.11.4/30
add area=backbone disabled=no interfaces=loopback networks=10.0.0.4/32

Larsa · Thu Mar 20, 2025 2:28 pm

The following recommendations are general since you haven’t described the overall topology of the solution.

With over 500 subnets, I’d definitely consider using multiple OSPF areas, particularly Stub Areas or NSSA for your LTE links if they are not part of a transit path. Use area summarization at ABRs and LSA filtering to keep OSPF stable and reduce overhead. If an LTE link is part of an active route and not isolated within a Stub/NSSA area, routing changes will still affect the entire network, that’s simply how OSPF works. If you want more fine-grained control over routing changes and costs, you can always use OSPF filters.

Also, if you haven’t already, make sure to enable BFD on all redundant backbone links for fast failover within a few milliseconds. Otherwise, you'll be using the standard OSPF Hello Interval of 10 seconds and a Dead Interval of 40 seconds.

Btw, why even use loopback interfaces? On MikroTik ROS, it’s just extra admin work if you’ve already set the OSPF Router ID using a IP address, which is best practice and almost always necessary for monitoring and management.

szuwaaar · Thu Mar 20, 2025 5:34 pm

Loopback address was just an example. Any network connected to router D and configured under /routing/ospf/interface-template/ with area id 0.0.0.0. will not be accessible by router A after failure of A-B or B-D link. Despite being present in routing table on router C. For example I will add another network to router D: 192.168.99.0/24

Here is a fragment of LSA on router A when link A-B or B-D fails, that considers 192.168.99.0/24 network:

 
19  D instance=ospf-instance-1 area=test type="inter-area-prefix" originator=10.0.0.4 id=192.168.99.0 sequence=0x80000002 age=758 checksum=0xA76 body=
        netmask=255.255.255.0
        metric=1

It is present in LSA, but router A does not install the prefix in his routing table

Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS       GATEWAY             DISTANCE
DAc 172.16.11.0/30    ether3                     0
DAo 172.16.11.4/30    172.16.11.2%ether3       110
DAc 172.16.13.0/30    ether2                     0
DAc 10.0.0.1/32       lo                         0
DAo 10.0.0.2/32       172.16.13.2%ether2       110
DAo 10.0.0.3/32       172.16.11.2%ether3       110

I am using loopback for VPLS tunnels.

Larsa · Thu Mar 20, 2025 6:20 pm

Some troubleshooting tips:

Enable BFD on all links to get a fast response when toggling links or making other changes.
Set up OSPF logging on all routers to check if they are sending and receiving proper LSA messages. (/system logging add topics=ospf,!packet action=memory). If you can't spot inbound LSA messages, OSPF might be filtered by the firewall.
Toggle or break a link and check LSA messages in the log and also with "/routing ospf neighbor" to verify that the OSPF neighbors are updated and propagation works.
Try a route injection by manually adding a route on node 'A' to see if it works as expected and sends the proper LSA messages. If not, there might be a misconfiguration somewhere.

szuwaaar · Tue Mar 25, 2025 2:52 pm

After link failure, router A does receive updates about 10.0.0.4/32 from router C, but does not insert them in routing table.

#------------------------LINK A to B working
2025-03-17 12:56:39 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } backbone { 0.0.0.0 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x8000015b csum: 0xb586 } received refresh 
2025-03-17 12:56:39 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } backbone { 0.0.0.0 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x8000015c csum: 0xb387 } schedule decay age: 3598 
2025-03-17 12:56:39 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } backbone { 0.0.0.0 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x8000015c csum: 0xb387 } flooding 
2025-03-17 13:11:45 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000145 csum: 0x173c } received refresh 
2025-03-17 13:11:45 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000146 csum: 0x153d } schedule decay age: 3598 
2025-03-17 13:11:45 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000146 csum: 0x153d } flooding 
2025-03-17 13:12:23 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } backbone { 0.0.0.0 } lsa { inter-area-router originator: 10.0.0.1 id: 10.0.0.4 seq: 0x80000002 csum: 0x64db } flooding 
2025-03-17 13:14:07 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.1 id: 10.0.0.4 seq: 0x80000002 csum: 0x7cc3 } flooding 
2025-03-17 13:15:10 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000001 csum: 0x68d3 } received refresh 
2025-03-17 13:15:10 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000002 csum: 0x66d4 } schedule decay age: 3598 
2025-03-17 13:15:10 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000002 csum: 0x66d4 } flooding 
#------------------------Failure of link from A to B occured here
2025-03-17 13:16:00 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.1 id: 10.0.0.4 seq: 0x80000002 csum: 0x7cc3 } originator flush 
2025-03-17 13:16:00 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.1 id: 10.0.0.4 seq: 0x80000002 csum: 0x7cc3 flushing } flooding 
2025-03-17 13:16:00 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000002 csum: 0x66d4 } received flush 
2025-03-17 13:16:00 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-router originator: 10.0.0.4 id: 10.0.0.4 seq: 0x80000002 csum: 0x66d4 flushing } flooding 
2025-03-17 13:18:34 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.4 id: 10.0.0.4 seq: 0x800000ec csum: 0x80d3 } received refresh 
 2025-03-17 13:18:34 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.4 id: 10.0.0.4 seq: 0x800000ed csum: 0x7ed4 } schedule decay age: 3598
 2025-03-17 13:18:34 route,ospf,debug ospf-instance-1 { version: 2 router-id: 10.0.0.1 } test { 1.1.1.1 } lsa { inter-area-prefix originator: 10.0.0.4 id: 10.0.0.4 seq: 0x800000ed csum: 0x7ed4 } flooding

Larsa · Tue Mar 25, 2025 5:28 pm

It sounds like there might be some kind of misconfiguration. If you're absolutely sure everything is set up correctly, I’d recommend reaching out to support for further assistance. I don't have the time or resources to set up a test environment to check this for you, I hope you understand.

A few additional tips:

- Ensure Proper OSPF Area Configuration:
Make sure that both Router A and Router C are correctly configured in the same area, or have proper inter-area configurations for routing to work seamlessly. Also, ensure that all necessary OSPF areas are correctly advertised.

- Verify LSA types:
Check your logs for inter-area-prefix LSAs. Ensure that Router A is set up to properly accept inter-area LSAs. Also, check if the LSA is being filtered or there might be some route filtering or redistribution causing issues.

- Verify OSPF neighbor relationships:
Check the OSPF neighbor status to make sure Router A and Router C are still exchanging LSAs correctly. You can use "/routing ospf instance print" and "/routing ospf interface print" for info about OSPF instances and the interfaces involved, including the neighbor relationships

- OSPF route table:
Double-check if the route is actually being dropped or added by OSPF. You can do this by checking the OSPF route table with "/ip route print where ospf". This will display the routes installed by OSPF. If the route isn't appearing, it could indicate a problem with OSPF's route calculation or filtering.

- Route table test:
Try manually adding the route to Router A’s table like "/ip route add dst-address=192.168.99.0/24 gateway=10.0.0.4". This will help verify if the route works independently of OSPF and if the path is reachable..

- OSPF timers:
If not using BFD, check that the Hello and Dead intervals are consistent across all routers in the same OSPF network segment (same subnet or broadcast domain, i.e., LAN). If they don’t, OSPF neighbors won’t form or maintain an adjacency.

OSPF area id 0.0.0.0 does not consider interface cost

OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost

Re: OSPF area id 0.0.0.0 does not consider interface cost