7.0beta6 OSPFv3 CPU hog

RouterOS RouterOS beta
1

Hi!
I decided to upgrade my RoSv7 testbed (OSPFv2, v3, BGP, MPLS) from 7.0beta5 to 7.0beta6, but I stopped at the first CHR instance.
When I enable OSPFv3 backbone area, routing eats up CPU and I can’t reach the CHR over network. I can only reach it with VNC.

OSPF config before upgrade:

/routing ospf instance
add name=ospfv2 router-id=10.0.10.11
add name=ospfv3 router-id=10.0.10.11 version=3
/routing ospf area
add instance=ospfv2 name=backbone4
add instance=ospfv3 name=backbone6
/routing ospf interface-template
add area=backbone4 interface=ether2
add area=backbone6 interface=ether2
add area=backbone4 interface=Loopback0 passive
add area=backbone6 interface=Loopback0 passive

OSPF config after upgrade:

/routing ospf instance
add name=ospfv2 router-id=10.0.10.11
add name=ospfv3 router-id=10.0.10.11 version=3
/routing ospf area
add instance=ospfv2 name=backbone4
add instance=ospfv3 name=backbone6
/routing ospf interface-template
add area=backbone4
add area=backbone6
add area=backbone4 passive
add area=backbone6 passive

/tool/profile shows routing usage is 100%, and I can’t export /routing config anymore. Furthermore I can’t disable OSPFv3 backbone area to fix the issue. I can do nothing with this CHR after upgrade but reboot/shutdown it.
When I disable OSPFv3 backbone area before upgrade, then CHR boots and CPU is under 1%, and then I fix the interface-template missing interface names, but after I enable OSPFv3 backbone area it hogs CPU again.

2

Yes, this is the same issue I reported here: http://forum.mikrotik.com/t/v7-1beta6-development-is-released/149195/1

3

Yeah, I see now. All of beta6 issues must be reported under that thread?
BTW removing networks=“” from interface-template does not fix for me as there was no networks before upgrade. I tried to disable all interface-templates but no success.

4

BTW, all of the below works:

  1. Specifying an interface and manually unsetting networks.
  2. Specifying networks and manually unsetting interfaces.
  3. Specifying both valid networks and interfaces (that fall into that network).

So I guess the problem with choosing if a template can be applied to an interface, is that the logic is AND not OR.
And the fact that default settings are “none” for both fields.

And to prove that:

  1. Setting interfaces to “all” and desired network works.
  2. Setting 0.0.0.0/0 and desired interfaces works too.

Upd.: and that actually makes sense - we already have an OR option (by creating different templates), so the only thing to be fixed is that not-set behaviour.
And ability to use interface lists would be nice too.

5

Because of OSPFv3 I prefer set interface and not networks. I unsetted networks field but it does not help. However OSPFv2 works as before.
If I disable all of interface-template CPU hog still occurs.

6

All the above works for v2, so I guess there is something else that stops v3 from working.

So I should probably duplicate that info into the beta6 thread, as it is not quite relevant here.