Yeah, @sirbryan totally wrecked Mikrotik’s April Fool’s prank they’d been planning for over a year! 
That “Change TCP MSS” feature (for instance in the PPP profiles) only works with IPv4 in RouterOS and has no effect on IPv6 (it’s stated in the docs), and of course it only helps TCP connections whereas today even websites are switching to UDP (with HTTP/3 and QUIC). For IPv6 it’s better to configure IPv6->ND like pe1chl already wrote.
And changing TCP MSS with mangle has no conflict with fasttrack, because the mangle rule only applies to the SYN and SYN/ACK packets. One is when the connection state is still new (and thus not yet affected by the fasttrack rule), and the other for the first packet in the “established” state, but because “Mangle Forward” is before “Filter Forward” in the packet flow https://help.mikrotik.com/docs/download/attachments/328227/Pfd.png?version=1&modificationDate=1570627732451&api=v2, the mangle rule can still change the MSS before the fasttrack rule can match the connection. I know this because I have those mangle rules for both IPv4 and IPv6 right now (needed because I tunnel devices accessing Netflix, both IPv4 and IPv6, inside Wireguard to another household for account sharing) with IPv4 and IPv6 fasttrack working flawlessly.
I kindly ask all users to keep the topic related to 7.18RC version as much as possible.
FWIW I’m testing CHR on smaller hardware, such as Intel N100 and N150 4-core machines, as well as a Raspberry Pi CM5. 7.18rc1 performs much better than 7.17 did on both systems. Both devices are able to push 2.5Gbps UDP in both directions, and up to 5Gbps when using a 10G AQC107 NIC.
However, the native Debian underneath is able to do 1Gbps more on CM5 and 3Gbps more on N150 when running iperf3 tests, and both do it on a single core, vs. CHR in KVM/Qemu utilizing 80% of all four cores. It makes me wonder how much is virtualization overhead and how much is RouterOS.
For the sake of clarity, I would like to emphasize that the MikroTik team is doing its utmost. Please consider RouterOS as a complimentary software that comes bundled with excellent hardware, along with nearly lifetime updates.
Let us remain optimistic and refrain from discouraging others.
Best regards and best wishes.
So not quite sure here whether it is, or isn’t hardware offloaded
What is the model of that device?
You have to make sure you’re comparing pears to pears (not going to mention apples 
). ROS in principle does firewalling as well and connection tracking machinery (identifying connections to which each packet belongs) is pretty costly operation. OTOH linux kernel might not be doing it. IIRC connection tracking is enabled whenever there’s even a single firewall filter rule configured …
My experience is that virtualization overhead (e.g. Proxmox VE) can be around 1 core, specially when there’s lots of I/O using virtualized hardware (vmnet, disks, etc.). You can compare output of /tool/profile cpu=all with output of e.g. top run on physical machine. And keep in mind that mobile variants of CPUs are quite a bit slower than their desktop/server counterparts.
I found this feature request to be as elegant as a glove slap!
The detail of mentioning the ticket ID in Jira is the cherry on the cake.
Congratulations!
P.S.: At some point I had the patience to do it like that… Like time, realizing that they don’t care about it at all. I gave up. But please don’t do what I did.
@massinia Your message came right after @volkirik’s message.
I want to believe that this isn’t the message you were referring to about Off Topic.
I found it extremely On Topic for a Release Candidate! Asking for features.
Just like other colleagues who have been talking about routing problems that they pretend to have fixed by writing “(additional fixes)”, but you can see right away that they weren’t extensively tested because the same names are repeated in the forum talking over and over and over about the same problems.
Unfortunately, betas and RC threads in this forum are the only place where you can truly reach the MikroTik team. Because they know that if they don’t look at this, it will become public shaming. Maybe they should improve this attitude a little.
In addition, it is also On-Topic for a Release Candidate to talk about:
- The lack of 6PE and 6vPE, and BGP-LU.
- The lack of progress on Kernel bypass and hardware off-load on issues like VRF, MPLS L2VPN, and L3VPN.
- The lack of progress on BGP Flowspec (poor thing… It’s been forgotten in the routing overview since the beginning.)
And it is also On-Topic for a Release Candidate to talk about the initial progress with VXLan and Hardware Offload.
Which inevitably leads to questions like:
- “Hey, what do you mean I can’t pass VLANs over this?”
- "Is EVPN coming soon?
- “Will it come with Type 5 Routes?”
- “If yes, how would be possible without VRF hardware offload?”
All of this is related to how Linux interacts with disks, and they still use Kernel 5.6.3 (April 2020) as a base.
If anyone here has had the opportunity to deal with distributed storage in Kubernetes clusters or hyper-converged virtualization, they must have read about significant changes in this regard in several versions of the Kernel after 5.6.3. Mainly regarding DMA.
Just to illustrate, here are two links that provide brief references on this.
https://en.wikipedia.org/wiki/Linux_kernel_version_history
https://btrfs.readthedocs.io/en/latest/Kernel-by-version.html
I can’t imagine they have incorporated all patches for any improvement made to BTRFS in kernel 5.6+ and 6.0+. So what it the point of using outdated ROSE BTRFS when someone can have that on e.g. TrueNAS for example (or any Linux distribution)?
I partially agree with you! But what’s done won’t be undone…
So at least let’s use this to make them realize that if they want to continue down this path of adding new features, they’ll have to take better care of the building’s foundation.
MikroTik should have already started migrating to 6.6.x, which is LTS and has all the storage improvements. The current OpenWrt is also on this branch. I think MikroTik currently use 5.6.3 because 5.6 is the first release that has WireGuard support in the kernel. Otherwise, they would have used an even older version 
.
Well, the latest LTS branch is 6.12.x…
That’s why I wrote “should have already started”. If they already started last year, then 6.6 would have been the right candidate (because 6.12 only came at the end of the year).
It has been discussed many times before. The trade-off is always between following the kernel releases and applying your in-house patches to ever changing kernel versions (having to adapt them all the time) or keeping the same kernel version+in-house patches and then following the kernel development and applying any security related patches and important bugfixes.
Most Linux distributions to the same thing as MikroTik: at release time they choose a kernel version and all further updates are to that same kernel version (adding some local version ID to it).
Of course the best would be to get local patches accepted into the release kernel so you don’t have this issue all the time, but that is both extremely difficult (I have tried to get a 3-line patch into the kernel and have given up) and also probably not desired by MikroTik because they would lose some of their competitive advantage.
- LDP signaled VPLS is still not working at all
- over BGP signaled VPLS, IPv4 is ok, but IPv6 isn’t [ ping status: “22 (Invalid argument)” ]
- VPNv6 is still not works, but at least in RC1 router doesn’t crash
LDP signaled VPLS works
BGP signaled VPLS works
VPNv6 works
either misconfiguration or very specific setup.
Could you please share an example config with at least 4 devices RouterOS, being at least one on P.Router Only, with the v7.18rc ?
VPNv6 does indeed work, but only partially, as it does not support an IPv4 backbone as a transport layer.