So ever since I upgraded some of my RB600’s from 3.x to 4.x I’ve been having some OSPF issues. Other than the upgrade nothing on the network has changed. Randomly one of my devices will drop a route and it doesn’t come back until I disable the local interface. It only happens on the 4.5 and 4.6 devices. Anyone else having this problem or any one know what I can do to prevent this?
Practically the same. Changed from 3.30 to 4.5. I have different RB’s in network from RB 112 to RB 1000. Some times routes disappear. In “ospf,debug” log there are a lot of route recalculations. Nothing helped. Came back to 3.30.
The same is with 4.6. (And there is nothing about ospf in the Changelog)
I don’t have the option of downgrading back to v3.x. I’ve replaced one of my interfaces with an N card. Anything prior to v4 doesn’t support N and will not even recognize the interface. Does anyone have a solution for this?
This is really plagueing my network. If someone could please help as soon as possible! I’ve even put in static routes and it bugs out and still wont work.
have you set ‘NBMA’ mode on wireless OSPF links?
Yes. sometimes it helps for sometime:)) But there were no problems with this links in 3.30. What changed in 4.x ?
Chupaka,
Thanks for the reply, I am a collegue of O1DMBFan. The major concern here is that nothing changed except for the OS version. Something has changed between 3.3 and 4.5 that seriously affects OSPF routes. We will just randomly have a router drop an ospf route, it can take upto 10-15mins for the route to come back. No rhyme or reason.
What could have changed between version that is affecting this?
Thanks!
you really need to make a supout file with the routes and without the routes and then submit it to Mikrotik support. They are the only ones that can fix the ‘bug’. I have a similiar problem with RIP, related to RIP packets > 512 bytes udp, I wonder if thats the same issue. are the routes that are missing the routes at the end of the table?
support sucks.. i
've got similar problems with ospf.. and some with ospf vlinks.. no answer yet for three weeks :-/ with 3.30 no problems (ok sometimes 100% cpu bug).. with 4.6 ospf route drops and vlinks creating invalid routes without a gateway. shouldn’t be too hard to reproduce and to fix.
Hey, forumers. I have noticed a clock bug on one of 4.6 routers. It is hard to reproduce, but look at system->resources → the UPTIME field. It counts by 10-11 seconds. By a week after upgrade I have uptime: 18w2d3h13m13s. 
In logs you can see siomething like this
(IP’s of neighbours is my private information):
07:33:03 route,ospf,info OSPFv2 neighbor : state change from Full to Down
07:34:40 route,ospf,info OSPFv2 neighbor : state change from Full to Down
07:36:18 route,ospf,info OSPFv2 neighbor : state change from Full to Down
07:38:00 route,ospf,info OSPFv2 neighbor : state change from Full to Down
07:39:42 route,ospf,info OSPFv2 neighbor : state change from Full to Down
07:41:25 route,ospf,info OSPFv2 neighbor : state change from Full to Down
In 3.30 it counts as usual - second by second. Of course, it can cause OSPF problems (intervals between Hello-packets, router deead interval in 4 seconds(4 counts by 10)).
Please, look at your routers, may be the problem is the same?
PS: I have sent the supout.rif. Waiting for answer.
Are you using x86 boards?
I am also having this issue. I changed a 500 series router out at one of our high traffic locations with a 433ah for more power. I thought I would be smart and put 4.6 on there and it randomly drops the routing. A reboot seems to be the only fix to the problem. Seems this is a carryover from 4.5. Wondering if anyone has any ideas.
found several of these in the ajacent neighbors log:
mar/18 23:55:12 route,ospf,info Database Description packet has init bit set in middle of an exchange
mar/22 20:23:27 route,ospf,info OSPF neighbor : state change from Full to Down
mar/22 22:31:55 route,ospf,info OSPF neighbor : state change from Full to Down
mar/23 18:41:51 route,ospf,info OSPF neighbor : state change from Full to Down
mar/23 20:50:18 route,ospf,info OSPF neighbor : state change from Full to Down
mar/23 22:05:03 route,ospf,info OSPF neighbor : state change from Full to Down
mar/23 22:14:29 route,ospf,info OSPF neighbor : state change from Full to Init
mar/23 22:58:38 route,ospf,info OSPF neighbor : state change from Full to Down
mar/24 08:54:24 route,ospf,info OSPF neighbor : state change from Full to Down
mar/24 10:46:49 route,ospf,info OSPF neighbor : state change from Full to Down
mar/24 13:02:49 route,ospf,info OSPF neighbor : state change from Full to Init
mar/24 15:01:25 route,ospf,info OSPF neighbor : state change from Full to Down
mar/24 15:25:23 route,ospf,info OSPF neighbor : state change from Full to Init
mar/24 17:57:52 route,ospf,info OSPF neighbor : state change from Full to Init
mar/24 17:59:50 route,ospf,info OSPF neighbor : state change from Full to Init
mar/24 20:35:52 route,ospf,info Database Description packet has different master status flag
mar/24 20:35:52 route,ospf,info new master flag=false
hope the info helps
We use 3.30 with routing-test on all OSPF-Routers.
We dont see this problems. As routing-test should be
the same OSPF Implementation as 4.x this is a hint
that you might be right that this is a timing problem
of the 4.x core.
v4 uses new high precision PIT timer. Some of older hardware doesn’t work correctly with this timer. Solution is to look for newest m/b BIOS and upgrade. If BIOS upgrade didn’t help, then change hardware to newer.
Is this a problem on x86 Hardware only or also on older Routerboards?
Rb1xx,5xx ok?
This problem is x86 only.
New bios - v 1.3.8 is the last as I know for RB 230 (x86).
Remove/change 36 devices in network because of new version of RouterOS?
The most interesting fact that Clocks goes crazy with enabling nstream(as support@mikrotik said), but I have a device RB 230, which works perfect with 4.6(and 3.30) and Nstream enabled. I have sent them a supout.rif from that RB 230 and now is waiting for support’s new reply. I really want to find out - what is wrong in 4.x .
So is there a clock problem with RB230 or not? You say that you have a problem, and then you say that RB230 doesn’t have a problem 
which is it ?
I have 2 devices - both RB 230. One of them has this problem in 4.6 adn doesn’t in 3.30. The other one doesn’t have any problems in 4.6.
what framer policy do you have on both, and is one client and other AP, or are they both similar configurations?