OSPF Routes not propagating

RouterOS Forwarding Protocols
1

I’ve been working on deploying OSPF since ROS5.0 was released. I’m now up to 5.4 on some routers, and am having a frequent issue that is sure to cause some problems later down the road.

One unit, in particular:

IP Addresses:

 #   ADDRESS            NETWORK         INTERFACE                                                                          
 0   172.17.84.142/30   172.17.84.140   backhaul                                                                           
 1   172.17.84.52/32    172.17.84.52    lo0                                                                                
 2   172.17.87.241/29   172.17.87.240   bridge1

Routes:

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          172.17.84.141           110
 1 ADC  172.17.84.52/32    172.17.84.52    lo0                       0
 2 ADC  172.17.84.140/30   172.17.84.142   backhaul                  0
 3 ADC  172.17.87.240/29   172.17.87.241   bridge1                   0

ospf networks

 #   NETWORK            AREA                                                                                               
 0   172.17.84.52/32    backbone                                                                                           
 1   172.17.84.140/30   backbone                                                                                           
 2   172.17.87.240/29   backbone

OSPF Interfaces

 #    INTERFACE                                              COST PRIORITY NETWORK-TYPE   AUTHENTICATION AUTHENTICATION-KEY
 0 DP lo0                                                      10        1 broadcast      none                             
 1 D  bridge1                                                  10        1 broadcast      none                             
 2 D  backhaul                                                 10        1 broadcast      none

Neighbors come right up, and after a a few moments, the routing tables are flooded. The problem, is that the neighbor on the backhaul interface isn’t getting the route for the LAN:

 /routing ospf route> print where interface=PTP-HES 
 # DST-ADDRESS        STATE          COST                   GATEWAY         INTERFACE               
34 172.17.84.52/32    intra-area     20                     172.17.84.142   PTP-HES                 
35 172.17.84.140/30   intra-area     10                     0.0.0.0         PTP-HES

The loopback address is getting propagated, but nothing for the /29 on the LAN.

This is happening on 5.2/5.3/5.4. I don’t know about earlier versions, as I only deployed 5.0 and 5.1 in a very limited fashion for testing.

Any ideas and/or suggestions on how to resolve this problem? What additional information is needed to resolve this?

Thank you,

2

Same problem here… with versions 5.2 and 5.4.
I’m going to try with 5.1 now.

3

Hi,

ospf networks specifies where OSPF protocol will run, i.e. where OSPF looks for neighbors:

OSPF Interfaces

INTERFACE COST PRIORITY NETWORK-TYPE AUTHENTICATION AUTHENTICATION-KEY

0 DP lo0 10 1 broadcast none
1 D bridge1 10 1 broadcast none
2 D backhaul 10 1 broadcast none

>

to run OSPF on loopback is probably waste of resources, loopback is good for router ID - it never goes down, so it doesn't trigger OSPF alg.

To configure what routes are propagated to neighbors, use

```text
/routing ospf instance
distribute-default and/or redistribute-* parameters, specifically redistribute-connected

and to limit/filter out some routes in-filter and out-filter

BTW i am running V4.17 and V5.2

May be a bit of reading might help RouterOS - RouterOS - MikroTik Documentation and RouterOS - RouterOS - MikroTik Documentation

4

to run OSPF on loopback is probably waste of resources, loopback is good for router ID - it never goes down, so it doesn’t trigger OSPF alg.

To configure what routes are propagated to neighbors, use

/routing ospf instance
distribute-default and/or redistribute-* parameters, specifically redistribute-connected

>
> and to limit/filter out some routes > **in-filter** > and > **out-filter**
>
> BTW i am running V4.17 and V5.2
>
> May be a bit of reading might help > http://wiki.mikrotik.com/wiki/Manual:Routing/OSPF > and  > http://wiki.mikrotik.com/wiki/Manual:OSPF-examples

My original thought was to redistribute connected and static routes, with the internet gateway injecting a default route.  Reading here on the forum has a rep from MT (don't remember who) advising not to redistribute connected and static routes (can't seem to find the post), but instead to add a passive interface to the OSPF instance.  I'll have to see if I can find the post I remember reading and see if I can't figure out why MT advised against redistribution of connected and static routes.

The other thing that's getting me, is that the default route isn't always getting installed as expected.

```text
> /routing ospf lsa print where id=0.0.0.0
AREA                           TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER        AGE
external                       as-external  0.0.0.0        172.17.4.0          0x80000331        722

> /ip route pr where dst-address=0.0.0.0/0
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                          172.17.84.249             1

As you can see, the route is available, it’s just not getting installed. Here’s the next router in line:

> /routing ospf lsa print where id=0.0.0.0
AREA                           TYPE         ID             ORIGINATOR     SEQUENCE-NUMBER        AGE
external                       as-external  0.0.0.0        172.17.4.0          0x80000331        875

> /ip route print where dst-address=0.0.0.0/0
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                          172.17.86.25              1
 1  Do  0.0.0.0/0                          172.17.86.25            110

Default from OSPF is installed as expected.

Now, these 2 routers are the last in a series of 6 routers along this branch of my network. 2 of them are refusing to install the default route, even though it’s being advertised. It’s like they think they don’t need it or something. I’ve been scratching my head over this, and any help would be greatly appreciated.

5

Passive interfaces are fine. They do not necessarily cause more utilization, they just ensure the network is being put into the type 1 LSA the router generates anyway, and are included as a stub link. If you were redistributing connected instead you’d be generating an additional type 5 LSA for every interface, and each router - I assume they all have loopbacks - would suddenly turn into an ASBR.
It depends on where you use which technique. Technically when an external route is withdrawn or entered you don’t have to recompute all SPF since it’s just a leaf route, as long as the SPF route to the router-id that announced the external route is stable that is somewhat quicker than a router changing it’s type 1 LSA and a everyone recomputing the entire SPF tree. In this case it’s loopbacks, which is about as stable as it gets, so that doesn’t make a practical difference at all. When the loopback goes down the router is down, so a type 1 LSA is withdrawn and everyone goes recomputing, anyway.
Sometimes using external routes leads to suboptimal routing - when you have stub areas, which will only get default summaries for external routes by design. In this case there doesn’t appear to be any stub areas.

All in all it is a toss up. Given that it’s loopbacks I’d go with passive interfaces. They’re cleaner and always optimal for route calculations, and there’s no penalty in this design.

The quickest way to troubleshoot would probably be to disable the OSPF instance on a router that does not install the router, turn on OSPF logging (“/system logging add topic=ospf action=memory”) and turn the OSPF instance back on. There’ll be a lot of output, but it should include information on how the router processes LSAs.

6

Ok, I’ve gone through a few of my routers and altered the OSPF configuration. I set a static router-id and redistribute-connected=as-type-1.

I then upgraded the router from 5.3 to 5.4. When the router came back up, I saw the route advertisement for the loopback address, but not for the address on the ethernet, or the other networks behind it.

So, I telnet in, look at the routes, and they’re all there. Double check the upstream router, still nothing.

Disable/enable the OSPF instance (without any other config change), and all the routes magically appear.

MT, what do you need from me to help figure out what’s going on here?

Upstream router:

[admin@SYLV_PTP-BMRS_AP3] > /routing ospf export 
# jun/01/2011 11:04:37 by RouterOS 5.4
# software id = GSJM-IQHL
#
/routing ospf instance
set default disabled=no distribute-default=never in-filter=ospf-in \
    metric-bgp=20 metric-connected=20 metric-default=1 metric-other-ospf=auto \
    metric-rip=20 metric-static=20 name=default out-filter=ospf-out \
    redistribute-bgp=no redistribute-connected=as-type-1 \
    redistribute-other-ospf=no redistribute-rip=no redistribute-static=no \
    router-id=172.17.84.41
/routing ospf area
set backbone area-id=0.0.0.0 disabled=no instance=default name=backbone type=\
    default
/routing ospf network
add area=backbone disabled=no network=172.17.84.200/30
add area=backbone disabled=no network=172.17.87.192/27
add area=backbone disabled=no network=172.17.84.236/30

Other router:

[admin@BMRS_BH-SYLV] > /routing ospf export 
# jun/01/2011 11:06:37 by RouterOS 5.4
# software id = 7939-3QNG
#
/routing ospf instance
set default disabled=no distribute-default=never in-filter=ospf-in metric-bgp=\
    auto metric-connected=20 metric-default=1 metric-other-ospf=auto \
    metric-rip=20 metric-static=20 name=default out-filter=ospf-out \
    redistribute-bgp=no redistribute-connected=as-type-1 \
    redistribute-other-ospf=no redistribute-rip=no redistribute-static=no \
    router-id=172.17.84.42
/routing ospf area
set backbone area-id=0.0.0.0 disabled=no instance=default name=backbone type=\
    default
/routing ospf network
add area=backbone disabled=no network=172.17.87.96/28
add area=backbone disabled=no network=172.17.84.236/30

Routes on upstream router:

[admin@SYLV_PTP-BMRS_AP3] /routing ospf route> print where interface=PTP-BMRS 
 # DST-ADDRESS        STATE          COST                   GATEWAY         INTERFACE               
 0 172.17.84.42/32    ext-1          30                     172.17.84.238   PTP-BMRS                
 1 172.17.84.43/32    intra-area     30                     172.17.84.238   PTP-BMRS                
 2 172.17.84.44/32    intra-area     40                     172.17.84.238   PTP-BMRS                
 3 172.17.84.45/32    intra-area     30                     172.17.84.238   PTP-BMRS                
 4 172.17.84.46/32    intra-area     40                     172.17.84.238   PTP-BMRS                
 5 172.17.84.47/32    ext-1          60                     172.17.84.238   PTP-BMRS                
 6 172.17.84.236/30   intra-area     10                     0.0.0.0         PTP-BMRS                
 7 172.17.84.240/30   intra-area     30                     172.17.84.238   PTP-BMRS                
 8 172.17.84.244/30   intra-area     30                     172.17.84.238   PTP-BMRS                
 9 172.17.84.248/30   intra-area     40                     172.17.84.238   PTP-BMRS                
10 172.17.86.24/29    intra-area     50                     172.17.84.238   PTP-BMRS                
11 172.17.86.56/29    intra-area     40                     172.17.84.238   PTP-BMRS                
12 172.17.87.96/28    intra-area     20                     172.17.84.238   PTP-BMRS

This is what it should look like… before restarting the OSPF instance, I only had the first item (172.17.84.42) and item 6 (directly connected for the PTP).

Help me out here… I’m really not liking the idea that I might have to get up in the middle of the night just to restart OSPF on a router that didn’t come up properly after loosing connectivity for whatever reason.

Thanks,

7

Create the situation where the routes are missing. Create a supout.rif (which is a dump of all router state), and save it. Disable/enable OSPF and wait for everything to converge. Create another supout.rif. Email support@mikrotik.com (the official support, this is just a community forum and there’s no guarantee staff will ever read this thread) describing your problem, linking back to this thread, and attaching the two support files.
http://wiki.mikrotik.com/wiki/Manual:Support_Output_File

8

I have the same issue, the default route shows under the lsa table but it’s not getting installed? I’ve seen it happen on 2 routers now and I can’t seem to fix it. I’ve tried disabling ospf and reenabling but I can’t get it to show.

9

I am seeing signs in 5.4 that OSPF just crashes on a specific interface and won’t participate any longer. Are you running 5.x?

Sam

10

I am running 4.10