Fun fact:
@Normis is promoting Mikrotik automatic upgrade with his new, todays video.
Wow, great news! This is perfect for tested and stable versions like v7.2.2. And besides that, if something should happen (god forbid), you may use Netinstall that is a very capable tool that doesn’t require any settings and will easily restore your device within minutes. 
It takes some balls promoting auto upgrade after recent 100% bricking releases.
Unfortunately such videos or other publications will reach only a tiny number of users, and most MikroTik routers will spend their life on their factory software, even 5 years after critical vulnerabilities have been found in it.
There should be a default auto-upgrade mechanism in place (if only by adding this example to the default config) and it should use a dedicated channel where new versions are only placed after at least a month of testing in one of the other (long-term or stable) channels, determining there are no known cases of bricking or other major problems.
Unfortunately MikroTik do not understand that and suggest that long-term serves this purpose. But long-term only refers to longer maintenance of an older version, not to a safe upgrading path you can apply without risk. New versions are placed in long-term without field testing in the “stable” branch, so they can brick or cause big problems to your router anyway. Not good when that happens automatically…
Good summary!
In particular, the importance of distinguishing between versions for long-term maintenance and safe upgrading. Hopefully MT will look over and take a holistic approach to the whole upgrade process for automatic updates (and fall-back), a new channel for properly tested versions and a usable tool for painless recovery.
btw, I use L2TP with CCR for ~400 clients.. and v6 from time to time give me error, and all still works.
Anyone have it at ros7 ?
ppp,error,critical: 217.67..: Encryption got out of sync - disabling
This is old unsolved by MikroTik case with one we all must live… of course it was reported in past.
I don’t think they are getting the point. You can see that in reactions to the video, and also before on this forum.
We have seen it before:
- at some random (for us) point in time the decision is made to “promote a development version to stable” (in the middle of a discussion about stability)
- at that time:
– 6.(xx+1)rc5 (development) becomes 6.(xx+1) which is the new “stable”.
– the most important fixes from “development” are back ported to 6.xx.n (the previous “stable”) it becomes 6.xx.(n+1) and it is renamed to “long-term”. - unfortunately there are issues (as could be expected due to the state of the development version)
- soon, a new 6.(xx+1).1 “stable” version and a 6.xx.(n+2) “long-term” version are released to fix the most apparent issues.
So when the long-term version increments, it essentially is an earlier “stable” version plus a couple of patches, and the whole thing is not field-tested (never was “stable”).
It certainly would not be a good idea to update millions of devices to that the next night. Let it spend some time in long-term, to wait for the problem reports and fixes.
There should be an extra “security” channel for those users that do automatic updates, that receives the version from long-term after it has really stabilized, and does not receive updates that are merely feature changes. Only security-related changes trigger a new version from long-term to be copied to “security”, and only after having spent a month or so in “long-term” without reports of bricking or major bugs.
In rare cases where there is a critical security bug that affects most installations badly, it can be considered to release a new version in that channel that is based on the previous “security” version plus ONLY a fix for that particular problem. So NOT the “currently stable” version or another upgrade that also changes other things.
It could be considered to make this “security” channel special in that a user could have selected “stable” or “long-term” as their main channel from which they do manual updates, and “security” is the channel used by the daily job, in such a way that updates are installed from there only when they are newer than the installed version.
Those that do not want any unpredictable changes can always remove or disable the scheduled job, and those that do not know or do not care will receive updates when required to keep the router secure, but can still track the developments when they choose to do so.
I have never seen that error. Does it occur with particular types of clients?
One possibility why MT does’t understand and hasn’t already fixed the problems is that they lack an experienced “release manager” with authority who works at management level. There may also be a lack of resources, but for whatever reason they’ve arisen, these problems can be remedied if management really wants to (and is aware of the problem)
They’ve managed to develop marketing to a new level with new websites, newsletters and communication channels thus it should be possible to fix the release management as well.
@Larsa IMO I believe that Tik management understand the cost equation … the more people you hire in mgmt positions the les comparative you will become.. MikroTik are doing a GREAT Job with the resources they do have — consequently very competitive and an unbeatable value proposition to boot.
But seeing that you are from California where tech companies go nuts for over-management socialistic practices I can understand your stance. 
Well, middle management might be a pain in the b*tt pure cost wise but a tech company like MT probably already has sufficient technical resources but lacks awareness how to organize things like promoting someone who can take the lead regarding release mgmt. This doesn’t necessarily mean you will act as full time manager but it’s rather a job description that comes with some kind of authority. (IMHO)
With my RB4011 and ROS v6.49.6 the cpu load when doing a speedtest @1Gbps is between 1-8% per core.
With ROS v7.2.3 the cpu load now goes up to 30%. and yes i checked, HW offloading and fasttrack are enabled.
any idea ?
[admin@MikroTik] > interface/bridge/port print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON
0 H ether2 bridge yes 1 0x80 10 10 none
1 H ether3 bridge yes 1 0x80 10 10 none
2 IH ether4 bridge yes 1 0x80 10 10 none
3 H ether5 bridge yes 1 0x80 10 10 none
4 IH ether6 bridge yes 1 0x80 10 10 none
5 IH ether7 bridge yes 1 0x80 10 10 none
6 IH ether8 bridge yes 1 0x80 10 10 none
7 IH ether9 bridge yes 1 0x80 10 10 none
8 IH ether10 bridge yes 1 0x80 10 10 none
9 I sfp-sfpplus1 bridge yes 1 0x80 10 10 none
10 I wlan1 bridge 1 0x80 10 10 none
11 wlan2 bridge 1 0x80 10 10 none
[admin@MikroTik] >
v7 uses more CPU than v6, especially when doing benchmarking like speedtest.
has been explained several times already.
cetipabo, the key words are “routing cache” - it’s removed in recent Kernel versions
But why? More throughput or less?
Thanks
@pe1chl and @Chupaka
Thanks ! i just wanted to know if it was normal or a misconfiguration on my side, or some kind of tweaking that i missed.
i’m just starting on Mikrotik world, so sorry for not having read the whole forum in one night, i just received my RB4011 yesterday.
Less fake throughput.
Read: results you see now in ROS7 are closer to real life performance.
Tss tss tss… some catching up to do then :lol:
it was removed because it caused problems or it’s just not implemented yet in V7 and it will be later ?
Less fake throughput.
Read: results you see now in ROS7 are closer to real life performance.
But fake throughput you mean from bandwidth test, or from speedtest ISP?
Why just it drain more CPU on same Gbit line?