Well, I’m not stupid, I know the technical problem. My main concern here is we are no longer in 2010. Almost all EU, China and US ISP provide IPv6 connectivity. In my country (France), we have ISP with IPv6 native backbone and encapsulated IPv4. Mobile networks are even IPv6 only (with NAT64). Google, Netflix, Amazon, CloufFlare, etc… that represent the main part of the traffic are all IPv6. We could almost say that IPv4 is now kept for backward compatibility only.
IPv6 in 2023 is no longer a fancy or optionnal feature. A company that pretend their router can route around 2Gb/s must be able to do it in both IPv4 and IPv6.
So, stop lying in your benchmarks, please mention it’s on IPv4 only, or add an other sheet with the same test in IPv6.
It also says this is an “all port test”. Your number multiplied by 6 possible paths is 2880, for a loss of ~32% over the unidirectional two-port test max. That ain’t bad.
we are no longer in 2010
Sure, but you’re getting upset about a router first released five years ago, and it was a “value” grade router even then. If you want a 2023 badass, go get an RB5009.
No need to show my config, I know the technical issue, which is the lack of fasttrack in IPv6, but this topic is not to complain about the hardware or lack of fastrack in IPv6, but about the throughput annonced on the Mikrotik website.
I turned off the routeur, so I can’t put the export here. But I did a factory reset, removed ether4 and ether5 from the bridge, add the IPv6 address, reconnect through the IPv6 and removed all the remaining configuration. It can’t be more simple:
/ipv6 address add ether4 address=fdc6:5e2d:f8a3:1::1
/ipv6 address add ether5 address=fdc6:5e2d:f8a3:2::1
I don’t know about CCR, but all RB or Hex router will route IPv6 in software/cpu only. So even if I didn’t tested all of them, I can tell you, 100% sure, that all those RB and HEX routers are not capable to route at speed written in the spec.
Again, I’m not upset about the lack of fasttrack in IPv6 on the Hex* or RB*. I’m just telling that the Mikrotik website is lying about the througtput announced.
In 2023, IPv6 is the norm, IPv4 the exception, telling a RB5009, release this year, can route 10Gb/s of traffic is a lie.
Citation needed. Here’s mine, where it’s 59/41% split in IPv4’s favor worldwide, with different tradeoff points depending on where you are in the world. Even in your country (France) it’s 30/70 today according to this data; I have a hard time calling 30% of anything an “exception” case. “Large minority” is a more accurate descriptor.
In any case, the test conditions given on the web site don’t say anything about “IPv4” or “IPv6.” That’s a hidden presumption you’re bringing to the party, without which you cannot get to a charge of “lying.”
I don’t know how true that statement is. I have both fiber and cable based internet here in the Los Angeles metro area, and neither of my ISPs is making IPv6 available.
Using the same source, if you zoom in a lilttle bit, I can tell you that it’s more about 43% (41-45%), not 30%. Reaching 50% is now a matter of months.
But anyway, in 2023, it’s no longer about percentage. 30% or 43% adoption worldwide with a linear increase is enough to say that IPv6 is adopted. The problem is the IPv4 pool is empty. It means you can easily build new business in IPv6 or add IPv6 to an existing IPv4 business. The opposite is false. It’s in that sense that IPv6 is the norm and IPv4 a backward compatibility. We could also talk about CGNAT, NAT64 for ISP side, and services that need to use tier services like cloudflare to be reachable in IPv4.
With this kind of low expectation, I can route 96Gb/s on a 48 port Gigabit cheap L3 switch with icmp redirect and static routes on two hosts in the same subnet… I thought Mikrotik was a serious professionnal network hardware manufacturer, no?
Empty configuration, 2 IP on 2 differents interfaces, as described, it max out at 480Mb/s with 100% CPU on 1 core, not even the quarter of the expected throughtput. And I’m not talking about PPS…
It’s not an hidden presumption that ROS7 doesn’t leverage at all the IPv6 routing acceleration of the MT7621A, or any CPU in any RB or Hex series.
No, they are not.
You should be getting somewhere in the vicinity of 600-700 throughput.
Suspect your PC is not capable of higher than what has been shown because anybody on this planet can achieve the results above.
I am talking downloading/uploading via your ISP, which is a real test.
You are correct, I was going by memory when I first got mine many years ago. Looking at the website it is revamped, only 385 with 25 filter rules so yes 300-450 is more likely. So clearly not lying.
To test a router raw throughput, it’s better doing it from 2 computers directly connected to the router with iperf3 rather than a download/upload through Internet…
Where do you see 385? with 512bytes packet and 25 ip filter rule?
I’m talking about 1500 bytes packets size, without any filter or bridge rulesn which is advertised as 2Gb/s, which is very far from your even 700Mb/s.
And AGAIN, i’m not asking for the Hex S to route IPv6 at wire speed. It never did it and will never do it. It has been replaced by an RB4011 for years now…
The problem is Mikrotik is still advertising their RB* and Hex* routers series throughput with IPv4 only which can be hardware offloaded.
In 2023, where IPv6 IS NO longer an option or a fancy/geeky feature, some websites or services are not accessible in IPv4 today. They should, if there were honnest with their customer, explicitelly tell the throughput test is in IPv4 only, or add the same sheet with an IPv6 test too.
I completely disagree with you. If the goal of those tests was to compare the routers each others, so the test would be done in CPU only.
Better IPv4-only hardware offload doesn’t give any information on anything else performance of others features in the router.
Comparing those information was useful 5 years ago when the main purpose of a router was to route IPv4 only traffic.
Mikrotik publishes results of certain test setup. And that test setup is as relevant to users as your own setup is. They are running same test setup for all devices, hence results can be used to compare devices between each other (but only that). Again, relevance of such comparison may or may not be relevant for your particular use case. There’s even disclaimer about different setups reaching lower results. So assessment of suitabiliry of any particular device model for any particular use case is up to user (but test results may allow user to approximate performance if yet untested device in his particular use case).
So … if you feel better now that you expressed your frustration about using inadequate device (probably because you’re cheap) … go away and stop bothering us who accepted real life limitations of MT devices long ago.
BTW, you may have not said that this particular device doesn’t fit your requirements or needs. But since you started to bitch about test results (which you were unable to replicate with your tests … did you perform them according to RFC2544 like MT did?) one may assume that the performance doesn’t fit your needs. If that’s not it, then this whole thread is even more misplaced.
