MikroTik

Posted: **Tue May 25, 2021 2:08 pm**

Hello there.

Creating this dedicated topic after reading the post of raimondsp :

viewtopic.php?f=1&t=175369#p859010

...

. We cannot do Fasttrack offloading until the software IPv6 Fasttrack gets implemented. The latter is on the TODO list (backlog) but not on the roadmap yet. I suggest creating a feature request thread on RouterOS v7 forums for IPv6 Fasttrack - if it gets enough user attention, it might receive a priority boost.

To me, with ipv6 being more and more needed, having to give priority to ipv4 for performance reason is not a good place to be in. And since CCRs without switchchip won't be able to use h3 l3 offloading, I would like to see ipv6 fasttrack in RouterOS v7.

Thx.

Posted: **Tue May 25, 2021 2:11 pm**

+1

IPv6 is already widespread, how is IPv6 FastTrack not a feature already!

Posted: **Tue May 25, 2021 6:48 pm**

Posted: **Tue May 25, 2021 7:02 pm**

+1 mikrotik's ipv6 implementation is lagging way behind that of other vendors.

Posted: **Tue May 25, 2021 7:47 pm**

+1

IPv6 is among us already for ages, lack of performance in ROS is unbearable.

Posted: **Tue May 25, 2021 8:30 pm**

+1
Incomprehensible that Ipv6 is not Fasttrack … incomprehensible!

Posted: **Tue May 25, 2021 8:31 pm**

+1 for IPv6 Fasttrack

Posted: **Tue May 25, 2021 8:47 pm**

I have no problem with IPv6 performance (Fasttrack is always the first thing I disable) but I think IPv6 deserves way more attention from MikroTik, the "our customers never ask for it" no longer cuts it.
When that includes Fasttrack development for some people, I welcome it to be included (as long as it can be disabled).

Posted: **Wed May 26, 2021 5:43 pm**

+1

IPv6 adoption has already reached 40-50% in many countries as per Google statistics. It shouldn't be treated as second class citizen in RouterOS. People expect IPv6 to provide the same performance as IPv4, which is only possible with Fasttrack.

Posted: **Thu May 27, 2021 3:58 pm**

The amount of IPv6 work we have done as MikroTik consultants in the last year has been staggering. We rarely build a new network without designing for IPv6.

This is a critical feature, please give it priority.

Posted: **Thu May 27, 2021 4:04 pm**

IPv6 parity with IPv4 is a requirement.

Posted: **Thu May 27, 2021 5:27 pm**

I’m starting a new WISP now and I’m shocked to learn that IPv6 fast track is not yes available. That seems nuts.

Posted: **Thu May 27, 2021 7:00 pm**

I’m starting a new WISP now and I’m shocked to learn that IPv6 fast track is not yes available. That seems nuts.

I advise you to buy routers that can run your workload without fasttrack.
IMHO fasttrack is more targeted towards home routers where the user wants to get the high bitrate of their modern fiber or cable connection on an outdated router model.
In a WISP, when you would want to do any connection tracking at all, you should not need that extra performance tweak but rather get faster routers.

Posted: **Thu May 27, 2021 9:06 pm**

+1 for IPv6 Fasttrack

Posted: **Tue Jun 01, 2021 2:01 pm**

+1 for IPv6 Fasttrack

Posted: **Tue Jun 01, 2021 8:45 pm**

Yes please! :)

Posted: **Fri Jun 11, 2021 3:48 am**

Why isn't this a thing yet?

Posted: **Fri Jun 11, 2021 1:19 pm**

+1 for this
IPv6 Fasttrack is a must in 2021, as most of the MikroTik devices are not capable of gigabit routing when IPv6 is involved.
my hAP AC^2 is only capable of ~600mbit on IPv6. my RB4011 uses 22% of CPU when passing ~1gbit traffic

Posted: **Wed Jun 23, 2021 7:33 am**

I’m starting a new WISP now and I’m shocked to learn that IPv6 fast track is not yes available. That seems nuts.
I advise you to buy routers that can run your workload without fasttrack.
IMHO fasttrack is more targeted towards home routers where the user wants to get the high bitrate of their modern fiber or cable connection on an outdated router model.
In a WISP, when you would want to do any connection tracking at all, you should not need that extra performance tweak but rather get faster routers.

No fast-path on the edge, Yes fast-path on all your distribution routers where you don't need to inspect most packets. An est/rel IPv6 fast-path for distribution routers is a real must have these days now that many of us are pushing >3Gbps between pops.

Posted: **Thu Jun 24, 2021 4:24 pm**

+1, IPv6 is a must for my deployments.

Posted: **Thu Sep 09, 2021 11:30 pm**

+1. Just bought my first MikroTik router to use on my 1Gbit connection and was very disappointed to see that I can only get that speed on IPv4. IPv6 runs at less than half the speed unless I completely remove all firewall rules. That is pretty unacceptable for 2021 when 50% of traffic is now using IPv6.

Posted: **Fri Sep 10, 2021 2:32 am**

+1

would love to see ipv6 supported in fasttrack, ipv6 is fully deployed in my network and the only hardware that can currently handle anywhere near 10gbit/sec is the CCR2004. fasttrack support for ipv6 would introduce many new options for l3 routing in my network.

Posted: **Fri Sep 10, 2021 6:25 pm**

At home I have DS-Lite from operator. With GPON Huawei router I have 1G connection speed, but when I made the same scheme of connection via Mikrotik hAP^2 more then 220Mbp/s I can't see.
Without IPv6 fasttrack next development of system are not possible.

Posted: **Sat Sep 11, 2021 3:02 am**

+1 for IPv6 Fasttrack

Posted: **Sat Sep 11, 2021 4:07 am**

+1 IPv6 Fasttrack

Posted: **Sat Sep 11, 2021 5:17 pm**

This is 2021 final quarter. Please implement a proper IPv6 stack. It is till way behind other vendors. Recursive routing is still not implemented. Time for mikrotik to pull up the socks. Docker and stuff can still wait, core functionalities of a router must be the priority.

Posted: **Sun Sep 12, 2021 12:30 am**

+1 IPv6 Fasttrack

Posted: **Sun Sep 12, 2021 12:55 am**

This is 2021 final quarter. Please implement a proper IPv6 stack. It is till way behind other vendors. Recursive routing is still not implemented. Time for mikrotik to pull up the socks. Docker and stuff can still wait, core functionalities of a router must be the priority.

Totally agree. There seem to us there is no clear vision what Mikrotik wants to be. It wants to be Home/SMB/App-developer/5G/IOT and at the side it also route ipv6 packets for enterprises.

Posted: **Sun Sep 12, 2021 12:26 pm**

This is 2021 final quarter. Please implement a proper IPv6 stack. It is till way behind other vendors. Recursive routing is still not implemented. Time for mikrotik to pull up the socks. Docker and stuff can still wait, core functionalities of a router must be the priority.
Totally agree. There seem to us there is no clear vision what Mikrotik wants to be. It wants to be Home/SMB/App-developer/5G/IOT and at the side it also route ipv6 packets for enterprises.

To be a home router supplier you need to support IPv6 as well! Maybe the current state of things (except maybe "Fasttrack") is good enough for that, but still there are many features to be brought on-par with IPv4 that are also useful in home use.

Posted: **Sun Sep 12, 2021 1:14 pm**

I totally agree: IPv6 is a matter of present for everybody and should be trated and supported as such. No amount of turning blind eye will change that.

While advanced features such as NATv6 would be nice to have, it's basic IPv6 support that has to be brought to higher level and it has to be done like yesterday.

Posted: **Sun Sep 12, 2021 5:43 pm**

+1 for ipv6 fasttrack

Posted: **Sun Sep 12, 2021 6:39 pm**

Still waiting! SOHO routers like Eero have had full IPv6 speeds for years now.

Posted: **Mon Sep 13, 2021 4:24 pm**

+1 request for this feature (very expected here)

Posted: **Tue Sep 14, 2021 2:20 pm**

+1 from me

Posted: **Tue Sep 14, 2021 3:14 pm**

+1 - please

Posted: **Sat Sep 18, 2021 11:34 am**

+1 for ipv6 fasttrack and оptimizing stack

Posted: **Sat Oct 23, 2021 8:02 pm**

+1 for IPv6 Fasttrack

Posted: **Tue Nov 02, 2021 10:07 pm**

+1 Here.

Posted: **Sat Nov 06, 2021 6:23 pm**

I discovered today no fast track on ipv6. Oh no! +1.

Posted: **Sun Nov 07, 2021 4:57 pm**

A must have...
+1

Posted: **Tue Nov 09, 2021 5:50 pm**

+1 Would be great to have ipv6 be as fast as ipv4

Posted: **Wed Nov 10, 2021 11:30 am**

+1 IPv6 Fasttrack

Posted: **Mon Nov 29, 2021 11:46 pm**

+1. This feature is table takes in 2021, and offered by Ubiquiti/EdgeRouter.

Posted: **Wed Dec 08, 2021 6:47 pm**

+1

Stop letting the IPv6 stack languish and start treating IPv6 as a priority.

Posted: **Wed Dec 08, 2021 9:28 pm**

Some people are noticing than ipv6 is slower on RoS7 vs RoS6 on some hardware. It's increase the need of fasttrack imo....

Posted: **Wed Dec 08, 2021 9:45 pm**

Or of new hardware.

Posted: **Wed Dec 08, 2021 9:54 pm**

Or no action at all and just happily using the router...
Living only for benchmark is not very useful...

Posted: **Thu Dec 09, 2021 6:43 am**

Or no action at all and just happily using the router...
Living only for benchmark is not very useful...

Why are you talking about benchmark ? We should just accept that ipv6 is way slower than fastracker ipv4, at a time where ipv6 is more and more used ?

Posted: **Thu Dec 09, 2021 11:24 am**

It is explained in the 7.1 release topic.
Before, there was a "route cache" in the Linux kernel which meant that it would keep the last routed address and when a next packet is to the same address, there is no need for a new route table lookup (actually there are a few addresses in this cache).
So in v6, when running a speedtest, this cache was used and it was faster.
However, in the current Linux kernels (not something decided by MikroTik!) this cache no longer exists. So each route has to be looked up in the table.
This means that a speedtest runs slower.
However, in real operation, there is communication with a lot of different addresses, and this cache was not every effective anyway.
So the "normal use" will not be much slower, certainly not as much as "indicated" by the speed test.

Fasttrack is another level of such caching, where even more of the connection state is used to bypass checks done on each packet, e.g. the firewall.
Sure it would help, but you should always understand: when you need Fasttrack to make your internet connection perform at its rated speed, you have bought a router that is too slow for your line.
Fasttrack can always be replaced with a more suitable performance router.
I always disable fasttrack because it is incompatible with some of the features of the router I use, and for me it is too much work and too risky to find out exactly what can be fasttracked and what not. So I just bought a faster router.

Posted: **Fri Dec 10, 2021 3:45 am**

I fear that for some Mikrotik hardware something like Fasttrack offload is actually necessary to maximize throughput, no matter how fast the CPUs. The CCR2116 offers 52G of port throughput, but this ports only have a 40G connection to the CPUs, so at least 25% of the traffic would need to be L3 offloaded to the switch chip to reach full L3 port speed with at least some L3 processing rules.

Posted: **Fri Dec 10, 2021 11:05 am**

I expect most people complaining here do have an internet connection somewhere in the 300-1000 Mbit/s range and a router that at best can route up to 200 Mbit/s, or even less when there are other performance-limiting factors (PPPoE etc).
With such devices it can help to have Fasttrack. It helps to optimize the common case and it certainly will promote peace of mind by showing good figures on speedtest sites.

When you have a complex setup with VPN tunnels, QoS, policy routing etc it will be easier to just disable Fasttrack and throw some more hardware at the task.
For example, I currently have a 30/180 Mbps VDSL line and I use a RB4011. No issue at all to operate without Fasttrack.
Before, I had a RB2011. That would not be able to do this.

Posted: **Fri Dec 10, 2021 12:06 pm**

Thanks for these words, this is what people seem to forget: get the right sized hardware as a starting point, many devices are not fully gbit capable and while very welcome fasttrack can only do so much.

I expect most people complaining here do have an internet connection somewhere in the 300-1000 Mbit/s range and a router that at best can route up to 200 Mbit/s, or even less when there are other performance-limiting factors (PPPoE etc).
With such devices it can help to have Fasttrack. It helps to optimize the common case and it certainly will promote peace of mind by showing good figures on speedtest sites.

When you have a complex setup with VPN tunnels, QoS, policy routing etc it will be easier to just disable Fasttrack and throw some more hardware at the task.
For example, I currently have a 30/180 Mbps VDSL line and I use a RB4011. No issue at all to operate without Fasttrack.
Before, I had a RB2011. That would not be able to do this.

Posted: **Fri Dec 10, 2021 4:41 pm**

In addition to limiting all-ports routing speed, lack of Fastttack might also limit single-stream performance, e.g. viewtopic.php?t=131503. I expect you can't buy a Mikrotik with enough CPU power to achieve certain single-steam performance goals (or multiple high-throughput streams, where the number of streams exceed the number of cores) without hardware assist. Offload is the only answer.

Posted: **Fri Dec 10, 2021 5:07 pm**

So the "normal use" will not be much slower, certainly not as much as "indicated" by the speed test.

I consider large single stream downloads to be the "normal use" case for home use. And speed tests are perfectly fine at representing the transfer speed achievable for this.

Most people don't pay for hundreds of Mbps download speed at home to watch video streams, a fraction of that bandwidth would be enough for that. The few moments, when you can really benefit from high bandwidth at home is large downloads. When you download a 100 GB game from steam, you don't want to wait for 45 minutes when it could be done in 15 minutes with the same hardware.

Mikrotik enables IPv4 fasttrack by default in their home devices, so they clearly acknowledge its usefulness in this scenario. Trying to tell everyone that they are wrong about wanting fast downloads on cheap devices because it's not what you consider normal use doesn't help.
The existing discrepancy between IPv4 and IPv6 performance should be fixed.

Posted: **Fri Dec 10, 2021 7:35 pm**

Lack of route cache doesn't explain the noticeable decrease in speed like we see,speedtest or other usages...

And hell, even with V6 some of us want fastpath for ipv6.

Posted: **Tue Dec 14, 2021 12:20 am**

+1...

Posted: **Tue Dec 21, 2021 8:30 pm**

For now, I've purchased a Fortigate for this feature.

Posted: **Sun Dec 26, 2021 11:15 pm**

+1...

Posted: **Thu Jan 20, 2022 3:04 am**

+1...

Posted: **Thu Jan 20, 2022 4:10 am**

+1 It's 2022 and home internet connections have had IPv6 available for over a decade now, FastTrack on IPv6 well and truely needed.

Posted: **Wed Feb 02, 2022 1:58 am**

+1
Absolutely crucial feature!
We use some CCRs to provide service to some student-dorms at our university. IPv6 lacks behind IPv4 with NAT in terms of speed... That's not a good thing in 2022.
I am stoked to see this feature being implemented!

Posted: **Wed Feb 02, 2022 10:18 am**

+1 It's 2022 and home internet connections have had IPv6 available for over a decade now, FastTrack on IPv6 well and truely needed.

i do agree +1 for IPv6 Fasttrack !

Posted: **Fri Feb 11, 2022 2:02 pm**

I'm disappointed by the lack of IPv6 fasttrack - just bought an HAP AC3 and it maxes out single core at 500mbit/sec. For anyone running IPv6 with gigabit at home this is a deal breaker. Please implement Fasttrack ASAP!

Posted: **Mon Feb 14, 2022 1:30 pm**

We cannot do Fasttrack offloading until the software IPv6 Fasttrack gets implemented. The latter is on the TODO list (backlog) but not on the roadmap yet. I suggest creating a feature request thread on RouterOS v7 forums for IPv6 Fasttrack - if it gets enough user attention, it might receive a priority boost.

Add me to the list of people that would like to see it. I have the RB750gr3. Currently my connection is 500mbps, but if it increases in the future, it would be nice if the router would be able to keep up with it.

Posted: **Mon Feb 14, 2022 3:30 pm**

+ 1 for this Feature Request : need IPv6 Fasttrack

Posted: **Sat Apr 16, 2022 12:21 am**

+1 for IPv6 Fasttrack.

I've been using dualstack since 2015, but last year I upgraded the uplink to 60 GHz (500/150 Mbps) and the router to RB3011, but the fasttrack would still be very useful.

Posted: **Tue Apr 19, 2022 9:17 pm**

must have.

Posted: **Fri Apr 22, 2022 4:05 am**

IPv6 adoption approaching 40% globally according to Google[1], and 25-30% according to Cloudflare[2] and Akamai[3].

This is arguably higher priority than anything related to ZeroTier / Wireguard, QoS, etc since it is a fundamental part of most networks now.

[1] https://www.google.com/intl/en/ipv6/statistics.html
[2] https://radar.cloudflare.com/notebooks/ ... ption-2022
[3] https://www.akamai.com/visualizations/s ... ualization

Posted: **Fri Apr 22, 2022 5:30 pm**

caratteristica importante che deve essere implementata immediatamente

Posted: **Fri Apr 22, 2022 5:39 pm**

Ciao @volkirik, hai scritto in Italiano, meglio se scrivi in Inglese...
***
You wrote in Italian, better if you write in English ...

Posted: **Fri Apr 22, 2022 5:48 pm**

italian is sympathetic language

Posted: **Fri Apr 22, 2022 5:50 pm**

italian is sympathetic language

Then why do I want to strangle people that put italian in an english forum thread?

Posted: **Fri Apr 22, 2022 5:54 pm**

sorry sir

Posted: **Thu Apr 28, 2022 5:45 am**

I just purchased a CRS309 because of the hardware offloading of L3 routing and NAT. Just missing IPv6 FastTrack and L3 hardware offloading.

+1 please consider IPv6 FastTrack

Posted: **Mon May 02, 2022 10:28 pm**

I'm all about lowering my power consumption, fast-track enables me to do that.
+1

Posted: **Fri May 06, 2022 5:04 am**

Parity with IPv4 features would be much appreciated.
+1

Posted: **Fri May 06, 2022 9:53 am**

+1 for IPv6 Fasttrack!

Posted: **Fri May 06, 2022 6:05 pm**

Has Mikrotik ever provided an answer to this request?
Is it even feasible on the hardware side of things?

Posted: **Fri May 06, 2022 6:22 pm**

Has Mikrotik ever provided an answer to this request?
Is it even feasible on the hardware side of things?

They have. It's actually even linked in the very first post.

And yes, some of the SoCs and switch chips Mikrotik uses support IPv6 offloading.

Posted: **Sat Jun 04, 2022 8:24 pm**

Any news ? IF it arrives, will this be ROS 7 only, or V6 too ?

Thx.

Posted: **Sat Jun 04, 2022 9:02 pm**

One thing is for sure, it will never be in v6.

Posted: **Mon Jun 20, 2022 2:48 am**

I was wondering why I had slow performance over IPv6 on my newly purchased hEX S and a gigabit connection - turns out the lack of IPv6 Fast Track is the culprit.

Adding my +1 to this feature request, as without it I've essentially downgraded when I switched from eero.

Posted: **Tue Jun 21, 2022 3:44 am**

+1 please consider IPv6 FastTrack

Posted: **Tue Jun 21, 2022 11:24 pm**

Coming from Octeon EdgeRouters, lack of IPv6 offloading is a downgrade. +1 for IPv6 fasttrack and L3HW offloading on switch chips that support it.

Posted: **Tue Jun 21, 2022 11:32 pm**

Coming from Octeon EdgeRouters, lack of IPv6 offloading is a downgrade. +1 for IPv6 fasttrack and L3HW offloading on switch chips that support it.

Quite of a few of the switch chips do support IPv6. hAP AC2's AR8327 for instance does. Hopefully we see IPv6 fasttrack make it onto these older units.

I would however settle for new models in similar price points with IPv6 acceleration out of the gate. I'm not that tied to the current models, it's just that getting IPv6 speeds requires dramatically more hardware. Can't sell a customer a 500Mbps internet service with IPv6 enabled on any of the 'CPE' level devices.

Posted: **Wed Jun 22, 2022 12:01 am**

we must not confuse fast-track with offload (HW acceleration) they are different things

Posted: **Wed Jun 22, 2022 12:12 am**

we must not confuse fast-track with offload (HW acceleration) they are different things

The practical differences are just where the packets get identified for hardware accell. ie, does the switch pluck them out and route them (hw accell...) or does the CPU identify what can be run through a hardware path and pass that to the switch (fast-track). In the end, for 99% it's irrelevant.

Posted: **Wed Jun 22, 2022 12:14 am**

we must not confuse fast-track with offload (HW acceleration) they are different things
The practical differences are just where the packets get identified for hardware accell. ie, does the switch pluck them out and route them (hw accell...) or does the CPU identify what can be run through a hardware path and pass that to the switch (fast-track). In the end, for 99% it's irrelevant.

this topic is for fast-track there is another topic for hw-accel

Posted: **Wed Jun 22, 2022 12:48 am**

The practical differences are just where the packets get identified for hardware accell. ie, does the switch pluck them out and route them (hw accell...) or does the CPU identify what can be run through a hardware path and pass that to the switch (fast-track). In the end, for 99% it's irrelevant.
this topic is for fast-track there is another topic for hw-accel

semantics. ipv6 at hw rates of the switch chips by any means. Everyone else get's what the request is.

Posted: **Wed Jun 22, 2022 10:56 am**

Then it is clear that you do not get it!
IPv6 fasttrack is not IPv6 routing at switch speeds!
It is an improvement over the current routing by using a method of shortcut around the many features provided by the router.
Thus certain thinks will not longer work, but packets for existing (tracked) connections can be routed faster.
This has NOTHING TO DO with L3 routing by switch chips, that is an entirely different animal, supported only on a couple of new devices, and restricting the functionality much more than fasttrack does. Most "users of internet at home" will not be able to use L3 accel, but they could use fasttrack.

Posted: **Wed Jun 22, 2022 11:14 am**

Hi,
I heard rumors of my ISP finally beginning to understand that there is a need for supporting IPv6 for private customers. (yes they are horrible and there is severe lack of competition here, they are providing IPv6 already, but until now with severe restrictions)
So +1 for IPv6 fasttrack as I have lots of customer grade MT routers (HAP AC2, HAP AC3, HEX S, WAPac with LTE) on uplinks with several 100s of Mbps, currently running IPv4, but soon to be converted to primarily IPv6.
Ah and I have those routers in two cities with 2 million inhabitants each, so there are probably a few other MT routers to be found there.

Regards
W

Posted: **Wed Jun 22, 2022 6:31 pm**

+1

please consider IPv6 FastTrack

Posted: **Tue Jun 28, 2022 1:29 pm**

+1 for IPv6 Fasttrack!

Posted: **Sat Jul 16, 2022 5:17 pm**

Have you tried adding an IPv6 firewall rule under the "raw" category? This bypasses the connection tracking part of the firewall. Add two rules. First rule should be to match src addresses. Second rule to match dst address. Both rules should have action "no track".

Posted: **Sat Jul 16, 2022 5:56 pm**

Have you tried adding an IPv6 firewall rule under the "raw" category? This bypasses the connection tracking part of the firewall. Add two rules. First rule should be to match src addresses. Second rule to match dst address. Both rules should have action "no track".

i think there is a problem with that approach because raw rule still catch and process all traffic, so it will not give the boost fast-track provides

for example:
ccr1036 8g 2s+ can forward almost 20gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules thanks to fast-track
ccr1036 8g 2s+ can forward almost 10gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules doing heavy Carrier Grade NAT thanks to fast-track

without fast-track you don't achieve half of that

that's the kind of improvement we are talking about

Posted: **Sat Jul 16, 2022 9:34 pm**

The only way to maximize ipv6 throughput on these is to have zero forward rules and no connection tracking. Without any sort of fast-path or hw accell it comes down to touching the packets the least and spending as little CPU time evaluating as possible. This is true of fast-path ipv4 as well really. Do some tests across a mipsbe board with fast track vs no forward rules and no connection tracking. it's a pretty dramatic difference. Not as much as no rules vs passing the firewall chain down but pretty dramatic still. fast-path/track is just minimizing CPU processing but it's still CPU.

I'd really love the whole suite, fast-track/path and hwaccel on supportable hardware for sure.

Posted: **Wed Jul 20, 2022 8:26 pm**

+1 for IPv6 fasttrack and L3HW offloading on switch chips that support it.

Posted: **Fri Jul 22, 2022 4:33 pm**

Add a +1 from me.
Currently the hEX-S is unusable for me with ros7 :/

Posted: **Tue Jul 26, 2022 8:07 pm**

Have you tried adding an IPv6 firewall rule under the "raw" category? This bypasses the connection tracking part of the firewall. Add two rules. First rule should be to match src addresses. Second rule to match dst address. Both rules should have action "no track".

i think there is a problem with that approach because raw rule still catch and process all traffic, so it will not give the boost fast-track provides

for example:
ccr1036 8g 2s+ can forward almost 20gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules thanks to fast-track
ccr1036 8g 2s+ can forward almost 10gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules doing heavy Carrier Grade NAT thanks to fast-track

without fast-track you don't achieve half of that

that's the kind of improvement we are talking about

I agree with you.

However, it will give you extra performance until the feature is implemented. Because you are matching traffic based on the src/dst addresses early on, you are skipping a lot of overhead.

Posted: **Tue Jul 26, 2022 8:34 pm**

i think there is a problem with that approach because raw rule still catch and process all traffic, so it will not give the boost fast-track provides

for example:
ccr1036 8g 2s+ can forward almost 20gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules thanks to fast-track
ccr1036 8g 2s+ can forward almost 10gbps of internet traffic in routing mode with conn-tracking enabled and some ip firewall rules doing heavy Carrier Grade NAT thanks to fast-track

without fast-track you don't achieve half of that

that's the kind of improvement we are talking about
I agree with you.

However, it will give you extra performance until the feature is implemented. Because you are matching traffic based on the src/dst addresses early on, you are skipping a lot of overhead.

how much extra performance you are talking about?

it is still standart track. should be same as no queue and no FW rule

Posted: **Thu Aug 04, 2022 11:02 pm**

+1 for IPv6 Fasttrack

Posted: **Sun Aug 14, 2022 1:57 pm**

up!

definitely need this..

Posted: **Mon Aug 15, 2022 1:57 am**

Australia is rolling out 1Gbps capable technology to all houses now (and over the next few years).

One of the properties I manage is getting it this week, but their hAP ac2 is unable to do 1Gbps routing over IPv6.

We need this.

(and before you ask, every major CDN can transfer data at 800Mbps+ here.)

Posted: **Mon Aug 15, 2022 9:48 am**

You can always buy a faster router. Or live with the situation that you cannot saturate the 1Gbps line. The user won't notice it in normal usage.

Posted: **Mon Aug 15, 2022 11:52 am**

Are we there yet ?

Posted: **Mon Aug 15, 2022 2:27 pm**

nein.

Posted: **Mon Aug 15, 2022 3:15 pm**

You can always buy a faster router. Or live with the situation that you cannot saturate the 1Gbps line. The user won't notice it in normal usage.

Buying a faster router is not a great solution for the power efficiency.
Regarding the users who won´t notice anyhow: "There is no reason for any individual to have a computer in his home." -- Ken Olsen, founder, Digital Equipment Corp., 1977, in a speech to the World Future Society

Posted: **Sat Sep 03, 2022 2:14 am**

This isn't IPv6 fast track but it is a step in the right direction.

This is very exciting...

Can anyone provide more information on this? What switch chips are supported? Does this mean that IPv6 fast-track is being worked on?

Robert

L3HW IPv6 is now supported by all CRS3xx, CRS5xx, and CCR2x16 devices.
IPv6 FastTrack HW Offloading is not implemented because the software IPv6 FastTrack needs to be implemented first. Unfortunately, I don't have information about the latter.

Posted: **Sun Sep 04, 2022 3:59 pm**

+1 please implement this

Posted: **Sun Sep 04, 2022 4:11 pm**

saving money as much as possible is nobility. i disregard "buy more powerful router" advices.

+1 for this feature. please implement it, mikrotik guys.

Posted: **Mon Sep 05, 2022 12:23 pm**

I get l3hw offload is important, and good job on that, but for a lot of hardware without modern switch ships, fast track/path is still a must. I hope we will see this in the next 6 months.

Posted: **Wed Sep 07, 2022 4:53 pm**

+1, would love this

Posted: **Fri Sep 30, 2022 11:30 am**

I have an idea why Mikrotik doesn't care about IPv6:

latvia-ipv6.png

Posted: **Fri Sep 30, 2022 10:14 pm**

Only hardware related to MikroTik, RB750Gr3 in particular, since it was gathering dust unpowered for a long time now, I wanted to try some OpenWrt on it today (SNAPSHOT built 29.09.2022) and here it is:
And no, the "top" screen isn't frozen, that's the actual cpu usage .... none.
WAN type is PPPoE, dual stack IPv6-PD

fast.com ipv6 20220930-0001.png

RB750Gr3 OpenWrt snapshot r20784-ec8fb542ec ipv6 hw_offload.png

Posted: **Sat Oct 01, 2022 12:09 pm**

Maybe the hardware (SoC) has capability to do PPPoE without CPU use?
Do you run a connection-tracking firewall in there? Or is it just transparent?

Posted: **Sat Oct 01, 2022 1:58 pm**

Standard firewall available in current OpenWrt version, they switched to nftables from iptables.
https://docs.kernel.org/networking/nf_flowtable.html
There were some hiccups until now, problems with PPPoE beeing unable to be HW offloaded, IPv6 unstable, but there was a lot of work in OpenWrt regarding this and it all looks/works better now.
Even this got some attention and fix: https://forum.openwrt.org/t/2-gbps-wan- ... ces/131478
It's sad that only the PPE inside some mt76xx devices is currently supported but it's still something

root@OpenWrt:~# grep HW_OFFLOAD /proc/net/nf_conntrack | wc -l
581

That's 581 hardware offloaded flows.
This is how a conntrack entry looks like:

grep HW_OFFLOAD /proc/net/nf_conntrack | grep 2a
ipv6     10 tcp      6 src=2a02:2f0d:xxxx:8806 dst=2a03:b0c0:xxxx:9001 sport=59630 dport=443 packets=8 bytes=1112 src=2a03:b0c0:xxxx:9001 dst=2a02:2f0d:xxxx:8806 sport=443 dport=59630 packets=222 bytes=134837 [HW_OFFLOAD] mark=0 zone=0 use=3
[....]

Posted: **Sun Oct 02, 2022 11:22 am**

That's cool

(But TBF, I don't want to switch to OpenWRT, I like RouterOS)

Posted: **Sun Oct 02, 2022 1:29 pm**

I like RouterOS too, but this RB750Gr3 served well beyond how much I was expecting to use it.
With the bandwidths ISPs are offering here (since a few years now) this device can't keep up while using RouterOS, like I've said above, it was sitting offline gathering dust.
In RouterOS v6 it suffers from the weird port / CPU lane layout bug, in RouterOS v7 performance decreased, IPv6 performance is bad in both versions etc.
I was curious what changed in OpenWrt since I last used it, seems like a lot.
I'll play around with it a little longer and repurpose my RB5009 into a switch + wireguard endpoint + containers, for now. I'm done betatesting it as a router.
Every few ROS7 releases something breaks in DNS or DHCP, it's not like your network depends on those services.
And I don't know if it's just placebo but the network feels snappier somehow, even browsing this forum, which is weird. (altough sniffing with wireshark the forum seems to have IPv6 issues again).

Posted: **Mon Oct 03, 2022 1:26 pm**

+1 for IPv6 FastTrack, it's been a long time coming, seems strange that in 2022 we're still waiting for it.

Posted: **Mon Oct 03, 2022 2:19 pm**

Is the hardware acceleration of IPv6 tracking and PPPoE handling part of the standard Linux kernel, or is that something done internally to the OpenWRT project?
I would think when the standard kernel supports it, it should be available within RouterOS v7 as well.

Posted: **Mon Oct 03, 2022 3:21 pm**

Most of it finds it's way in the kernel, https://patchwork.kernel.org/project/ne ... @nbd.name/
MikroTik won't use something like this, as it's not an universal solution

and they only have so few devices that can benefit from this.

Posted: **Fri Oct 14, 2022 11:01 am**

+1

just started with using Mikrotik routers and I'm really surprised this is still not implemented. Wondering whether going the Mikrotik way does really make sense.

Posted: **Sat Dec 31, 2022 6:31 am**

Only hardware related to MikroTik, RB750Gr3 in particular, since it was gathering dust unpowered for a long time now, I wanted to try some OpenWrt on it today (SNAPSHOT built 29.09.2022) and here it is:
And no, the "top" screen isn't frozen, that's the actual cpu usage .... none.
WAN type is PPPoE, dual stack IPv6-PD
fast.com ipv6 20220930-0001.png
RB750Gr3 OpenWrt snapshot r20784-ec8fb542ec ipv6 hw_offload.png

Interesting... I've checked the MT7621A block diagram; there seems to be a built-in Hw-NAT in the processor itself.

Posted: **Sat Dec 31, 2022 9:46 am**

Yes, that's why it's called hardware offload.

Posted: **Mon Jan 16, 2023 3:36 pm**

+1 fasttrack IPv6

Posted: **Fri Jan 20, 2023 8:20 pm**

7.8beta, still no fastrack for ipv6, come on mikrotik, pleeeaaaase (having say that, you're doing good on multiple fronts with latest releases, congrats).

Posted: **Sat Feb 25, 2023 12:29 am**

No news? I returned a hAP ac2 a year ago and sold a RB750GR3 because it wouldn't go past 200-250 mbps while using ipv6 (I have a 1 gbps connection), and the rest of the devices suffered from the router not being able to provide for them. Every once in a while I look for news regarding this, but... At this point it's probably not worth to waste a few minutes and be left disappointed every time.

I stayed with the router the ISP provided (which achieves full speed with ipv6) but I think it's time to give up on Mikrotik and look for an alternative (willing to listen to viable options, obviously via private message).

Posted: **Sat Feb 25, 2023 8:00 am**

moderator action

Why would you benchmark using such ancient devices in the first place? My CCR1036 can do 20G+ on IPv6 no problem. For home, buy a hAP ax2/ax3 or RB5009UG+S+IN

Posted: **Wed Mar 01, 2023 9:57 am**

moderator action

That's not the point. The point is the gap between fasttrack ipv4 and non-fasttrack ipv6.

Posted: **Mon Mar 06, 2023 12:01 pm**

No, that is incorrect! The packets are checked against firewall rules UNTIL ONE MATCHES.
And as the first rule is usally "accept established/related", the vast majority of packets is only checked against one rule.

Posted: **Fri Apr 14, 2023 7:29 pm**

Any news on this? Is it at least on the roadmap now?

Posted: **Sun Apr 30, 2023 5:28 am**

+1
Would love to see IPv6 Fasttrack on RouterOS v7!
Sadly, my Mikrotik HEX is struggling to reach 280 Mbps over IPv6...

Posted: **Sun Apr 30, 2023 12:08 pm**

+1...

Posted: **Mon May 08, 2023 10:16 pm**

+1 maybe v7.10? v8?

Posted: **Wed May 10, 2023 5:33 pm**

+1 Please

Posted: **Thu Jun 01, 2023 5:32 am**

Maybe some guys should stop waiting and invest on RB5009, or whatever recent device / vendor capable of +1G
I am thinking Mikrotik is moving forward to "detach" true L3HW from (software) fasttrack. That's what happened with IPv6.
Whatever the benefits once provided, fasttrack sounds like a massive kernel hack... which would not be easy to maintain forever for every device/RouterOS release/kernel upgrade

You cannot expect to do 1G++ networking with full features on 10-year old, 50€ devices...

Posted: **Thu Jun 01, 2023 10:23 am**

Yes we can expect.

There are other vendors supporting ipv6 fasttrack

Posted: **Thu Jun 01, 2023 10:36 am**

Other vendors ? fasttrack? are you sure they call it fasttrack?

Posted: **Thu Jun 01, 2023 11:40 am**

I am thinking Mikrotik is moving forward to "detach" true L3HW from (software) fasttrack. That's what happened with IPv6.
Whatever the benefits once provided, fasttrack sounds like a massive kernel hack... which would not be easy to maintain forever for every device/RouterOS release/kernel upgrade

Improving thoughput by SW hacks is very common, it´s always called by different marketing terms, but most big names have something similar like FastTrack.
HW acceleration is not strictly bound to SW accel.
Just look at the open source FD.io, VPP, backed by Cisco:
https://en.wikipedia.org/wiki/Vector_Packet_Processing
Other vendors have other proprietary implementations, like CoreXL, SecureXL,

We want to have power efficency these days, more than ever, so please squeeze out everything from the CPU!
It doesnt matter, how it´s implemented or what is it called.

Posted: **Mon Jun 19, 2023 3:43 pm**

+1 fasttrack IPv6

Posted: **Thu Jul 13, 2023 8:16 pm**

+1 for IPv6 fasttrack on ROS 7

Posted: **Mon Aug 21, 2023 11:43 am**

I wonder if Mikrotik are any closer to delivering IPv6 Fasttrack/Fastpath

Posted: **Mon Aug 21, 2023 11:46 am**

Maybe closer than they were 10 years ago.

Posted: **Mon Aug 21, 2023 1:51 pm**

I hope you guys are right, but there's no indication that they moving in this direction

Posted: **Sun Sep 03, 2023 7:22 am**

+1 Need ipv6 fasttrack.

Posted: **Sun Sep 03, 2023 9:59 am**

+1 for IPv6 FastTrack

Posted: **Mon Sep 25, 2023 1:49 am**

+1 for this feature.

I bought a MikroTip Hap ac² and now after setting up everything to my wishes I did a lot of speed testing to ensure I get my 1 GBit/s fiber connection like before with a router without proper VLAN support.

IPv4 CPU Load is around 15-30% (mixed on all cores) when running at 1 GBit/s - all fine
IPv6 CPU Load is nearly 25% (100% on one core, other cores idle around at 0-4%) when trying to run the 1 GBit/s - I get around 400MBit/s at 1500 MTU and 140MBit/s at 500 MTU size. This is just bad. I can understand, that buy a router with larger CPU is a way to solve it. But in my case I just expected it to work "exactly" like IPv4 speed wise.

Not loaded the ping timings via IPv6 are better on my ISP, so disabling IPv6 on clients when I want speed is kinda sad and not the setup I hoped for when the routing benchmark states nearly 2 GBit/s of performance with all the basic rules.

At least update your benchmark sites to reflect the speed problems with IPv6 routing. https://mikrotik.com/product/hap_ac2#fndtn-testresults

Posted: **Sun Oct 08, 2023 5:53 pm**

+1 for IPv6 fasttrack

Posted: **Tue Oct 17, 2023 2:40 pm**

It would be really nice if Mikrotik would finally start using IPv6 in their offices, their web etc etc.

Now they seem to be very happy with plain vanilla IPv4-only network from 1980s, and all IPv6 functions, even the most basic ones, just escape their staff.

IPv6 really needs its FastTrack, as now I have been forced to throw otherwise useful RBhEX-S devices to poubelle, and replacing those with other vendor devices. And as this is completely useless work, I am sure those customers with 80-140 Mikrotiks each, are not coming back to Mikrotik. I did tell them what the issue is with the poor Mikrotik IPv6 forwarding, and they were equally pissed off that RouterOS so blatantly overlooks the huge requirement for IPv6 usability.

These customers have typically 500Mbps/500Mbps or 1000Mbps/1000Mbps internet connections, few locations have even bigger, of course with better non-Mikrotik hardware, as they do transfer a lot of 8K production quality video left and right. And yes, the sources and targets are IPv6 locations.

I know I can get some 1000 Mbps / 1000 Mbps IPv6 forwarding up, if I just will get a lot bigger router, and sacrifice the whole CPU for just IPv6 forwarding. That is not how real routers work in basic forwarding. Most of these devices have the most basic configuration, and even then, a otherwise nice and proper HEX-S is currently completely useless.

I have seen that Mikrotik does not use or know about IPv6, and within the 24 years I have been using native IPv6, the requirement for IPv6 support has been a lot more than "ooo, I can ping with IPv6!".

What is the current status, plan and prognosis of having even the most basic IPv6 forwarding to use hardware assisted FastTrack (and FastPath)?

Posted: **Tue Oct 17, 2023 5:55 pm**

MikroTik should just adopt XDP with hardware offloading to the NIC for packet filtering. To Adopt DPDK (or its derivatives) for packet forwarding, a lot of MikroTik boxes would be able to forward 100Gbps at near line-rate using CPU alone with XDP + DPDK.

Posted: **Wed Oct 18, 2023 12:57 am**

@DarkNate: Replace XDP by VPP and keep DPDK, please! Or use all of them!

)

VyOs just transitioned from XDP to VPP and many other projects use it, to support >10G speeds.
https://wiki.fd.io/view/VPP/What_is_VPP%3F

Still, something should have already be done by MT about IPv6 performance!

Posted: **Wed Oct 18, 2023 1:22 am**

@DarkNate: Replace XDP by VPP and keep DPDK, please! Or use all of them! )

VyOs just transitioned from XDP to VPP and many other projects use it, to support >10G speeds.
https://wiki.fd.io/view/VPP/What_is_VPP%3F

Still, something should have already be done by MT about IPv6 performance!

DPDK/VPP is designed for packet forwarding, not packet filtering (aka firewall), for packet filtering XDP dominates the market. Just look DDoS scrubbing providers, all are using XDP in the industry for packet filtering.

Posted: **Wed Oct 18, 2023 2:04 am**

It says here there is stateful filtering for VPP:
https://s3-docs.fd.io/vpp/23.10/usecases/acls.html

I don´t know what the general preference is, but what I've experenced is the successor of pfSense: TNSR, which is a damn powerful firewall and it´s based on VPP:
https://www.netgate.com/resources/artic ... rocessingl

Getting a bit offtopic, and honestly I don´t really care which solution wins. Any of those would be great!
Most importantly I want more performance out of the same amount of watts consumed.

Posted: **Wed Oct 18, 2023 6:50 am**

Speaking about VyOs, old ER-4 can forward established TCP IPv6 at line speed (gigabit) with less than 2% CPU utilization. Too bad their os is abandonware.

Posted: **Thu Oct 26, 2023 12:27 pm**

+1, We need this feature. RouterOS ipv6 performance is very poor.

Posted: **Fri Oct 27, 2023 7:46 am**

MikroTik should just adopt XDP with hardware offloading to the NIC for packet filtering. To Adopt DPDK (or its derivatives) for packet forwarding, a lot of MikroTik boxes would be able to forward 100Gbps at near line-rate using CPU alone with XDP + DPDK.

No way. Mikrotik want to sell more Routerboard. If XDP/DPDK is used then x86 is the best choice.

Posted: **Fri Oct 27, 2023 10:06 am**

If XDP/DPDK is used then x86 is the best choice.

XDP does not depend on any special HW: https://www.iovisor.org/technology/xdp
All new routerboards have ARM. (OK, there is maybe something I miss, but most of them have ARM.)
DPDK:

Designed to run on Arm, PowerPC and x86 processors, DPDK runs mostly in Linux userland and supports Windows. It is available for a subset of DPDK features with a FreeBSD port. DPDK is under the Open-Source BSD License.

https://community.arm.com/arm-community ... ion-on-arm
So, MT, please give us any acceleration you can for IPv6 (and by using the previously mentioned stuff also for IPv4...), please!

Posted: **Sat Oct 28, 2023 11:30 am**

If XDP/DPDK is used then x86 is the best choice.

Clearly, you have never spoken with Linux kernel programmers and system programmers to even understand what is XDP or DPDK, and how it is being deployed in the Telecom and data centre industry on all kinds of hardware architectures, ranging from x64 (what the actual f is x86 in 2023?) to arm64 to custom RISC-V to custom ASICs.

Cisco is adopting DPDK/VPP in some product lines, Juniper likely as well under-the-hood but closed source, Nokia already deployed XDP on their products a long time ago, VyOS is doing it with DPDK/VPP. People I know who works in Fortune 1000 companies are deploying XDP/DPDK all over their infra and server nodes on all kinds of CPU architectures, including arm64 boxes running BGP full tables on a damned SBC. AWS is doing their engineering with containers even for eBGP bilateral or PNI peering, not even physical routers, but containers!

But MikroTik:
Let's do 200Mbps IPv6, 1Gbps IPv4.

Top-notch innovation right here.

See this as well:
viewtopic.php?p=1027211#p1027211

Posted: **Sat Oct 28, 2023 11:32 am**

If XDP/DPDK is used then x86 is the best choice.
XDP does not depend on any special HW: https://www.iovisor.org/technology/xdp
All new routerboards have ARM. (OK, there is maybe something I miss, but most of them have ARM.)
DPDK:
Designed to run on Arm, PowerPC and x86 processors, DPDK runs mostly in Linux userland and supports Windows. It is available for a subset of DPDK features with a FreeBSD port. DPDK is under the Open-Source BSD License.
https://community.arm.com/arm-community ... ion-on-arm
So, MT, please give us any acceleration you can for IPv6 (and by using the previously mentioned stuff also for IPv4...), please!

What makes you think MikroTik listens to customer demand from enterprise? They care more about SOHO market like storage features, bring the home/IoT type features etc.

Till date, they don't even support kindergarten-level routing protocol like is-is. When we all know, OSPF doesn't scale as well as is-is does.

Why do I or any enterprise use MikroTik? Because of funding problems, should we resolve funding problems, we're going straight for Nokia or Juniper. Heck, might as well buy an MX204 refurbished for my home lab.

Posted: **Sat Oct 28, 2023 2:12 pm**

[What makes you think MikroTik listens to customer demand from enterprise? They care more about SOHO market like storage features, bring the home/IoT type features etc.

Sorry sir: strictly home user of Mikrotik here! I had my share of enterprise networks, but none of that had anything to do with MT.
I doubt MT cares only about SOHO, MT cares about any market which they can make profits from, as any other profit oriented company.

Till date, they don't even support kindergarten-level routing protocol like is-is. When we all know, OSPF doesn't scale as well as is-is does.

Well, it surely takes some serious efforts to implement that "kindergarten-level" IS-IS (just the ISO standard on ISIS has around 200pages), and they look like to roll their own implementation and they for sure are working on it a lot. Btw. OSPF is good enough to scale to many hundreds of routers. You just have very fast CPUs with lots of RAM nowadays. OSPF is still widely used in enterprises.

Why do I or any enterprise use MikroTik? Because of funding problems, should we resolve funding problems, we're going straight for Nokia or Juniper.

The more you save, the more you profit in many cases. I see also more benefits, like low power, small size, versatility, supported for ages.
I have seen many enterprises giving up on separate, out-of-band management networks, because of the costs of the networking HW.
This use case would be a perfect fit for MT even in big companies!

Heck, might as well buy an MX204 refurbished for my home lab.

I belive that would cost a bit more (maybe 5x?) than a brand new rb5009 and it has something like 650W PSUs, fans, also the weight ? OK you would be well served with it's 400GB routing throughput. (??)
No MT does not compete directly with Juniper.
In smaller scale, it enables deploying faster networks at remote locations and most importantly it has enabled my 10G NAS connection.
But speed (also price, power, size) matters here in SOHO as well, as many places already get >=1G Internet connections for private users.
IPv6 is also important here in SOHO, probably even more than in datacenters.

Posted: **Sat Oct 28, 2023 6:45 pm**

OSPF is a PITA. is-is isn't.

OSPF requires operational and configuration overhead when you have 1000 layer 3 devices in a network, to maintain the configuration automation template etc, across IPv4 and IPv6.

Whereas with is-is, since it's CLNP, I don't need IP addressing whatsoever for underlay network, it can run unnumbered with a single-instance. Minimises operational and configuration expenses.

If OSPF is so great, why is there no Tier 1 carrier using it instead of is-is?

Posted: **Sat Oct 28, 2023 7:40 pm**

If XDP/DPDK is used then x86 is the best choice.
Clearly, you have never spoken with Linux kernel programmers and system programmers to even understand what is XDP or DPDK, and how it is being deployed in the Telecom and data centre industry on all kinds of hardware architectures, ranging from x64 (what the actual f is x86 in 2023?) to arm64 to custom RISC-V to custom ASICs.

Cisco is adopting DPDK/VPP in some product lines, Juniper likely as well under-the-hood but closed source, Nokia already deployed XDP on their products a long time ago, VyOS is doing it with DPDK/VPP. People I know who works in Fortune 1000 companies are deploying XDP/DPDK all over their infra and server nodes on all kinds of CPU architectures, including arm64 boxes running BGP full tables on a damned SBC. AWS is doing their engineering with containers even for eBGP bilateral or PNI peering, not even physical routers, but containers!

But MikroTik:
Let's do 200Mbps IPv6, 1Gbps IPv4.

Top-notch innovation right here.

See this as well:
viewtopic.php?p=1027211#p1027211

I do know that XDP/DPDK not only work for x86.Second hand E5 2699 V4 is only $136.54 in China, And mellanox 25G mcx4121a is only $20.50. If ROS support XDP/DPDK. I will built a X86 machine straightly and not consider any routerboard of fast path support. XDP/DPDK makes routerboard uncompetitive.

Posted: **Sat Oct 28, 2023 9:04 pm**

OSPF is a PITA. is-is isn't.

OSPF requires operational and configuration overhead when you have 1000 layer 3 devices in a network, to maintain the configuration automation template etc, across IPv4 and IPv6.

I did not say, that OSPF is in any way better than ISIS. It is still a fact, that in enterprise networks OSPF is still in use and scaling got much less an issue with as much resources we have today in any router.
So probably current support for routing protocols is no reason for MT to get used more in those networks. And Tier 1 Provider are really no market for MT.

In contrast: low IPv6 performance is very well a reason for not buying MT in SOHO and in Enterprise markets!

Posted: **Sat Oct 28, 2023 9:21 pm**

I did not say, that OSPF is in any way better than ISIS. It is still a fact, that in enterprise networks OSPF is still in use and scaling got much less an issue with as much resources we have today in any router.
So probably current support for routing protocols is no reason for MT to get used more in those networks. And Tier 1 Provider are really no market for MT.

The majority of network engineers disagrees with you:
viewtopic.php?t=30587

Posted: **Sat Oct 28, 2023 11:12 pm**

Hmmm, I did not read every post in that thread, but after a quick look:
THAT thread is about the benefits of ISIS and there the network engineers do discuss benefits of implementing ISIS.
I still never said anything about OSPF being better or ISIS being inferior.

In this thread the goal is to discuss IPv6 support and I believe IPv6 performance is BAD on MT. MT should try to do something about that, before implementing another routing protocol. Especially if they would speed up the whole data plane in the process!
That's my opinion and a 100 network engineers could not beat it out of me.
At least I´d try to run away.

Posted: **Fri Nov 03, 2023 9:06 pm**

Speaking about VyOs, old ER-4 can forward established TCP IPv6 at line speed (gigabit) with less than 2% CPU utilization. Too bad their os is abandonware.

Old ER-4, and even older ER-Lite, were using Cavium SDK (proprietary) to offload established connections to hardware (Octeon SoC).
It isn't pure SW optimization (like MT fast-track, or VPP), and it is not either a true L3HW. Something in between.

The complexity of this implementation was so high that EdgeOS v.2.x took years to reach stable, with a history of long-lasting bugs (packet re-ordering, ipsec, ...), as SoC vendor (cavium) was not willing/able to provide modules for recent linux kernel.

Likely it was one of the reasons they terminated the EdgeRouter line.

I have to agree, as early as 2015 (even before ?), small ER-lite managed to forward 1Gbps (IPv4 + Ipv6) with near-zero CPU usage.

Posted: **Sat Nov 04, 2023 10:58 am**

Of course this (the above) is also a lesson learned by MikroTik, and likely the reason why such things are not incorporated that quickly anymore.
See how it went with the long release delay of RouterOS v7 (updating the heavily patched Linux kernel was a major effort), and what is happening now with Wireless (maintaining the old wireless driver became too much work and now that a standard driver from the manufacturer is used, a lot of functionality is lost).
And MikroTik use many different CPU and SoC architectures and should they implement IPv6 fasttrack only for e.g. CCR20xx the howling here would be even worse than it is now.

Posted: **Mon Nov 06, 2023 12:09 pm**

+1 for IPv6 fasttrack and performance improvements! Thanks

Posted: **Mon Dec 04, 2023 4:33 pm**

+1 for IPv6 Fasttrack

Posted: **Wed Feb 07, 2024 7:11 am**

Posted: **Thu Feb 08, 2024 8:05 pm**

+1, please

Posted: **Fri Feb 09, 2024 1:24 pm**

+1
Absolutely crucial feature!
We needed.
Thanks.

Posted: **Fri Feb 09, 2024 1:32 pm**

+100000000000

Posted: **Tue Mar 05, 2024 3:24 pm**

Please add it!

Posted: **Wed Mar 06, 2024 8:58 am**

Posted: **Wed Mar 06, 2024 10:43 am**

It really takes too long....

Posted: **Sun Mar 17, 2024 12:29 am**

+1. Janis alluded to IPv6 support being added over 8 years ago at MUM EU '16. Even for newer boards with beefier CPUs, knowing the router is doing more work than it has to and drawing more power for IPv6 is frustrating.

Posted: **Sun Apr 21, 2024 11:00 pm**

+1 for this.

The fact that even on a CCR2216, Mikrotik’s own numbers show it only capable of 3M PPS at a 64-byte packet size with 25 ipfilter rules (no fastpath, which is necessary for fasttrack) means that with IPv6 it’s a $2,500+ machine that can’t do full duplex 1Gbps line rate.

This is not acceptable in 2024 when nearly half the world is on IPv6 and there are entire countries that don’t have (or only have limited access to) IPv4.

Edit: I see folks saying by end of 2024 or in 2025 and want to say: Mikrotik has been talking about IPv6 performance improvements for close to a decade. I just wish they would be more honest about what’s stopping them from being able to implement it.

Posted: **Sun May 05, 2024 2:41 pm**

+1 for this~

Posted: **Sun May 05, 2024 3:08 pm**

IPv6 Fasttrack is coming once they work out platform issues ... hopefully before end of this year or spring of 2025 ...

Posted: **Mon May 20, 2024 3:22 am**

IPv6 Fasttrack is coming once they work out platform issues ... hopefully before end of this year or spring of 2025 ...

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.

Posted: **Mon May 20, 2024 3:34 am**

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.

Posted: **Mon May 20, 2024 12:09 pm**

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.

Posted: **Mon May 20, 2024 12:19 pm**

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.

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...

Posted: **Mon May 20, 2024 2:26 pm**

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.

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.

Posted: **Tue May 21, 2024 5:48 am**

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?

Posted: **Wed Jun 19, 2024 10:14 pm**

+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.

Posted: **Mon Jul 01, 2024 3:05 pm**

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?

Posted: **Mon Jul 08, 2024 11:23 pm**

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.

Posted: **Tue Jul 09, 2024 10:53 am**

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.

Posted: **Tue Jul 09, 2024 3:00 pm**

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.

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.

Posted: **Tue Jul 09, 2024 7:43 pm**

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.

Posted: **Tue Jul 09, 2024 8:46 pm**

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:

Posted: **Wed Jul 10, 2024 1:09 am**

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.

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?

Posted: **Fri Jul 12, 2024 3:26 pm**

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.
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 ?

Posted: **Fri Jul 12, 2024 3:31 pm**

MT should look at DPDK in my opinion: https://www.dpdk.org/

Posted: **Fri Jul 12, 2024 4:30 pm**

I would guess that the MKT implementation is maybe too "linked" to the hardware they're using ?

That cannot be! RouterOS is running on a very wide variety of hardware.

Posted: **Fri Jul 12, 2024 8:17 pm**

MT should look at DPDK in my opinion

Two major things make DPDK unsuitable for the current product line:

1. DPDK is a pure userland solution while ROS is kernel-based.
2. 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”.

Posted: **Tue Jul 16, 2024 10:53 am**

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.

Posted: **Wed Aug 07, 2024 3:05 pm**

+1 for fasttrack on IPv6;

On the products info pages would be nice to have IPv6 performance tests.

MikroTik

Feature Request : IPv6 Fasttrack

Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack

Re: Feature Request : IPv6 Fasttrack