Hi Mikrotik Team,
Today i had another blackout, and needed couple of long minutes to work it out what exactly happened.
However, this time I cannot 100% blame Mikrotk, anyway something might be done *better* so other might have their ass saved in future.

So, I have two BGP servers:
1) BGP1
2) BGP2

Both have 2 bgp upstreams connected on different IP class /30 connected(let say A.A.A.A for BGP1 and B.B.B.B for BGP2)

I had nice solution of auto-takeover of traffic by BGP2 server, which worked very well during our tests. Take over time was roughly 300ms and not even noticed by customers.
So today I had hardware damage of BGP1 server. BGP2 server took over and became master as expected.
BGP sessions was up, however no traffic was forwarded by this server.
I tried to ping "8.8.8.8" and various other hosts - and I had "no route to host". I have checked the ip -> routes and It had fetched ~900k routes from both upstreams, anyway ALL ROUTES from both upstreams WAS blue color (fetched, but inactive). Usually one route is blue (inactive, but standby -- fetched) and second black - active if BGP engine choose shortest or depends of filters. Here both was standby - inavctive.

So the reason was most likely set "pref-src" (in IN routing filters) of master BGP server IP (A.A.A.A, instead of B.B.B.B) and BGP engine dropped that route - because router didn't had A.A.A.A address itself, and that was unknown address.
I have synced conf between those two BGP servers, and probably forgot to change pref-src to B.B.B.B at some point, and that's the reason.

The other thing - I didn't had more time to check why routes are inactive, so I decided to restore last-known working ESXi snapshot of MASTER server. So I've restored CHR image and lost my licence. So server launched up, received BGP prefixes, but then when traffic started to flow it was unresponsive and very slow.
In the end - after restoring backup image, it lost licence and went into DEMO mode (1mbit interface TX cap). It took another minutes to work it out, and unresposinve serve also took another minutes to fetch demo licence from server.

So Dear Mikrotik Team, because I already know of those problems, can you consider implementing following fixes/changes, so maybe others will save their precious time during blackout:

1) Can you please mark BGP peer as "I" invalid and RED color, and place some message in log like "unknown pref-src for this peer-filter!!" ? I had no any message in log, nothing, just BGP engine silently dropped that routes with invalid pref-src ... Or change behaviour -- if pref-src is unknown to router, replace it with default-router-ip and warn in log
2) Can you please add some popup warning in winbox, if CHR licence will be reset to demo/trial/free? I had completly no idea it resets to free mode. Shouldn't it after moving vmdk stay in 2months trial, instead of free? 2 months is enough to transfer licences in mikrotik accounts. Just placing some big notice like "!!! DEMO MODE - 57 days left !!!" OR "!!! FREE MODE !!!" in the top of winbox window, would be enough i think!! Or just popup after each connect (like this popups when configuring new devices or so... - so anyone will be 100% confident about device lost licence, went to demo mode)

I think reworking following might be cool idea ...

Also, Is anyone interested in automatic conf-sync tool between servers, which will automatically update all stuff like IP addresses, pref-srcs and other stuffs ???

BR

While not addressing your other points, with regards to #1, I think you misunderstand BGP a bit...

Nothing that you do with routes received via a BGP session can or should invalidate the session itself. The BGP session is established and perfectly valid, and is exchanging NLRI without issue, even if that NLRI does not result in valid usable routes (in your case, due to you assigning an invalid pref-src via a filter; there are many other ways to get invalid routes). Also, nothing is being 'silently dropped', the routes are being installed exactly as you instructed, they just aren't being used, since they don't make useful sense. There is no reason to mark the session as 'i'/invalid/red, just because you aren't using the results in your desired way.

In analogy, would it be fair to blame the postal service for you missing an important document, due to you burning all your mail before looking at it?

In fact, there can be good reasons to set a pref-src that doesn't exist on the router...

Maybe you only want those routes to become active conditionally, perhaps when VRRP (or a script/whatever) causes the IP specified to become active/valid.

Or maybe, you just want the routes to exist in the routing table, so they can be searchable via script (for firewalling or whatever); but you don't want them to actually be used for routing. There are better ways to do that, but why dictate a particular use case?

Sanity checking is a good thing, to be sure; but in the case of BGP filters, it's better implemented in an external provisioning system, where you can codify your use-case/business-logic. At the raw config level, it's better just to make sure the config is syntactically correct, and not try to validate the specific use there.

In analogy, would it make sense for a C++ compiler to fail out, if it were to somehow detect that you are trying to build a application you aren't actually going to use?

I don't mean to be harsh, but BGP is a powerful and flexible tool, and not all uses conform to your particular case (many do, probably most even, but not all). It's on you, and/or the systems you use/build, to make sure you are using it in a way that is correct for you.

--Eric