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?

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.

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?

http://wiki.mikrotik.com/wiki/OSPF-examples

have you set 'NBMA' mode on wireless OSPF links?

http://wiki.mikrotik.com/wiki/OSPF-examples

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 <IP>: state change from Full to Down
07:34:40 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:36:18 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:38:00 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:39:42 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:41:25 route,ospf,info OSPFv2 neighbor <IP>: 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.

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.

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 <ip>: state change from Full to Down
mar/22 22:31:55 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/23 18:41:51 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/23 20:50:18 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/23 22:05:03 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/23 22:14:29 route,ospf,info OSPF neighbor <ip>: state change from Full to Init
mar/23 22:58:38 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/24 08:54:24 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/24 10:46:49 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/24 13:02:49 route,ospf,info OSPF neighbor <ip>: state change from Full to Init
mar/24 15:01:25 route,ospf,info OSPF neighbor <ip>: state change from Full to Down
mar/24 15:25:23 route,ospf,info OSPF neighbor <ip>: state change from Full to Init
mar/24 17:57:52 route,ospf,info OSPF neighbor <ip>: state change from Full to Init
mar/24 17:59:50 route,ospf,info OSPF neighbor <ip>: 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

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 <IP>: state change from Full to Down
07:34:40 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:36:18 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:38:00 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:39:42 route,ospf,info OSPFv2 neighbor <IP>: state change from Full to Down
07:41:25 route,ospf,info OSPFv2 neighbor <IP>: 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.

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.

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.

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.

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 .

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.

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 ?

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.

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?

what framer policy do you have on both, and is one client and other AP, or are they both similar configurations?

With problems - AP(framer policy - best fit), without problems - station(Also -best fit). Both running nstream. I'll try to find out more devices, but I can't to upgrade and downgrade them during a week. Only at weekend's.

I have tried the 4.6 on 1 RB433ah and 2 different 532 boards. Updated bios and the whole shot. I downgraded the 532's to 3.30 and left the 433ah running 4.6. Same result. I have now downgraded the 433ah and all is well. I may add that all 3 are acting only as routers and do not have any wireless cards in them. Also one of the 532 have a daughterboard and one does not. The only thing that changed when it started dropping routes was the firmware on them.

With problems - AP(framer policy - best fit), without problems - station(Also -best fit). Both running nstream.

I have replaced AP RB 230 with RB 411AH. And RB 230 was reconfigured as client device. It is also uses nstream and connected to the the RB 411AH. It works. Now problems with OSPF - what changed? wireless mode?

I may add that all 3 are acting only as routers and do not have any wireless cards in them.

Hazyd has the same problem on RB's without wireless cards. I don't know what to do next?

I had the same issues with OSPF and v4, but it was caused by the instability of the wireless links and nstreme, disabling nstreme fixed all problems. If you use nstreme, disable it.

RoS 4.11 is out, but still no results...
UPD: bug was fixed in 5.0beta
Why can't DEV team backport this fixes to 4.11?

I tried to fix this issue. I gave up after a year. I worked with mikrotik support. I did all the supouts and they couldnt tell me anything. So OSPF is 100% gone. Back to the good old static routing. Works a lot better. My phone stopped ringing. Working on another solution for redundancy.

Im not seeing this problem on my setup with 30-50 routers and 100 or so routes in a OSPF single backbone. Maybe if we can pinpoint whats different we can get them to find it and fix it.

I have about 200 mikrotik routers. Does this help. Ask questions if you want. I am learning more about BGP. It handles 200+ routes. Its a better solution. Want to work with me on BGP?

MT have said that routing crash's due to interface changes crashing OSPF and that a fix was in the pipeline for 4.x and 5.x

I used 4.11 and it still had the issue. Have you tried the loopback setup for ospf so ospf doesn't depend on the actual interface? I am still trying to find out why ospf still crashes. In my setup I have just a rb1000 and a rb433ah at the moment and it still crashes. The load is high which is a good test. I am trying a bunch of different settings to try to resolve the issue.

OSPF may crash if external routes with forwarding-address is distributed, this is a known problem that we are fixing right now.

OSPF may crash if external routes with forwarding-address is distributed, this is a known problem that we are fixing right now.

I am going to research forwarding-address in the manual to understand what exactly you mean. Do you have a short explanation while I do that?

The manual doesnt have anything about forward-address however. I found this.

" The Forwarding Address

If the network between the NSSA AS boundary router and the adjacent
AS is advertised into OSPF as an internal OSPF route, the forwarding
address should be the next hop address but if the intervening network
is not advertised into OSPF as an internal OSPF route, the forwarding
address should be any one of the router's active OSPF interface
addresses.
"

Is this what your talking about?

I also found this on google.

"Forwarding Address— Indicates the address to which data traffic to the advertised network should be forwarded. If the value is set to 0.0.0.0, this means that the traffic should be forwarded to the ASBR. In some situations, the forwarding address will be nonzero, to avoid suboptimal routing. The following list describes events that will produce a nonzero forwarding address:

- OSPF is enabled on the ASBR's next-hop interface.

- The ASBR's next-hop interface is nonpassive to OSPF.

- The ASBR's next-hop interface network type is not point-to-point or point-to-multipoint.

- The ASBR's next-hop interface address falls into the OSPF network range.
"

Is routeros setting the forwarding address to 0.0.0.0 or a non zero bit? Is there a work around to stop the crashing?

You can see in "/routing ospf lsa" what forwarding address is set

Thank you

I am getting this LSA. So what you are saying is mikrotik is always sending a 0.0.0.0 when its suppose to be sending the ip address of its next hop?

"
type=as-external
netmask=255.255.255.252
forwarding-address=0.0.0.0
metric=20
route-tag=0x0
type1
"

http://wiki.mikrotik.com/wiki/Manual:OS ... ng_Address

Hope it explains when forwarding address is set to other value than 0.0.0.0

ok, so does OSPF lockup when a forwarding address is 0.0.0.0 or when its set to the next hop? Another words if I set the next hop router. Will it fix the lockup problem. Or are you saying we should wait until you guys fix routeros version of ospf?

if forwarding-address is 0.0.0.0 for all LSAs then you should be fine. If not then most likely you have some other problem that we haven' t found yet.

All the forwarding addresses are 0.0.0.0. Am I waiting on Mikrotik to fix the crash issue?

we have already some fixes ready. If you want to see if it fixed your problem, send a mail to support and ask for pre-release version

I will, thank you.