7.18RCs also crashing with VPNv6 if router gets longer prefixes then /64, for example /96. It is around early processing of BGP updates as filters doesn’t prevent crash. I think this is not a corner case. Unfortunately I didn’t get any updates from support from 27th of January, even I provide LAB access for them as they asked.
NoTrack makes IPsec faster with bypassing connection tracking:
However, this can add a significant load to the router’s CPU if there is a fair amount of tunnels and significant traffic on each tunnel.
The solution is to use IP/Firewall/Raw to bypass connection tracking, that way eliminating the need for filter rules listed above and reducing the load on CPU by approximately 30%.
+1
I don’t want to offend anyone, those with weaker nerves should close their eyes now.
I don’t care if MT adding features which push down other NAS OSes (for unknown reasons) till the core functionalities at least gets as much care as other, not networking functions. As soon as these not core functionalities gets more care, the RouterOS is not Router OS anymore, getting more like a NAS OS. Unfortunately, I only occasionally see routing issues being fixed in changelogs, while features and bug fixes are being flooded into disk and rose-storage and other similar irrelevant features for networking. It’s like buying a new futuristic car, but the manufacturer only cares about the eye-catching features of the damn big tablet on the center console in the car. I can spends a lot of time in the car with minecrafting, but the chassis will blown out below me. What a hell is going on?
+1 too
I really don’t care about file sharing and such, there are other companies/OSes that do that for years and are pretty good at it.
Please keep focus on networking …
How about management updates ? dude ? and stuff like that. Way more important for me …
IF it must be done, make all those fancy stuff modular, so I can ignore them …
Mea culpa, after I fixed the overlapping IPv6 addressing on both VPLS, IPv6 works fine too so BGP signaled VPLS is ok. LDP signaled has other issue as it doesn’t work at all. It has no remote-label:
Thanks for the pointer to the IPsec Wiki page. It looks like my issue is also documented in the FAQ on that page at the very bottom:
Random packet drops or connections over the tunnel are very slow, enabling packet sniffer/torch fixes the problem?
Problem is that before encapsulation packets are sent to Fasttrack/FastPath, thus bypassing IPsec policy checking. The solution is to exclude traffic that needs to be encapsulated/decapsulated from Fasttrack, see configuration example here.
My guess:
The advanced storage features in RouterOS were born related to MikroTik’s centralized controller.
The best methodology I’ve found so far to control a large number of MikroTik devices was through eworm scripts (except CPEs, which are logically TR-069). The closest thing I’ve seen to Intent Driven Design.
And if you think about it, combining the ramdisk+rsync features, or for less demanding scenarios Back-to-Home-Files, is the most appropriate way to have this intent driven design.
So far, these features are something good and necessary.
However, I believe that when they did put good developers to work on this to create a solution, the product team must have gotten a little too excited when they saw what was coming out, and had wet dreams of venturing into this other world beyond routing and switching.
I don’t think having these features is a bad thing. What is bad is the stupid decision to neglect important things like dataplane and control-plane separation or routing protocols to focus on delivering the base version of the storage platforms.
The criticism here is about redirecting efforts.
This talk that the routing development team is dedicated specifically to this, in my opinion, is a lie. And I challenge the MikroTik people to prove me wrong through the fun videos on YouTube about the company’s backstage. If that happens, I will be happy to acknowledge that my statement is wrong.
I ask again for focus on:
Ensuring minimum resources, and also limiting them to a certain maximum, for control-plane processes.
Making Kernel bypass and hardware offload work in these protocols.
Splitting features in new packages.
And to those that say that this post is Off-Topic.. Well, this is about the release candidate, right? And it is clear that the expectations of most RouterOS users were not met with what will come in 7.18.
Making Kernel bypass and hardware offload work in these protocols.
Splitting features in new packages
You are just wasting your energy and time, been there done that in Mikrotik world the order of priority is not routing and switching it’s something whatever they desire, they don’t even know their core strength as a company they have good hardware but lack focus in the software stack, I won’t repeat on the talking points here
Very frustrating right.
For me v7 almost 10 years now from introduce in our MUM and some problem i’ve reported, some of them answered will be fix in v7.
Event in CCR 1 series with v6 os, we left the legacy with problems, i am sorry to say that.
And now with CCR 2 series with v7 the developmen seem so slow
I stand with you on this. I will also eat my own socks if MikroTik proves us wrong. I agree, and I’ve also been very vocal as of lately on their need to better align their focus and priorities - figure out what their identity is. Become laser focused on producing quality software releases. The hardware isnt the problem - MikroTik has quite good hardware engineers [routing, switching] Wireless still needs work [cost cutting on sheilding and antenna designs].
Fork ROSE to separate project for a MikroTik NAS. Work on separating management, control-plane, processing.
we see routes being double-installed when the MT acts as ABR with a second ABR for the same areas using ospfv3 in 7.18rc2 - SUP-180213
the issue is only active with IPv6, opsfv2 and IPv4 does work fine for the same setup.