I realise this is a bit like asking "How long is a piece of string", but I'm wondering if anyone has any numbers for the IPSec performance on the _new_ CCR1009's. I'm mostly interested in single-stream performance, as it'll likely have just one or two "fat" L2TP+IPSec tunnels, and I'd like to get each tunnel operating as fast as possible (it will be on a 1Gbit WAN connection)

On the previous model, I read a lot of reports that the RB1100AHx2 actually had better IPSec throughput than the CCR1009 (due to the core count on the CCR1009).

Basically I'm looking to get as many mbit of aes-128-cbc IPSec performance per $. i.e. a CCR1009 is around 17% more expensive than a RB1100AHx2, so I'd be hoping for > 17% IPsec performance.

For what it's worth this will be replacing a RB2011UiAS-RM, so it's not going to be hard to beat the IPSec performance on that model.

Are you aware of the CCR/Tile issues with IPSec hardware acceleration? http://forum.mikrotik.com/viewtopic.php?f=1&t=112545
Afaik, the new units suffer just the same.

No, I hadn't seen that issue. Thanks for the heads up. If this turns into another "Fixed in v7" issue then I won't be holding my breath.

No, I hadn't seen that issue. Thanks for the heads up. If this turns into another "Fixed in v7" issue then I won't be holding my breath.

They claim we are close but who knows. If you end up finding a nice solution that is a CCR form factor/price range and can push ~1Gbit, let us know. Most of us in that thread are in the same boat.

The same for me, I have EOIP/IPSEC tunnel between CCR1009-7G-1C-1S+ hw: 6.41 and CCR1016-12S-1S+ hw: 6.40.1 and on 1Gbps link I get speed results about 200Mbps Shame ;P

Do you run with default settings (aes128-cbc and sha1) or did you select other options (that may be slower or not HW accelerated)?
BTW, the abovementioned "issue with IPsec hardware acceleration" has been fixed.

Do you run with default settings (aes128-cbc and sha1) or did you select other options (that may be slower or not HW accelerated)?
BTW, the abovementioned "issue with IPsec hardware acceleration" has been fixed.

Yes my setting are default aes128-cbc and sha1. I noticed on CCR1009 that one core of CPU is only used during speed test. The link between my routers is going thru infrastructure of ISP - can it affect on it? When I run test without IPSEC encryption the speed is full.

Do you run with default settings (aes128-cbc and sha1) or did you select other options (that may be slower or not HW accelerated)?
BTW, the abovementioned "issue with IPsec hardware acceleration" has been fixed.

Fixed but partially. In my case software enabled IPSEC (AES-256 CTR) still faster comparing hardware enabled (AES-256 CBC). GRE+Ipsec AES-256, sha1/one thread/TCP.

Firmware 6.40.x
Now I'm migrating to 6.41 to check if it become better %))

Do you run with default settings (aes128-cbc and sha1) or did you select other options (that may be slower or not HW accelerated)?
BTW, the abovementioned "issue with IPsec hardware acceleration" has been fixed.

Yes my setting are default aes128-cbc and sha1. I noticed on CCR1009 that one core of CPU is only used during speed test. The link between my routers is going thru infrastructure of ISP - can it affect on it? When I run test without IPSEC encryption the speed is full.

Previously all the cores were used in parallel, but the problem was that individual packets would be encrypted asynchronously by the different cores and would come out in different order than they went into the router.
This in itself is entirely within spec of IP and it should work fine, but in practice a lot of users with Windows applications were complaining that the speed of their TCP connections was very low.
Apparently Windows does not handle this re-ordering correctly. Linux was not affected by this problem, at least not as much as Windows.

So it was fixed, and I think the fix has been to serialize everything for a single connection through a single core. But I don't know what method was used to determine the connection to core mapping, i.e. if it is based on network traffic (e.g. different TCP sessions go to different cores) or if it is only by IPsec policy or even peer.
You can test if you have improved performance when you test with two different TCP connections in parallel. If not, it could be that you have better more performance with two peer systems using the network at the same time. Of course that would not help you when you have only 2 systems that you want to connect together.

In general it can be said that testing performance has to be done carefully. There is often no relation whatsoever between what you measure in a simple "speed test program" and what you achieve when using the router for realistic traffic (many sessions in parallel). This can differ both in positive and in negative sense.

I am currently testing two ccr1009 with 6.42 fw on both the maximum performance achieved IPSec was 450 Mbps on a direct Gigabit link. Only one of the cores is loaded.