I have an issue where OSPF randomly started bouncing on a fiber link.

It has been up and running for over 2 years when all of a sudden we started getting Hello timer mismatches.

I triple checked the settings and logs and nothing had changed.

To fix this problem I added encryption to the link turned the hello packet to 10s, rebooted and upgraded all routers to 6.34.1. It seemed to elevate the problem.

Until this morning when I received "Database description packet has different master status flag OSPF issue" and OSPF dropped and routed traffic stopped. But pings across the circuit have not dropped.

I found the post below but it seems outdated and blames the link.
http://forum.mikrotik.com/viewtopic.php?f=14&t=34170

Anyone have any ideas?

Hi, Did you ever resolve this ? IF so what was the resolution / issue.

thanks

I have started seeing this since an upgrade to 6.35.2... on a wireless link where we have had some link stability issues.

Was about to start rolling out some upgrades after a couple of watchdog reboots over the past few days, but don't want to end up with broken OSPF across a bunch of remote sites.

Have OSPF deployed on several networks running 6.35.2, without any issues so far.

What devices are running the wireless link?

Ubiquity AirFiber A5X... and interestingly it is only on those links where we have seen the database errors.

Previously we have used broadcast network types and dynamic discovery of interfaces and neighbours without issue across Ubiquiti and other licensed link devices without issue.

These are the only ones reporting the database errors.

Having the exact same issue here. Tried 6.34.2 and 6.35.2 using both NBMA and Broadcast type of networks still the issue prevails.

In this particular case the issue is between 2 routers connected using a L2VPN via a transport provider.

Going to try as well adding authentication to the link to see if that helps.

Going to try as well adding authentication to the link to see if that helps.

Not help at all.
I think one of your mikrotik is CCR or AHAx2 ?

No problem with either CCR, RB1100AHx2, 750 flavours, 2011...

Double check L3 (nat, firewalling) and L2 for issues.

Missconfiguration of OSPF?

One of the routers is a RB951 the other one is a CRS can't remember the model atm. No firewall rules whatsoever are being used, OSPF configuration is fine, this is a small network with less than 8 routers all of them working fine. Just this pair link isn't working. Both devices are using the latest bug fix image.

Both routers involved have connections to other routers and no issues either with the adjacency, tested MTU, it's as intended passing 1500 bytes packets, so no problems there whatsoever either.

In any case I tend to blame a link fault but so far we haven't been able to find an issue with it. The link is idle when we do the test, same issue doesn't matter if hellos are multicast o unicast.

Check the MTU on both ends of the link - all the parameters must match exactly or an adjacency won't form. You could try debug logging for OSPF to see why it's getting mad.

Check the MTU on both ends of the link - all the parameters must match exactly or an adjacency won't form. You could try debug logging for OSPF to see why it's getting mad.

It would keep the adjacency on ex-start but on this case it forms (goes to full) and flaps randomly after x amount of time. May be one minute may be be 3 minutes but at the end it flaps, in any case the ospf configuration is right no issues there, no issues with the MTU capabilities of the transport. I've yet to try with some other devices to validate whether it's the link (in my mind this is the only logical explanation other than a weird bug) , OP had the same issue with a different scenario though same issue.

Shaoranch, are those PTPs done with nanos? fw version?

If it's flapping after establishing, I've seen similar behavior over UBNT P2P links (AirMax, not AirFiber), and it pretty much appeared to be related to packet loss due to either congestion spikes, or modulation changes, etc. (and this was using Cisco-to-Cisco OSPF, not Mikrotik)

Have you tried setting DSCP to EF on OSPF packets so that the UBNT gear knows that these are high-priority packets?

One of the routers is a RB951 the other one is a CRS can't remember the model atm. No firewall rules whatsoever are being used, OSPF configuration is fine, this is a small network with less than 8 routers all of them working fine. Just this pair link isn't working. Both devices are using the latest bug fix image.

Show OSPF config from routers ?

In any case I tend to blame a link fault but so far we haven't been able to find an issue with it. The link is idle when we do the test, same issue doesn't matter if hellos are multicast o unicast.

No, link failures produce other messages - "OSPFv2 neighbor x.x.x.x: state change from (Init|Full) to Down" should read as "dead timer expired" (no OSPF incoming packets in 40 seconds).

"packet has different master status flag" - issue with election master/slave.

If there are only two routers on this link, have you tried setting the interface type as point-to-point?

If there are only two routers on this link, have you tried setting the interface type as point-to-point?

And how this help? Only remove DR/BDR selection from algorithm?

I just had this exact same issue today with a client network on bugfix 6.34.6 and I resolved it by setting ospf interface priority back to the default of 1. It had been set to different integer values on several routers to force a DR Master.

Have you set an interface priority on any of the routers?

First off, thanks everyone for sharing your insights, I'll answer some of your questions but the issue seems to have been solved (adjancency's been up the past 3 days), it was as I suspected an issue with the transit network, the provider didn't exactly tell me what they did, but they called me telling they discovered a fault and fixed it (didn't touch any of our routers), everything's been fine so far.

I just had this exact same issue today with a client network on bugfix 6.34.6 and I resolved it by setting ospf interface priority back to the default of 1. It had been set to different integer values on several routers to force a DR Master.

Have you set an interface priority on any of the routers?

Haven't changed the priority, will take this into account 

If there are only two routers on this link, have you tried setting the interface type as point-to-point?

Tried Broadcast, NBMA and PTP as well, same behavior

Shaoranch, are those PTPs done with nanos? fw version?

On this particular case, no wireless is involved, the transit provider reach us via FO then their CPEs provide us with copper interface, OP is the one that had the same issues with a wireless link I wrote here because I was experiencing the same problems

One of the routers is a RB951 the other one is a CRS can't remember the model atm. No firewall rules whatsoever are being used, OSPF configuration is fine, this is a small network with less than 8 routers all of them working fine. Just this pair link isn't working. Both devices are using the latest bug fix image.

Show OSPF config from routers ?

In any case I tend to blame a link fault but so far we haven't been able to find an issue with it. The link is idle when we do the test, same issue doesn't matter if hellos are multicast o unicast.

No, link failures produce other messages - "OSPFv2 neighbor x.x.x.x: state change from (Init|Full) to Down" should read as "dead timer expired" (no OSPF incoming packets in 40 seconds).

"packet has different master status flag" - issue with election master/slave.

Router configuration is fine, no issues there, it's pretty much a basic configuration on this particular point, the adjyacency forms both randomly happens this, I do think that it should show a different message just like you, I checked the system a few days ago and noticed that randomly I could also see LSA retransmisions (around 3 - 5, not always like 1 each hour) this is why I was blaming the link. 

I've experienced this same behaviour for many years and the common denominator has always been Mikrotik. I used to think this was a Ubiquiti problem but i have experienced this using the following brands of wireless equipment

-Ubiquiti (various types)
-Ligowave (PTP-PRO)
-Cambium ( Canopy PTP450i, Force 110PTP)

i've also experiment with different MTU's, different priorities for NBMA Neighbors, tried point to point, broadcast, nbma etc

I've hunted through the forums for a long time without conclusive evidence what causes this. Strangely it seems some people are affected and others not.

Are you redistributing the default route via OSPF, by the chance ?

Anyway, across the years, we've seen a lot of weird behaviors in the current OSPF implementation, for example:

- Sometimes adjacency gets formed, ospf database appears to be OK, but FIB doesn't receive all routes. Disabling and enabling ospf instance fixes the problem.
- Some network topologies, when you have redundant paths, can trigger the crash of the OSPF process (sometimes it just looses adjacency and restarts itself, sometimes CPU gets stuck to 100%)

Last but not least, the issue you're reporting here.

We're running a quite dense network now (200 routers in backbone area, 700+ total routes), but we were experiencing the very same problems when the size was more than reasonable (40 routers in backbone, 300 routes in the IGP). I wasn't able to completely fix those problems ever (I tried segmenting the network in different areas, reviewed all router-id on every piece of equipment looking for dups)...

We strongly hope that v7 comes with a more robust OSPF implementation (and nv2 GPS sync, multithreaded BGP ... )

S.

I think I've fixed this, I was doing my head in, I was using the loopback IP as the routerID, once I set it back to 0.0.0.0 so that OSPF dynamically chooses the lowest IP as the RID, my routing tables updated and I'm running smooth. So far so good. Hope this helps.

Kind regards,
Cody Volckmar.