Not too fast, rc2 still have bugs with cpu 100%
thx
CPU usage means you are using the device for something. If you still see 100% CPU with no configuration and cables unplugged, email support with your RIF file
SUP-150642 not update since i openedit on April 20:
"we have issue with bgp (that were fixed months ago) after one hour of operation:
- one cpu core goes 100%
- slow advertisment of the prefixes
- HoldTimer Expired for one ipv6 bgp session (no issue with the Cogent remote peer).
attached rtrace during it and supout generated immediately after holdtimer expired"
Would be nice and useful IMHO if Mikrotik makes some kind of searchable bug trucking site as most Linux distros do, that would allow users to check if issue they are experiencing has already been reported and accepted for a fix (hopefully avoiding many duplicate reports that can bog down people in support), and also check if some issue has been resolved and if there is a workaround…
Now we have to waste too much time searching the forum for articles that are often unmoderated and provide little to not usable and accurate answers…
“My CPU usage is high” could honestly be anything.
I highly agree with bratislav about open tracking system and want it day one and understand that some sensitive information needed for further investigation thus open tracking can not an ideal in this situation but at least share us confirmed bugs with in versions so users can avoid jumping and bricking live systems.
The problem of course is that RouterOS (and the devices it is running on) is so versatile that there always are many bugs, but most users will not see them. E.g. the “BGP causes 100% CPU” bug is something I have never seen, but I do not use BGP for an internet routing table, but rather for automatic failover in a private network with many VPN tunnels. So my routing tables are not in the hundreds of thousands of routers, but more like 20 or 1000 routes (depending on the network).
However, I see another problem that nobody else seems to report: one BGP session going down and taking others with it. Those then need to be re-established. And of course that is the time at which they are most needed.
I posted a topic about it http://forum.mikrotik.com/t/bgp-sessions-close-when-another-session-to-the-same-ip-closes/175478/1 but nobody is chiming in.
So apparently I am the only one facing this, and it is not very likely that MikroTik would postpone a release to fix this.
Similarly, they will probably not postpone for a “100% CPU” problem that most people do not see.
That is correct of course, but high CPU usage caused by BGP under certain circumstances as reported by rpingar is a bit more to the point 
it is looong time and no new beta…what is happening?
Is important to say that Beta is different from RC.
Now on 7.15rc2. Two possible paths here:
- 7.15 release as stable.
- 7.15rc3 expecting reports of corrections or other possible undesired behaviors.
A long time in the sabe RC can mean (mostly) two things:
a) They are having a hard work to correct what were reported on RC
b) They don’t that much about issues that were reported and are going to release it anyway.
Let’s see…
Well… That seems to me to be a concrete detail from someone who has the slightest idea of what he’s talking about. And it also has a good basis for comparison with correct functioning in the past.
If this description is correct and complete, and they go straight to 7.15 stable without clarification about this, it will be a typical case of MT behavior.
What makes me disappointed is that colleagues who have a real problem case are having to come here and publish the support case ID so that it is not “forgotten”.
Sort of proof that what is being said is really happening.
This reminds me about the Memory Leak case in 7.15.rc2 that was mentioned by colleagues here in this thread.
Has there been any stance from MT on this?
Wait for the next RC, there will be potential fix for the problems appeared in v7.15 builds. However there can be other “high CPU usage” causes that are not strictly related to v7.15
What’s new in 7.15rc3 (2024-May-13 18:26):
*) bridge - added error message if MLAG peer-port is configured with “mlag-id”;
*) dns - added support for “adlist”;
*) leds - fixed LEDs for RBLHGG-5HPacD2HPnD device (introduced in v7.15rc1);
*) lte - continue to dial on LTE attach config error for MBIM modems (introduced in v7.15rc1);
*) lte - do not show persistent interfaces for multi-apn slave interfaces;
*) lte - fixed USB alternate composition switching when “mode=mbim” (introduced in v7.15rc1);
*) lte - removed 2 APN restriction for RG520F-EU modem;
*) lte - use the correct network interface for multi-interface LTE modems;
*) media - added support for DLNA;
*) netinstall-cli - fixed incorrect server address assignment (introduced in v7.14);
*) ppp - fixed IPv4 accounting (introduced in v7.15beta9);
*) route - improved system stability;
*) route - rework of route attributes;
*) ssh - fixed bogus output;
*) system - skip configuration upgrade from RouterOS v6 on configuration reset;
*) wifi-qcom - fixed connectivity and authentication issues (introduced in v7.15beta9);
*) wifi-qcom - fixed fast BSS transition over distributed system (introduced in v7.15beta9);
*) wifi-qcom - fixed incorrect min-signal and max-signal values in the output of frequency-scan tool (introduced in v7.15rc1);
One thing I wanted to ask many times already:
why are changelog entries from previous version(s) also mentioned in newer versions changelogs over and over again?
e.g.
*) dns - added support for "adlist";
*) media - added support for DLNA;
That is of course utter nonsense. EVERY SOFTWARE MANUFACTURER puts versions into release with known problems.
The only thing you can blame on MikroTik is that there is no list of known problems (confirmed or under investigation) available to the public.
The beta/rc changelog represents changes since the previous stable release. So if there was an additional fix for some feature added, we do not write it as a new chagelog entry on each and every beta/rc release. We simply “move it up”. So what was changed regarding adlist or media feature since 7.14.3 - “added support”.
Beta/rc is not only a “testing” release regarding software, but also for the changelog. The final changelog comes with the stable release.
Is there already some way to delete RouterOS v6 configuration from an upgraded device? (other than netinstalling it)
There is a problem with route enumeration using snmp, e.g. using the command
snmpnetstat -v2c -c public -Cr hostname
In some cases, it continues printing the same route over and over, it seems the “get next” gets in a loop.
Not sure at which version that exactly has been introduced, but it worked OK before.
It does not happen with simple configurations, but e.g. this reproduces it:
/routing table
add disabled=no fib name=test1
add disabled=no fib name=test2
/ipv6 route
add blackhole disabled=no dst-address=fec0::/10 gateway="" routing-table=main \
suppress-hw-offload=no
add blackhole disabled=no distance=1 dst-address=fec0::/10 gateway="" \
routing-table=test1 scope=30 suppress-hw-offload=no target-scope=10
add blackhole disabled=no distance=1 dst-address=fec0::/10 gateway="" \
routing-table=test2 scope=30 suppress-hw-offload=no target-scope=10
It also happens with IPv4 routes, and it does not require multiple routing tables. It does require multiple routes to the same destination (e.g. default).
@olgale After updating to 7.15rc3, the problem still persists.
I saw two entries in the log about route fixes.
However, the issue remains.
I have submitted a new supout file uploaded to SUP-151768, please check it.
What’s new in 7.15rc3 (2024-May-13 18:26):
*) route - improved system stability;
*) route - rework of route attributes;