Hardware Encryption

ciscoben2009 · ‎10-10-2011

Hi All

Hope someone could shed some light on this

I have a cisco 2811 router that is runing a ipsec VPN between two of our offices and is connected to a 10MB line

The problem is it seems the router cant encrypt the data quicker enough for the line speed

with the ipsec on line max out at around 3mb/sec

with out and just the gre tunnel is does the full 10mb

As far as i know this router has a hardware chips for ipsec VPNs it list a VPN card under the show ver

is there something i have got wrong?

thanks

Ben

Leo Laohoo · ‎10-10-2011

As far as i know this router has a hardware chips for ipsec VPNs it list a VPN card under the show ver

Not all. Try the command "sh crypto engine config". Look under "crypto engine type", if you have hardware then it's good. If you have "software" it could either mean that the VPN hardware was turned off or you don't have one.

Is CEF enabled?

Can you post the output for the command "sh interface tunnel"? What is your IOS and feature set?

ciscoben2009 · ‎10-10-2011

Hi Leo

the engine type is hardware and cef is enabled

below is the output

hope that helps

thanks

Ben

Hardware is Tunnel

Description: VPN Tunnel to London

Internet address is 192.168.84.2/24

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 245/255, rxload 231/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 1.1.1.1 (FastEthernet0/0), destination 2.2.2.2

tunnel protocol/transport GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Tunnel TTL 255

Fast tunneling enabled

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 149000 bits/sec, 32 packets/sec

5 minute output rate 49000 bits/sec, 31 packets/sec

110718 packets input, 85718754 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

93037 packets output, 15133848 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

Joseph W. Doherty · ‎10-10-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Is your VPN configuration defined to avoid fragmentation?

ciscoben2009 · ‎10-11-2011

Hi Joseph

I am not sure is there some way i can check?

thanks

Ben

Joseph W. Doherty · ‎10-11-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Review: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Rozsa Illes · ‎10-11-2011

Hi Ben,

Just a note to what Joseph mentioned. You can check if the router is fragmenting/reassembling via the command: show ip traffic.

From the show interface output, we have the default MTU so I would not be surprised if we indeed see some fragmentation or reassembly. We cannot reassemble the packets in CEF so we have to punt them to process switching.

It might be also worth checking if there is any other CPU intensive feature configured on the tunnel (eg. QoS, NBAR).

Warm Regards,

Rose

ciscoben2009 · ‎10-11-2011

Hi Rose

we do have NBAR running but it is not showing as high on the CPU useage but will take it of for now

is there a recommened MTU size for GRE tunnels? if the packet is to large for the MTU is there anyway around it?

thanks

Ben

Rozsa Illes · ‎10-11-2011

Hello Ben,

A quite general MTU value for GRE tunnels is: 1400. You might want to add the tcp adjust-mss value: 1360 though it only affects TCP traffic. These should be configured on both endpoints of the tunnel.

What is important that we fragment the packet before it is encrypted. If we fragment it after encryption, the remote end has to buffer the fragments, reassemble the packets before it could encrypt them and this adds overhead to the CPU. If we set the MTU, we will fragment the packets before they are encrypted so the reassembly does not have to happen on the receiving router.

Warm Regards,

Rose

ciscoben2009 · ‎10-11-2011

Hello Rose

I have set both ends of the tunnel to 1400 using "ip mtu 1400" but has made no difference

the CPU is running at around 77% when coping a file over the tunnel

should i try al ower MTU?

many thanks

Ben

Rozsa Illes · ‎10-11-2011

Hello Ben,

What you do see if you check the show ip traffic (several times during the file transfer and on both sides)? Do you see any fragmens/reassembly? If not, does not make sense to try tuning the MTU more.

But we could check if there is any other feature that might require CPU cycles and we could check what is the average packet size (show cry eng acc stat and show int tun should help here).

Warm Regards,

Rose

ciscoben2009 · ‎10-11-2011

Hello Rose

they are and i am also getting

16:44:45: %IP_VFR-4-FRAG_TABLE_OVERFLOW: FastEthernet0/0: the fragment table has reached its maximum

threshold 16

have had quick google and can up the limit but guess there a problem with the mtu somewhere in the first place that causing the problem?

thanks

Ben

Rozsa Illes · ‎10-11-2011

Hi Ben,

Yes, the router received too many fragments and it could not handle them.

We can try is to ping across the tunnel with the df-bit set. This would help us to determine the maximum MTU on the tunnel itself and see if it is causing the fragmentation. If it is less than 1400, we will need to decrease it further or to find the device which limits the MTU.

Warm Regards,

Rose

ciscoben2009 · ‎10-11-2011

Hi Rose

have done a ping with the MTU of 1400 and the DF set and it went through fine

is the problem when the GRE packet gets encapsulated in the ipsec header it is going over the MTU of the outbound WAN interface?

thanks

Ben

ciscoben2009 · ‎10-11-2011

Would a good test be to try it with the ipsec and not a gre tunnel and see what the throughput is?

thanks

Ben