Hi everyone.

I'm using IPv6 with 750/750 Mbps Internet connection and IPv6 provided by my ISP on a hEX S. My WAN is being connected using a SFP ONT and I notice a very weird behavior in my speed tests.

If I disable IPv6 and do the speed tests, I can get very close to my nominal speeds, however, as soon as I enable IPv6 to my clients, my speed plummets to half of what I get using IPv4.

Checking the CPU usage, I can see CPU0 and CPU1 averaging 96 and 65 % while CPU2 and CPU3 are 2% on Download. During upload I can see CPU1 at 96% and CPU0 at 65% with the speeds around 300 Mbps in both Upload and Download.

While using IPv4, I can see a more uniform usage in the CPU Cores with CPU0 at 80%, CPU1 a 40%, CPU2 at 40% and CPU3 at 18% on upload test and CPU0 at 80% and the rest of the cores around 9% in the Download test. In both cases I'm able to get close to my ISP speed.

My IPv6 firewall rules are simple with 14 rules:

Is some one getting a similar behavior with beta4 on other devices as well or this is a hardware limitation?

Thank you!

ROS has a feature called fast-track. It decreases processing overhead for select packets, if configuration and traffic mix is right, more than 99% of packets qualify. This feature thus increases capacity of a device.

In ROS v6 (currently stable and long-term versions) unfortunately it doesn't exist for IPv6. Same for ROS v7 so far.

ROS has a feature called fast-track. It decreases processing overhead for select packets, if configuration and traffic mix is right, more than 99% of packets qualify. This feature thus increases capacity of a device.

In ROS v6 (currently stable and long-term versions) unfortunately it doesn't exist for IPv6. Same for ROS v7 so far.

Hi mkx.

Thank you for the explanation. I've read some related things previously about the lack of FastTrack for IPv6. Just wanted to be sure if this was not a known issue from v7.1beta4.

Would be possible to brute-force this limitation with a more powerful hardware? For example a RB3011UiAS-RM or RB4011iGS+RM ? Or are there inferior hardwares that could provide up to 1 Gbps routing with Firewall rules for IPv6 ?

Thank you!

ROS has a feature called fast-track. It decreases processing overhead for select packets, if configuration and traffic mix is right, more than 99% of packets qualify. This feature thus increases capacity of a device.

In ROS v6 (currently stable and long-term versions) unfortunately it doesn't exist for IPv6. Same for ROS v7 so far.

Hi mkx.

Thank you for the explanation. I've read some related things previously about the lack of FastTrack for IPv6. Just wanted to be sure if this was not a known issue from v7.1beta4.

Would be possible to brute-force this limitation with a more powerful hardware? For example a RB3011UiAS-RM or RB4011iGS+RM ? Or are there inferior hardwares that could provide up to 1 Gbps routing with Firewall rules for IPv6 ?

Thank you!

Yes, of course. A more powerful router with a more powerful CPU won't have a problem with IPv6. For example, I use a CCR1016 and have no problems. Note that you won't be able to FastTrack traffic anyway if you're using certain features, so a more powerful CPU is always good. I don't use FastTrack in my configuration.

See more here: https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

You don't need a CCR to get decent IPv6 speeds. What I typically do is go to the MikroTik "Test Results" tab for a certain device and look at the "25 ip filter rules", "512 byte" "Mbps" speed. This is a reasonable estimate of the real world performance you can get from the device without fasttrack.

I have recently tested 7.1beta4 on my main router (RB4011) with a 6to4-tunnel but cannot reach speeds over 100 Mbps. There are a lock of dup acks and icmpv6 packet too big messages cluttering up the interface.

Not sure if this is related to IPv6 in general or the 6to4 tunnel, but you may want to check out v6 before buying another device.

(RB4011 ROSv6 6to4 reaches up to 600 to 800Mbps)

I'd say this is related to tunnels ... any type (6to4, PPPoE, ...) because tunnel overhead reduces effective MTU through tunnel and it becomes lower than native MTU on end devices. Which then necessiates fragmentation etc.

Which then necessiates fragmentation etc.

normally you will use TCP-MSS clamping. with IPv6 your systems will use PMTUD. If the source node does not perform PMTU discovery, it must send packets no larger than the minimum IPv6 MTU size of 1,280 bytes. there's no fragmentation in the network with IPv6, so intermediate nodes (routers, firewalls, packet forwarding devices) cannot change what they receive. they either forward it (if it fits in the outgoing if's MTU) or drop it (if it is too big) and send an ICMPv6 unreachable packet to big message.

with 6to4 you might encounter fragmentation, but it is done at IPv4 level, _after_ your v6 packet is already wrapped into IPv4. normally this shouldn't happen as tunnel MTU is automatically calculated, but things can get indeed funky. encapsulations using IPv4 as transport (GRE, IPencap, L2TP, SSTP) can essentially screw up PMTUD on IPv6, and make the source believe, there's enough MTU in the entire path, if tunnel MTU is set incorrectly. but this is generally a bad practice. as i described, it will result an IPv4 packet which is bigger than the outgoing IF MTU, and this one can be fragmented. and as you correctly stated, fragmentation is a CPU intensive task and essentially lowers forwarding speed.

more here:
https://packetpushers.net/ipv6-and-the- ... g-message/

You don't need a CCR to get decent IPv6 speeds. What I typically do is go to the MikroTik "Test Results" tab for a certain device and look at the "25 ip filter rules", "512 byte" "Mbps" speed. This is a reasonable estimate of the real world performance you can get from the device without fasttrack.

in general properly structured IPv6 forward filter rules (accept for established/related connections) can speed up things, as there's no filter rules to travel and evaluate, before the packet is admitted for forwarding. so it should be better than the one with 25 FW rules.
estimating throughput in bps is kinda tricky. you have your forwarding speed (measured in PPS) as one of the main limiters. then there's the bandwidth available on the interface or in generally in the forwarding path. but that's just there to make sure you don't think you can push 1.5Gbps over a GE link :-)

but PPS can be totally ok to estimate the throughput. just take the MTU size you expect, multiply them, and multiply the result by 8 to get bits, and boom, there it is. it will be a lot more accurate and flexible way to estimate what your setup would be able to deliver. usually you should get an IMIX-is value for packet size, we are around 950 byte in our network (375226310000 bps @ 48353390 pps)

In general parsing the IPv6 header will take at least twice as much time that parsing the IPv4 header, due to its size, regardless how it's done. (40 bytes vs 20 bytes)
this fact on its own inherently lowers IPv6 forwarding speed to 1/2 of the IPv4, so roughly 1/2 of the PPS. (but not the BPS :-)

in general properly structured IPv6 forward filter rules (accept for established/related connections) can speed up things, as there's no filter rules to travel and evaluate, before the packet is admitted for forwarding. so it should be better than the one with 25 FW rules.

Yes, but in my experience, the 25 IP filter rules 512 byte benchmark is a rather good indicator of the performance the average "power" user can realistically expect out of the device (not a regular user applying the default config and leaving it alone). I am not suggesting that 25 IP filter rules will always be used. However, when someone asks me what MikroTik device to buy, I look at that benchmark to determine the optimal device. Most people buying MikroTik devices (rather than cheaper TP-Link/D-Link/etc.) are not wanting to simply load the default configuration and leave it alone, they want to tinker with it and do more advanced things. Regardless of what advanced things the user wants to do with the device, I usually find that the 25 IP filter rules, 512 byte benchmark is pretty close to what they will get in that "tinkered" environment (unless they are overdoing it).