The tunnel I made is a regular IPSEC (without L2TP, IP-IP, etc). The behavior is all the more strange because the IPSEC short circuit has incomplete use so theoretically there are resources to handle more traffic.Note that published results are strictly synthetic and achieved with only plain IPsec tunnel configured on the router. For example, connection tracking can significantly reduce the encrypted throughput. Also if you are using L2TP, it creates additional overhead thus bringing the encrypted throughput even lower.
Wojtek, can you please reword this sentence (or say it in Polish and/or use more words, whatever)? I don't understand what "incomplete use" means here.the IPSEC short circuit has incomplete use so theoretically there are resources to handle more traffic.
Ok, but see results with IPSEC off - the traffic spreads to all cores.Looks like you're testing single core performance of a hAP ac2 by single threaded b-test here.In the attachment I am sending screen of devices between which I am doing the test.
I cannot imagine Mikrotik intentionally publishing inflated test results, I can imagine them (like any other vendor) to publish results obtained under ideal conditions (which @Emils has suggested). So I've suggested my real experience. It's not "problems with MTU", it's how fragmentation affects network performance in general. Note that the issue is so significant that IPv6 has changed the rules how fragmentation may be handled.Honestly, I would not look for problems with MTU. More with h2 ac2 performance.
(147.700.000 Mbits/s / 12.170 packets/s) / 8 bits/byte = 1517 bytes/packet, which means that the fragmentation is not the issue here - if it was, the result would be around 800 bytes/packet.In the attachment I am sending screen of devices between which I am doing the test.
That's a good point, however I'd rather expect it to indicate the reverse - a "crypto" interrupt suggests that the CPU is notified about "encryption finished" event by means of that interrupt when the hardware has finished the encryption.I am wondering about IRQ called qca_crypto. As if IPSEC was supported by software and not hardware.
On the left you can see 4011 (both devices work on ARM processors) and there is no such IRQ.
/ip ipsec peer add address=192.168.3.1/32 name=peer_test /ip ipsec profile set [ find default=yes ] dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 /ip ipsec proposal set [ find default=yes ] auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048 /ip pool add name=dhcp_pool0 ranges=192.168.230.2-192.168.230.254 /ip dhcp-server add address-pool=dhcp_pool0 disabled=no interface=ether2 lease-time=1h name=dhcp1 /ip firewall connection tracking set enabled=no /ip address add address=192.168.230.1/24 interface=ether2 network=192.168.230.0 /ip dhcp-client add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=ether5 use-peer-dns=no use-peer-ntp=no /ip dhcp-server network add address=192.168.230.0/24 dns-server=188.8.131.52 gateway=192.168.230.1 /ip ipsec identity add generate-policy=port-strict peer=peer_test secret=EDF#4tG@%4tgf /ip ipsec policy add dst-address=184.108.40.206/32 peer=peer_test sa-dst-address=192.168.3.1 sa-src-address=0.0.0.0 src-address=192.168.230.0/24 tunnel=yes /ip route add distance=1 gateway=192.168.3.1
I've used this information to double-check on your screenshot that the number of bytes and packets is similar on the plaintext (ether2) and encrypted (ether5) side, so I'm officially out of ideas.ehter2 - LAN
ether5 - WAN
These are pretty good numbers for IPsec single client / TCP, I've seen similar performance on RB750Gr3, which is pretty close to hAP ac2 in IPsec perf, in my quick tests.However, even after you have applied the steps you used, the speed is still around 230Mbps.