RouterOS version 7.20.1 have been released in the "v7 stable" channel!
Before an upgrade:
Remember to make backup/export files before an upgrade and save them on another storage device;
Make sure the device will not lose power during upgrade process;
Device has enough free storage space for all RouterOS packages to be downloaded.
What's new in 7.20.1 (2025-Oct-10 11:49):
bgp - added output.network-blackhole setting;
bgp - do not auto-generate blackhole routes by default (introduced in v7.20);
bgp - fixed inactive flag in GUI after instance disable/enable;
console - fixed ".id" printing when using "group-by" (introduced in v7.20);
console - fixed relative path printing (introduced in v7.20);
ike1 - fixed an issue where policies could be released too early before re-acquisition;
ipv6,ra - fixed prefix unlinking from interface on configuration change and stop deprecating prefixes when the validity lifetime expires;
lte - fixed issue with firmware update for FG621-EA modem;
ppp - added support for KNOT BG77 modem firmware upgrade to version BG77LAR02A04_A0.301.A0.301;
qos-hw - always use qos-hw-offloading=yes for CRS812 device;
quickset - fixed issue where routes set by QuickSet did not appear in export;
route - fixed missing connected routes on setups with large amount of interfaces (introduced in v7.20);
route - improved stability;
routerboard - fixed non-running interfaces for CRS310-8G+2S+IN after booting to SwOS ("/system routerboard upgrade" required) (introduced in v7.20);
sfp - improved interface link speed configuration for CRS812;
snmp - fixed SNMP trap messages being corrupted when sent to multiple targets;
switch - fixed "failure: cpu flow control not supported" (introduced in v7.20);
system - improved system stability when using hardware-offloaded encryption on RB3011 and hAP ac2 (introduced in v7.20);
webfig - fixed form closing with saving when pressing Enter key (introduced in v7.20);
webfig - fixed interface settings and graphs (introduced in v7.20);
webfig - improved container form loading performance when router has a lot of files;
winbox - fixed WinBox 3 application failure when opening IPv6/Firewall/Connection entry (introduced in v7.20);
www - improved stability (CVE-2025-10948);
To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download
Everything went smoothly
I encountered an issue after the update (please post about the device, configuration, and unexpected symptoms)
I encountered an issue, but solved it (please post the solution)
I encountered an issue, but I am not sure if it is related to this release
0voters
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while a router is not working as suspected or after some problem has appeared on the device.
Please keep this forum topic strictly related to this particular RouterOS release.
I still see the auto generated blackhole routes after the update.
I see a new option in BGP→Extra→Network Blackhole which is not selected, but those are still created.
Running on a CHR (Openstack 64bit)
Is there anything special to do to avoid those blackhole routes ?
It seems that dynamic blackhole is still visible, but if 'bgp-extra-network blackhole' is not checked, the status will be 'not active'. However, if it's checked, the status will become 'active'.
In my case the blackhole route is inactive, as I have the static route being installed.
But now after 7.20, which installs these blackhole routes, I have all of them as inactive (they are not active as they have an higher metric anyway), but it’s still there.
For me these routes were in the “inactive” states already in v7.20, so this fix didn’t change anything for me. But they are still created.
Anyway if I disable my static route, then yes this fix can change the status of those blackhole routes.
But why should I get them in the first instance if I have a real static route going to the correct destination ?
They should not be there at all in my case, they don’t serve any purpose in my case.
your comparison is misleading. Mikrotik can and should publish RC every few days. That is fine. But you don't push minor releases like YOLO. And as Edpa already said, there was a month between rc1 and stable release.
It seems that Mikrotik's implementation of the 'bgp-extra-network-blackhole' checkbox is not to completely remove the dynamic blackhole from the routing table, but rather to mark the route as inactive. This is similar to filtered routes in v7, where the routes are not deleted from the routing table, but are instead marked as filtered with an 'F'
As I mentioned above, I'm not trying to say anything.
I'm just highlighting facts and information that are public and anyone can get.
Unfortunately, I don't have the time to do this...
But an interesting analysis would be to look at how many new features and major changes were made in a given release, and compare this with the time interval in business hours given for proper user analysis between one RC and another, or between an RC and the first stable release.
I think you have enough time to do this as you seem to have enough time to whine about every single thing that Mikrotik does. Its become so predictable that every time Mikrotik makes a post you need to find a flaw in it and post something negative or highlight the problem for days.
I think initally you meant well but its just become so toxic that alot of people dont take you seriously anymore.. well I dont know, i shouldn'treally state for others.
I see what you’re getting at, but we don’t have visibility into how many developers are actively working on a given release at any point in time. Some get pulled away to fix legacy issues, others may be on vacation, etc. Without knowing the actual number of devs dedicated to a specific release, tracking total hours isn’t a particularly meaningful metric.
But why should I get them in the first instance if I have a real static route going to the correct destination ?
They should not be there at all in my case, they don’t serve any purpose in my case.
Agreed. I don’t want any blackhole routes unless I explicitly set an option to have them. I don’t even want them as ‘inactive’ routes, this way they still spoil my routing table and ‘print where’ queries.
That’s the same for me.
Anyhow I see that this was also discussed in the beta 7.21 for the same reasons, so may be developers will look at it differently and step back a little bit on this decision, giving to this new option an action to avoid also installing the route as inactive in the routing table, like it was prior to 7.20.
Problem is that people with no problem do not read the forum. They with problem will read forum and vote negative. So you should take that in account when reading the voting data.