[admmikrotik@router70a] > /system/resource/print
uptime: 3h12m33s
version: 7.20.8 (long-term)
build-time: 2026-01-30 09:17:54
factory-software: 7.4.1
free-memory: 849.2MiB
total-memory: 1024.0MiB
cpu: ARM64
cpu-count: 4
cpu-frequency: 1400MHz
cpu-load: 0%
free-hdd-space: 461.7MiB
total-hdd-space: 512.0MiB
write-sect-since-reboot: 3295
write-sect-total: 540762
bad-blocks: 0%
architecture-name: arm64
board-name: RB5009UG+S+
platform: MikroTik
[admmikrotik@router70a] >
After upgrading from 6.49.19 (long-term) to 7.20.8 on a CCR1036, the entire BGP configuration is gone. No instances, no templates, no connections, nothing.
Probably not really fixed...
3 Likes
The issue with BGP-VPNv4 redistributing "other BGP" multihop routes to other PE via RR, ticket number [SUP-207808] is still occurring in this LONGTERM version 7.20.8
1 Like
You do know that 7.20.8 is not a tiny update vs 6.49.19, right? https://mikrotik.com/download/changelogs?versionFilter=6.49.19-7.20.8&channelFilter=
Did you check out this article before an upgrade?
Why? Configuration conversion from v6 to v7 has nothing to do with this.
Configuration loss which was resolved could appear on router with huge configuration (combined with graphing history) which could grow over the time and new configuration could not be added/stored any more. You might reboot router and think that configuration was lost but it actually was never properly saved.
1 Like
Another reboot of LtAP mini, back to 21MiB FreeMem 
The article states “All known configurations will upgrade from 6.x to 7.x successfully.” That’s clearly not the case for the configuration on this CCR1036, and I’d say that advises investigation.
Had to change script policy from “do not require permissions” to now “read” from 7.20.7 to 7.20.8 for snmp-activated scripts again.
(please do not change this again it’s cumbersome to rework all configs)
We would like to sincerely thank you for reducing the maximum connection tracking table size starting from RouterOS 7.20.2.
The change:
firewall – reduce maximum connection tracking entry count
is especially appreciated on NAT edge routers serving thousands of customers.
Nothing improves resilience during DDoS attacks quite like cutting the available connection tracking capacity to 1,048,576 entries — regardless of installed RAM or real-world workload.
Previously, operators could scale conntrack according to hardware capacity and traffic profile. Now we enjoy the added excitement of watching the table approach 100% during peak hours, knowing that any moderate flood might push the router into connection drops for all customers — safely protected from the risk of using too much memory.
It is reassuring to know that modern x86 servers with tens of gigabytes of RAM are now protected from the dangerous possibility of actually using it.
While we understand the intention to prevent OOM crashes, this hard limitation creates a new operational risk for ISP NAT deployments under real traffic conditions.
We hope future releases may consider:
-
Restoring configurable max-entries limits
-
Or at least providing adaptive scaling based on available RAM
-
Or documenting the architectural reasoning more transparently
Until then, some of us may temporarily enjoy revisiting 7.19.x.
Thank you for the safety.
8 Likes
I just discovered ipv6 not working. Need to disable/enable address to get it working partially.
On multiple segments /64 somes ip are stale and some failed.
I use dual adresses, ula and gua via prefix delegation. Same behavior for both.
I'm asking why since around 10/15 days I've less ipv6 conns. Now I know.
Downgrade to 7.19.6 and quickly get ipv6 conns at the normal level thank grafana dashboards... And all os working, reachable like before this devil release 7.20x.
Great debugging!
After lot of try between 7.19.6 and 7.20.8 : the problem about ipv6 connection was resolved by disabled igmp-snooping on bridge.
Will try on 7.21.2 soon.
Still seems like a bug, right?
Or not, support say me this :
Yes, IGMP snooping can restrict IPv6 multicast, see the docs:
https://help.mikrotik.com/docs/spaces/ROS/pages/59277403/Bridge+IGMP+MLD+snooping
There are few improvements we are planning for IGMP snooping to minimize the IPv6 issues, but the real question is, do you require IGMP snooping on the bridge? Does your network have some kind of multicast application (e.g. multicast video streaming) that should be forwarded only to certain clients? Do not blindly enable all the features without understanding the use case.
1 Like
In my experience, the combination IGMP Snooping + Hardware Offload bridge (RB5009) + IPv6 + VLANs have never worked correctly, and I've tried all kind of suggestions in the past few years and nothing worked.
On my devices, from the combination above, IGMP Snooping must be turned off, and the other 3 can work beautifully together.
IGMP Snooping was needed because of IPTV, in my case, that could be resolved by using UDPXY running in a container, on a separate bridge with only the VETH.
There are few limitations/issues with IGMP snooping and IPv6:
- there is no option to disable it for IPv6.
- there is no per-VLAN IGMP/MLD querier, that can keep the MDB table up to date. The bridge "multicast-querier=yes" is able to generate only untagged queries. You can work around by creating IGMP querier per-VLAN using igmp-proxy or pim interfaces, but nothing for MLD.
And this is unrelated to v7.20.8.
2 Likes
Hi,
My CCR2004-1G-12S+2XS always have fans at full speed. Maybe is using SPF temp for calculate speed?
Is this normal?
Running ROS 7.20.8
Regards.
