Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

IPSEC Encryption Overhead

I'm hoping someone can help me with the maths to reconcile what I've observed on

our routers  on a tunnel interface.  The maximum amount of data I can get across the tunnel is 1339 bytes, which seems just a little bit too small.

Background: we have two 3845 routers with IOS 12.4(3a) advanced ip services.

I have tunnel interfaces on both routers, interface configs are below.

crypto ipsec transform-set MY_TSET esp-3des esp-sha-hmac comp-lzs

crypto ipsec profile MY_VTI
set transform-set MY_TSET

interface Tunnel7
ip address 10.1.40.134 255.255.255.252

tunnel source 10.252.0.14
tunnel destination 10.252.0.18
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile MY_VTI
end


interface Tunnel3
ip address 10.1.40.133 255.255.255.252

tunnel source 10.252.0.18
tunnel destination 10.252.0.14
tunnel mode ipsec ipv4
tunnel path-mtu-discovery
tunnel protection ipsec profile MY_VTI
end

When I test the mtu of the source destination interfaces I get 1500 bytes, as you would expect from an ethernet connection to a service providers MPLS network. See output below.

Router1#ping ip 10.252.0.18 df-bit size 1500

Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
Router1#ping ip 10.252.0.18 df-bit size 1501

Type escape sequence to abort.
Sending 5, 1501-byte ICMP Echos to 10.252.0.18, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)

When I test the mtu of the tunnels I get 1339 bytes, see the output below.

router1#ping ip 10.1.40.133 df-bit size 1340

Type escape sequence to abort.
Sending 5, 1340-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds:
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)

router1#ping ip 10.1.40.133 df-bit size 1339

Type escape sequence to abort.
Sending 5, 1339-byte ICMP Echos to 10.1.40.133, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/31/36 ms

Now when we do the maths on the packet size I get the following

20 bytes    - IP header for ESP packet

8 bytes      - ESP header

8 bytes      - 3-DES IV

20 bytes    - ip header for GRE encapsulation

4 bytes      - GRE header

1339 bytes - original ip/icmp echo  data

5 bytes      - 3DES padding to make it a multiple of 8 bytes (20+4+1339+5)/8 = 171 8byte blocks

2 bytes      -  padding to ensure ESP trailer alignment ends on a 4 byte word

1 byte        - ESP trailer pad length field

1 byte        - ESP trailer next header field

12 bytes    - ESP auth information as per RFC2404

That comes to a total of 1420, which is 80 bytes short of the mtu of the source/destination interface of the tunnel.

Can anyone help explain where things are going wrong, either with my maths or the router config.

Regards

Rob

Everyone's tags (5)
4 REPLIES
New Member

IPSEC Encryption Overhead

Hi Robert,

  Did you ever manage to find a solution to this problem? Iam facing a simmilar issue where the MTU's just don't add up.

Thanks In advance.

Irman.

New Member

IPSEC Encryption Overhead

Hi Irman,

     I am somewhat embarrassed that I forgot to reply back to the forum once we had a workaround. Thanks for giving me the opportunity to rectify that now.

We did eventually get a workaround and Cisco  allocated bug ID CSCth31172 to the problem.  The workaround is  simply to specify  the tunnel source by interface name rather than ip address.

I wrote a more complete description of my findings on my blog at http://networknerd.wordpress.com/2010/06/11/cisco-ipsec-mtu-bug/.

Hope that helps with your problem. The bug seems to effect a large number of IOS versions so I was a bit surprised that nobody had reported it before me.

Regards

Rob

New Member

IPSEC Encryption Overhead

Hi Robert,

  I often forget to reply to forums its just difficult to keep track of problems when they are stretched out over a period of time. But thanks for the information. I will test this out and let you know how i get on.

Regards

Irman Ghaffar.

New Member

IPSEC Encryption Overhead

Hi,

  Apologies for the late response here I have been keeping an eye on the Issue, seems to have been resolved in the latest IOS release, now running Version 15.2(1)GC. Up for > 2 weeks without major issues but it did stop responding at all traffic (including ssh). Would bea little cautious when updating.

Hope this helps!!!

10676
Views
0
Helpful
4
Replies
CreatePlease to create content