I read in a Cisco white paper that an MTU reduction "complies with best practices in VPN networks of setting the MTU to 1440 bytes on an interface to allow for IPSEC headers."
Sounds straightforward enough. Here's my confusion, though...
Say I have a VPN tunnel between two campuses in different states. Tests show that one site can get to the web without fragmenting at 1472 (MTU 1500, with the IP header). But getting to the other VPN site, they fragment anything larger than 1406 (MTU 1434, with the IP header). See ping results below.
Q1. If I follow the logic correctly, I should set the MTU on both sides to 1434, right? Why is that different than the 1440 recommendation from Cisco?
Q2. Does something happen inside the IP protocol to inform the PC and RDP/Terminal Services server about this, so they don't keep trying to send 1500 byte packets? Or does that part not matter? If not, why not?
Q3. It seems like we'd want to stop fragmentation across the entire network. Do I need to set MTU in DHCP as well? Why would I want to optimize and prevent fragmentation at the tunnel endpoints, rather that at the source, at the PC and switch? Seems like it would suck to have to live with the lowest common denominator speed for the Internet, just because of a slower VPN tunnel for some traffic.
Q4. What about all the other switches and routers I control, other than those two ASA endpoints for the VPN tunnel, do I have to change the MTU in all of them also?
Q5. To make matters worse, I did a fragmentation test across the MPLS link to our data center (not using VPN tunnel), and it fragmented above 1272. So do I need to tweak everything here and there down to 1272?
Q6. And the last question, does it even matter? I brought this issue up with a local Cisco support contractor a few years ago, and he shrugged it off like I was speaking a foreign language to him. Apparently he'd never made any MTU changes based on fragmentation.
C:\>ping www.google.com -f -l 1472
Pinging www.google.com [74.125.22.106] with 1472 bytes of data:
Reply from 74.125.22.106: bytes=64 (sent 1472) time=50ms TTL=36
Reply from 74.125.22.106: bytes=64 (sent 1472) time=51ms TTL=36
Reply from 74.125.22.106: bytes=64 (sent 1472) time=51ms TTL=36
Reply from 74.125.22.106: bytes=64 (sent 1472) time=189ms TTL=36
Ping statistics for 74.125.22.106:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 50ms, Maximum = 189ms, Average = 85ms
C:\>ping 192.168.1.1 -f -l 1472
Pinging 192.168.1.1 with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 192.168.1.1 -f -l 1407
Pinging 192.168.1.1 with 1407 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 192.168.1.1 -f -l 1406
Pinging 192.168.1.1 with 1406 bytes of data:
Reply from 192.168.1.1: bytes=1406 time=95ms TTL=127
Reply from 192.168.1.1: bytes=1406 time=85ms TTL=127
Reply from 192.168.1.1: bytes=1406 time=75ms TTL=127
Reply from 192.168.1.1: bytes=1406 time=91ms TTL=127
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 75ms, Maximum = 95ms, Average = 86ms
