auth-algorithms=sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m pfs-group=modp2048
Did various test with IPSEC + GRE and EoIP. Will check soon IPIP.
the results are more or less there on the attached screenshot, does it seem right ?
Including the history was tested on windows using jperf 2.0.2.
First (source lan from windows copy) - Second (copy destination win box)
(correction for the second CPU , there was divided during the screenshot, for the most part was concentrated on one core)
RB1100AHx2 from 5 years ago can do 500mbps+ on a TCP single stream on one EoIP+IPSEC tunnel. 700mbps with multiple TCP streams. Should the CCR not be faster?
With bonding after?
How is it implemented ? With IPSEC from same interfaces and diffrent IPs ?
In paralel ? Multi subnet ipsec on/from the same interface and then EoIP or GRE?
After that bonding the two resulting interfacfes using bonding (balance rr)?
I tried it with´out success, maybe I am doing it wrong .. The second IPSEC has issues for “phase 2”..
Do you have code example for multi stream ipsec config?
Regards.
P.S. Two EoIP on the same IPSEC are doing the same bandwith like one. I am hitting the “rule of tomb 1 ipsec per core”.
One must also ask: Source Media and Destination Media 20Mbyte per second (200Mbit) is about what your average 2" spinning harddrive does after all buffers have been depleted. Allways test network with memory transfers so you test the real performance.
Update: CCR1009-7G should have all ports accelerated !! Is this info for all CCR1009 or just the CCR1009-8G ?!?!?!?!
VPN:
4 IPSEC (IP1,IP2,IP3,IP4 each on they own subnet)
4 EoIP On each of the end point (Clamp TCP MSS + Fast Path)
1x BONDING balance RR
Routed the IP1 subnet to the BONDING.
the result is almost same as previous ones, I tried even to change the MTU, it got worse:
The traffic is windows copy:
Jperf, two TCP streams in both directions:
CPU, during jperf:
I even disabled EoIP 2 and 4, there was NO change. The throughput was just balanced on the remaining two EoIP tunnels.
To conclude this Odyssey, if you need encryption, take another better product. If you need basic routing/firewall go for this product family, but if you need encryption with tunnels you are in bad luck. This is not one of the accelerated aes puppies, even multi treading benefits on this arhitekture is questionable. This is all old software single tread limit.
I am happy that I had 3 of this to make a test lab, to go beyond the mikrotik brochure and marketing and make conclusion on my own. In the future I will use heavily the return policy, if I want to hurt my self some more. Will not hold to promise’s of the “will be fixed in the next RC” type. For the peace of mind even the pfsense development and no warranty doesn’t sound bad after this 3+ years and counting of beta testing for this specific feature. If that’s the norm, the refund policy of your products should be changed to 4 years !