05-06-2010 12:46 AM - edited 03-04-2019 08:23 AM
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
08-26-2011 02:31 AM
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.
08-27-2011 04:14 PM
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
08-30-2011 02:17 AM
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.
09-23-2011 04:35 AM
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!!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide