Is it normal for OSPF to drop / reload when only adding a comment on the OSPF Interface?
RoS and Firmware 6.45.8 Long Term.
It’s an old bug
Indeed. It happens with most minor changes (adding a comment, changing the name, etc)
Wow, thx, did not expect that and dropped ± 1000 PPPoE connections earlier, ouch
Same thing with BGP peer I recently learned the hard way. Took about a minute for all the routes to come back.
The same with Netwatch comment, some PPP Tunels… it’s just better to set comment at first config and not change it 
Yes it is probably a thing in their configuration framework, where any change to an item will send it a message to update its state, even when the change has no effect on the state at all.
Of course it is difficult for us to see what changes exactly affect the state. One would think a comment certainly doesn’t, but what about a name, for example. An item name in many cases probably is as insignificant for state as a comment, as it is just kept alongside the lower-level name or ID used by the system. In other cases, maybe not.
Likely it is quite tricky to compile a table of changes that can be safely made without bringing the item down and back up, and MikroTik chose not to worry about it and just do it every time.
We can only hope that this is something that will be improved in v7.
On the other hand: relax. Competitor’s products do an entire REBOOT almost every time you make a minor change…
BTW OSPF in v7beta is already implemented, so if you have any complains or suggestions about v7 OSPF feel free to send them to support while it is in beta state.
I would think the whole “OSPF Drops when adding a comment” issue is not specific to OSPF at all, but only to the whole RouterOS environment.
The same thing happens when adding a comment to an interface, a BGP peer, an IP address, etc etc etc.
Is this something that has been fixed or is going to be fixed in v7?
No it is specific to protocols. For example BGP in v7 will have parameters that will not reset connection.
OSPF should also have parameters that will not reset adjacencies.
Will v7 also solve it for items outside routing protocols? Like interfaces, addresses, etc?
Changing comments on interface and address does not trigger any reconnects.
You know how it goes, if you have encountered a problem on specific interfaces then contact support with request to fix it.
Try ro use CLI, i found that using
set comment=“my comment” does not reset the session
I tested in CLI on GNS3 / CHR after the original incident, and did the same