cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11132
Views
0
Helpful
4
Replies
Highlighted
Beginner

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

4 REPLIES 4
Highlighted
Beginner

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.

Highlighted

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

Highlighted

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.

Highlighted

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!!!