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.
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.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...