I'm still having too many BGP issues with v7...
For the time being, the setup where I absolutely need BGP is stuck on version 6.49.21.
However, as promised, I am testing version 7.23.5, and in a few days (provided there are no issues)
I'll start rolling it out to production.
I will then publish the results, as promised.
No, adding multi platform is an almost infinite step FORWARDS. What part of that did you miss?
This would probably generate a fork on topic... But:
What kind of issues?
Beyond:
Most of the time, without any specific reason (if I knew it, probably I would have fixed it by now)
it either starts updating all the routes again, but wipes everything out first...
or, for a brief moment, the link to the peer is completely lost, and it has to start all over again.
The two scenarios are similar, but only in the second case is communication with the peer interrupted for a few seconds.
These are machines that must remain in production, I can't go around running a lot of experiments...
EDIT:
If what you wrote actually happened, I didn't notice it, but I don't think so.
I never had any issues, other than the renegotiation ones I mentioned to you.
One issue I observe is that multiple peers connected to the same local IP tend to reconnect in parallel.
E.g. we have a L2TP/IPsec server where a couple of peers connect over 4G as a backup to the normal route via GRE/IPsec over DSL or fiber. All the peers get their own static IP via PPP secrets, but in the central router there is only one IP to which they all connect (put on a bridge with no ports).
When a client disconnects and re-connects (which happens because 4G sessions have a limited lifetime), we regularly, but not always, see that all these BGP sessions get disconnected and re-connected. Not a problem because these are backup paths, but still funny.
Also (as written), the number of prefixes indicated in the sessions window is often wrong (0) when multiple paths to the same peer exist (the scenario described above). I found by accident that the sure way to fix it is to open the IP->Routes window, let it show the routes and then refresh (F5) the sessions window... but sometimes it is also fixed by changing tab in the BGP window and going back to sessions. This prefixes number is clearly calculated from incorrect info which will be corrected when it needs to display the routes or maybe when it is updating them.
Other irritating bugs seem to have been fixed by now.
Upgraded to Winbox 4.3 because 7.25 required it (it would crash otherwise).
II'm troubleshooting MLAG/LAG issues, and when I make a change that temporarily disconnects me from the switch (and I want Safe Mode), I've noticed it randomly crashing (on MacOS).
This of course defeats the purpose of Safe Mode...
Why would that defeat the purpose of Safe Mode? Safe Mode is a property of RouterOS, not WinBox!
When you make a change that disconnects you, RouterOS is already rolling it back. That is a disadvantage of the Safe Mode implementation: you cannot make changes that will temporarily disconnect you, under Safe Mode. That has nothing to do with WinBox crashing or not.
There could be an alternate "Safe Mode" that works under these circumstances, e.g. one with a certain timeout that requires you to re-connect (and maybe issue some command) within that timeout to keep your Safe Mode session running, but it does not exist.
If I make a change that will temporarily drop the link at Layer 2 (bridge/VLAN changes), but it eventually comes back, then Safe Mode doesn't revert my changes.
If the app crashes, the TCP session on the router times out and it will roll the changes back.
There are text scaling and space scaling settings in 4.4rc1, They work pretty well.
(don't know if they exist in 4.3)
WinBox version 4.4 has been released: