Did you hear this from Mikrotik staff ?
This is a widely requested feature and yet for some reason its 2024 and it still has not arrived.
I did not hear that fasttrack would be coming, BUT
I did see a post from a Mikrotik employee (sorry, can’t find it now) stating that hey are working on hardware acceleration for IPv6. Now, I know it isn’t fasttrack, but isn’t L3 hardware routing dependent on fasttrack? I really think they are closed related, in terms of stack processing. Not in terms of hardware, of course, since fasttrack can be done 100% in software and L3HW depends on hardware implementation.
They are related but they are not the same thing. When you have hardware capable of L3 processing, one way to use it is to offload the processing of fasttrack into it. But as you rightly indicate, then first you need to have fasttrack in the first place.
However, the L3 hardware is also capable of handling static routes, for IPv4 and IPv6. Both uses have their pros and cons.
Readn the L3 hardware relevant documentation for more info on this.
That’s the part relevant for this topic. My point is, since they ARE developing L3HW for IPv6, i THINK (I don’t KNOW, I just think) that as a subset fasttrack will be developed too. I should have asked in that thread, but alas…
IPv6 HW Forwarding is here now and available on the CRS3xx and CRS5xx (I am running it right now)
However IPv6 HW and IPv6 FastPath are implemented in very different ways. Unfortunately IPv6 FastPath is still not here. IPv6 FastPath will benefit other platforms where L3HW is not an option, as well as allow stacking for things like VPNv6.
I’m just genuinely curious can someone from MT camp/support can tell us why they are having a hard time to implement this very important feature for SOHO markets, if they can do it in IPV4 why not in IPV6 been using other gears for the last 5 to 6 years and never seen this is an issue, Is this purely a business decision or just plain technical issues that has multiple layers of complexity upon layers complexity just like we are experience with BFD,VPLS and et. al?
+1 for this feature.
IPv6 FastTrack is the one single feature that is holding me back from upgrading my HEX S to RouterOS v7…
And here we are, 3 years after creation of this post and yet no ETA for this feature. It’s sad.
IPv6 FastTrack is the one single feature that is holding me back from upgrading my HEX S to RouterOS v7…
I’m curious why that is. It’s not like there’s IPv6 FastTrack in RouterOS v6 is there?
I dont know.
The problem is that in RouterOS v6 there is something called “Route cache”. In RouterOS v7 this is not present.
As a side effect, in low-end / SOHO routers, like the HEX S, IPv6 traffic cant pass the 280 Mbps mark (in my scenario at least) using RouterOS v7, in contrast to RouterOS v6 where i can full saturate my gigabit fiber symetric internet connection.
That is true, and it is a reason why you should not upgrade an old and slow router to v7 when you do not need to, but you should also realize that this route cache affects the performance during “speed test” (where you are sending lots of traffic to/from a single IP address) but it much less affects the performance in daily operation, where there is traffic to/from a lot of different addresses.
That is also the reason why the route cache was removed. It added complexity and it did not work that well in daily operation.
Here I think You are making a judgement mistake: Yes, all You said is right - but I don’t agree with the use case analysis. Let me explain.
Yes, it’s true that routers with a great number of connections don’t get much (if at all) benefit from the cache.
Yes, it’s true that speed tests see the most benefit from the cache.
Yes, it’s true that complexity, vulnerabilities and irrelevancy to core routers was the reason it got booted from the kernel.
BUT
For home routers - and for routers that deal with few but very intensive connections - it makes a huge difference. So I completely disagree with the “it only benefits speed tests”. It isn’t true at all - it just doesn’t benefit some uses, while helping others. Not every router is a core router. Not every user has 15k connections crossing his equipment.
Talking about route cache is completely irrelevant. It’s gone long ago. If MT wasn’t using very obsolete linux kernel in ROS v6, then we’d loose route cache already years ago.
Also it wasn’t Mikrotik’s decission to drop route cache. So again bitching about it in this forum is completely irrrlevant.
What does matter (and this thread is about it actually) is implementation of fasttrack support for IPv6. It doesn’t seem to be (overly) depending on kernel version (at least for IPv4), so it’s probably doable.
So please, MT, introduce IPv6 fasttrack.
Yeah, and the idea that the cache is gone in the current kernel is a myth and misconception. The current V7 kernel uses a more modern and secure network stack that divides the cache into distinct layers to achieve better efficiency where it’s needed most.
Some relevant reading on the subject:
Any idea why FastTrack is not a standard kernel feature?
Even if MikroTik have developed it and refused to give it back to the community, would it not be a “simple idea” that could have been in the standard kernel sources for years already?
Fastpath is, so I guess adding conntrack to the mix is maybe doable even without mikrotik involvment ? I would guess that the MKT implementation is maybe too “linked” to the hardware they’re using ? In any case, isn’t something like flowtable pretty similar already ?
MT should look at DPDK in my opinion: https://www.dpdk.org/
That cannot be! RouterOS is running on a very wide variety of hardware.
Two major things make DPDK unsuitable for the current product line:
- DPDK is a pure userland solution while ROS is kernel-based.
- DPDK’s resource footprint is way too large to fit an embedded network OS like ROS.
DPDK is normally used in highly specialized high-end “appliances”.
DPDK is normally used in highly specialized high-end “appliances”.
[/quote]
Hmm, in the 90’s preemptive multitasking was normally used in highly specialized high-end mainframes…
But you might be right I can´t really judge. However there are other projects trying to speed up networking:
VPP:
https://fd.io//
Still it´s user space.
+1 for fasttrack on IPv6;
On the products info pages would be nice to have IPv6 performance tests.