2.9.27 ospf crash

i just had a system running 2.9.26 stop responding via SNMP (everything else still worked) so I took the opportunity to upgrade it to 2.9.27 (it’s sort of my test box) so upon booting up with 2.9.27, OSPF came up, replicated all the routes, and then dropped them all. after a few seconds, all the routes came back up again, and then it dropped them again. it did this until I forced a downgrade to 2.9.12 where it booted back up and OSPF is again working fine. SNMP still isn’t working, I’ll post about that seperatly.

anyone had problems running OSPF on 2.9.27?

Is it a problem where you are replicating routes (default route?) and once that route takes effect it can’t get to its peer anymore so it drops the routes?

Sam

no… it’s peer’s are local to the same network segment as it is (the only way that OSPF works as far as I know), and it worked fine in 2.9.10-2.9.26, it just didn’t work in 2.9.27…

DELETED

I’m running two MT’s one with 2.9.26 and one with 2.9.27 Last week the one running 2.9.27 forgot it’s IP Bindings. I changed them from all servers to the exact name and they came back up. The first computer running 2.9.26 is a backup and it’s still running fine. I’m new so I thought it was just something I did wrong again.

I had another box running 2.9.27 drop all of it’s neighbors yesterday, I was disableing an IP address to drop the route, so that it would fail over to the alternate route (the main link started acting up and dropping out, wouldn’t normally do this durring the day otherwise), and the box dropped all routes and would not come back up until a reboot… this was a major router at one of my main tower sites, and it was at 6:00 in the afternoon… I was NOT happy.

Send support-output file to support@mikrotik.com if you experience problems.

It seems, that after a while, recent RouterOS versions will lose OSPF routing. This happens most often on RouterBOARDs, probably due to memory overflow.

My diagnosis of this problem is that the OSPF router process dies and nothing is setup to bring it back up. It will recover after tricking to to restart – by removing everything from /routing ospf network and adding it back again. Or, of rouse rebooting the router.

I believe it will not be that difficult to add an watcher process for this – it causing extreme problems in large RouterOS networks.

OSPF just drops off at random and won’t come back even after system reboot. Sometimes it comes back, sometimes it doesn’t.

Usually only thing I found that works is to either…

  1. Disable the port and re-enable it, most of the time OSPF comes right back in less than 5 seconds. (disabling the port between routers and then re-enable it) I think this works because it drops any OSPF links and starts fresh. If all OSPF links aren’t dropped, it will hang on various state changes.

  2. Disable the OSPF Network, wait for a few seconds and then re-enable it to restart the link process.

  3. Which doesn’t always work, reboot the router. Most of the time this is for some reason the least effective method of the three.

Any solution from MT for this heavy problem ?

Any solution from MT for this heavy problem ?

Has this been fixed on 2.9.29?

for sure it is present on 2.9.6

on saturday I will launch version 2.9.27…

We have a group of 4 MT OS running 2.9.29 with test-routing.

We are having a lot of problems with them lossing routes for about a week now. We have sent a support file to MikroTik but they belive everything works.

They will be fine for hrs then the main backbone is unable to communicate with the gateway.

Is anyone else having these issues?

can you access your gateway from the router that is advertising the default route?