[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] MTU, link-mtu and tun-mtu

  • Subject: Re: [Openvpn-users] MTU, link-mtu and tun-mtu
  • From: Phillip Vandry <vandry@xxxxxxxxx>
  • Date: Mon, 24 Oct 2005 16:17:29 -0400

On Mon, Oct 24, 2005 at 01:16:44PM -0600, James Yonan wrote:
> --link-mtu refers to maximum UDP payload size and doesn't include the IP 
> or UDP header.

Ah, that explains it perfectly. Thank you.

> A lot of experience gained during the OpenVPN 1.x releases showed that 
> it's best to fix the tunnel MTU at 1500 and vary the other parameters (and 
> use --mssfix to prevent fragmentation rather than a lower tunnel MTU).

I won't argue with this experience gained, but I disagree with this
practice. TCP MSS munging should be used as a last resort, mostly for
hacking around servers behind broken firewalls that block necesary ICMP
messages for path MTU discovery. The main reason why it is not a good
solution is, of course, that it is for TCP only. Since we are working
at the IP level, IP fragmentation should be the mechanism used to deal
with packets that are too large to fit in the tunnel. That will catch
all packets from all IP protocols. In particular, if a frame must be
fragmented before entering the tunnel thanks to an apropriately reduced
MTU on the tunnel interface, properly working path MTU discovery will deal
with this and the sender will begin originating smaller frames. If the
tunnel MTU is not reduced so that the packets with the tunnel overhead
on them fit on the path between the tunnel peers, then they will have
to be themselves fragmented at the IP level somewhere along the way but
this will be invisible to the tunnelled applications, so they cannot
react to it. Generally this will double the number of packets the tunnel
passes whenever the MSS adjustment hack does not apply (UDP, etc..),
much like using the --fragment option.

By the way, if you leave the MTU "too big" anyway and let tunnel carrier
packets get fragmented, that argues for making even larger than 1500
on medium to high speed links (transmission time for a 1500 byte packet
on a 30 Mbps link is less than half a millisecond).