AES slow when compared to 3DES

I'm using two 2811 routers to create a network to network GRE IPSec VPN using shared keys and esp-3des to encrypt traffic. When I transfer a very large file across the VPN tunnel the transfer takes place at around 40Mbps (the physical connection between the routers is currently a 10/100 switch). I changed the encryption algorithm to esp-aes 128, and the same file now transfers at only 4Mbps. Is this to be expected? I had read that AES was more "computationaly efficient" than 3DES, so naturally I expected it to be faster not 1/10 the speed. By the way, the routers have VPN accelerator cards and an MTU of 1514 is set on the tunnel interfaces. Any ideas?

Reply to
Chris
Loading thread data ...

Post the output of "sh crypto engine configuration'" for both test cases

Reply to
Merv

Post the output of "sh crypto engine configuration'" for both test cases

Reply to
Merv

You're MTU should be 1412... NEVER set it that big... fragmention will happen in the process switched path... not in the cef and fast switched paths. This will eat up router cpu and decrease packet forward abilities regardless of the vpn accelerator. Frags will have to be reassembled by the cpu prior to being decrypted in the accelerator... very nasty.

if you use MTU of 1412 with path discovery (or clear df bit option in global config) you will be okay.

Now, AES is faster than DES with the default crypto accelerator that ships with the non vpn bundle package (AIM EP II).

Are you waiting long enought to calculate accurate results ? are you running into another issue ? (like speed/duplex mismatch on the config during the aes test ?)

Was the only thing you changed the transform set and then you saw the slow speed ?

You should excecute show crypto engine config (as the previous post stated) and see something like this..

------------------ show crypto engine configuration ------------------

crypto engine name: Virtual Private Network (VPN) Module crypto engine type: hardware State: Enabled Location: aim 0 VPN Module in slot: 0 Product Name: AIM-VPN/EPII-PLUS Software Serial #: 55AA Device ID: 001E - revision 0000 Vendor ID: 13A3 Revision No: 0x001E0000 VSK revision: 0 Boot version: 255 DPU version: 0 HSP version: 2.3(22) (ALPHA) Time running: 1w6d Compression: Yes DES: Yes 3 DES: Yes AES CBC: Yes (128,192,256) AES CNTR: No Maximum buffer length: 4096 Maximum DH index: 2000 Maximum SA index: 2000 Maximum Flow index: 4000 Maximum RSA key size: 2048

AES should be supported also in the built in accelerator as well.

Make sure you have this command entered

crypto engine accelerator

perhaps you removed a default command ?

read this doc...

formatting link

Reply to
jbrunner007

Also with respect to encyption perforamnce check out the pre-fragmentation feature:

formatting link

Reply to
Merv

The output of show crypto engine config shows support for AES and looks essentially identical to what you've posted. I changed the MTU of the tunnel interface to 1412 and cleared the df-bit in global config. I was able to ping across the tunnel, but not send large files. The file I am testing with is a 650MB .iso file. I can FTP it across the tunnel with 3DES in 135 Seconds. When I change only the transform set (everything else remains the same) to AES 128 the same transfer takes

1200 Seconds.

I also enabled mtu path discovery but the results were the same -- small packets would traverse the tunnel, but large ones would not.

By the way as you had suspected, when I leave everything as it was (MTU

1514 and don't mess with the df-bit) the processor on the decrypting router is getting hammered.
Reply to
Chris

Merv, I tried the crypto ipsec fragmentation before-encryption. From the reading, I fully expected that combined with the suggestions from jbrunner to work, but no joy. I had the same results -- pinging works fine, but large file transfers just time out.

Reply to
Chris

Hello, Chris! You wrote on 27 Feb 2006 07:16:43 -0800:

C> Merv, C> I tried the crypto ipsec fragmentation before-encryption. From C> the reading, I fully expected that combined with the suggestions C> from jbrunner to work, but no joy. I had the same results -- C> pinging works fine, but large file transfers just time out.

Since you are dealing with TCP based traffic, make sure there is "ip tcp-mss adjust 1300" command configured. You can fine tune number of bytes upward later. Here is URL with details

formatting link
With best regards, Andrey.

Reply to
Andrey Tarasov

Thanks Andrey. ip tcp adjust-mss worked. I started at 1300 and went up to 1339 before I saw the bottleneck again. I read the article you linked. The only thing that I'm a little confused about is the fact that I didn't have to use this command when I was using 3DES, but AES required it. Regardless of that mystery, I appreciate everyones advice.

Thank you Chris

Reply to
Chris

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.