Hello,
My suggestion:
Please add performance results for IPsec tunnel (AES) to “Performance test results” table on each product page.
Interested the maximum speed of a single tunnel.
As I see, you added “IPsec test results” for some products, like this https://mikrotik.com/product/CCR1009-7G-1C-1Splus
Some questions:
- how many threads were used in Single tunnel?
- it’s TCP or UDP throughput?
- why you publish results only for products with hardware ipsec?
It is stateless traffic, so you could say it is UDP. There is no use of testing devices without hardware acceleration, because their performance difference between models is insignificant.
>>It is stateless traffic, so you could say it is UDP.
Please add result for “Single tunnel TCP single thread”. Its very useful info, for example as file copying.
>>There is no use of testing devices without hardware acceleration, because their performance difference between models is insignificant.
RB3011UiAS-RM should be much faster than RB2011UiAS-RM.
I tested two 750G r3 (6.39.3), connected via EoIP tunnel with IPsec.
Windows file copy test show only 33 MB/s (264 Mbps). This is very far from declared 477 Mbps https://mikrotik.com/product/RB750Gr3.
Maybe you add also results for some popular tunnels+ipsec (l2tp+ipsec, gre+ipsec, eoip+ipsec)?
Maybe EoIP is responsible for that. Can you check without EoIP ?
I think it is still a good result for such device.
Windows file copy is highly dependent on latency. Even a 2ms latency will make a huge difference. Did you test on local network, or through the internet? Also, fragmentation should be avoided.
I tested in 1Gbit LAN
Well, so network wasn’t the problem. I can’t test this, since I don’t have two units on gigabit. What profile said? Was the CPU running at 100%? What was the process using most CPU?
hex_eoip_ipsec.png
Ok. So, your problem isn’t exactly IPsec - it is using 0,5% of your CPU power. Ho is your firewall? What are the rules? Maybe there is something there in need of optimization…
I have no experience with EOIP, so I don’t know how much CPU it uses.
Firewall is blank
These two Hex is direct connected and used as encrypted wire in LAN
No rule whatsoever? Not a single one? Not even the default ones? If this is true, You are not using fasttrack.
Do you have this rule on Your firewall? If not, then add it and test again.
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
You do not understand. Its “L2 wire” only. No L3 forward.
It can’t be L2 only if they are doing IPsec.
IPsec use “input” and “output” chain, not “forward”.
Traffic inside the IPsec tunnel still crosses the forward chain.
https://wiki.mikrotik.com/wiki/Manual:Packet_Flow#Changes_in_RouterOS_v6
And You have “networking” using about 100% on 2 cores. I’d look at fasttrack. Another possibility is fragmentation: it should be avoided, as it is a CPU hog.
Just occurred to me: You said the traffic was about 260 Mb/s. It was just download? The figure of ~450Mbps IPsec is adding up and down. The crypto engine doesn’t care which way the packets are flowing. You can have 225/225, 350/100, 200/250… Whatever adds to 450Mbps. And this is with 1400 bytes packets. With smaller ones the number will be worse.
You can find information here how the tests has been done: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#HEXv3_.28mmips.29_Config_Optimizations
And here is some generic article, might be useful: https://wiki.mikrotik.com/wiki/Manual:Performance_Testing_with_Traffic_Generator
Paternot
>>Traffic inside the IPsec tunnel still crosses the forward chain
No
eoip_ipsec.png
>>Just occurred to me: You said the traffic was about 260 Mb/s. It was just download?
Its unidirectional file copy (download or upload)
didomir
>>You can find information here how the tests has been done: https://wiki.mikrotik.com/wiki/Manual:I … imizations
This is synthetic UDP test.
True “real life” test its TCP single connection, as i suggested.