[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: James Yonan <jim@xxxxxxxxx>
  • Date: Tue, 25 Oct 2005 10:47:27 -0600 (MDT)

On Mon, 24 Oct 2005, Phillip Vandry wrote:

> 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).

I'd have to say that one of the "breakthroughs" in improving OpenVPN's MTU
handling from 1.x to 2.0 was in acknowledging that IP fragmentation and
PMTU discovery is basically broken on the modern internet, and that the
most-likely-to-work solution is to either (a) avoid fragmentation in the
first place (--mssfix), or (b) fragment internally, so that UDP packets
sent between OpenVPN are never subject to IP fragmentation (--fragment).

IP fragmentation has two major problems:

(1) Fragmentation is inefficient, and makes a terrible impact on latency.
(2) IP Fragmentation depends on the PMTU discovery which in turn depends
on routers and firewalls being properly set up to respond to forward
"fragment needed but DF set" ICMP messages, as well as to forward the IP
fragments themselves.  This is often not the case.

Having said all this, if you are operating in an environment where IP
fragmentation and PMTU discovery are working fine, then you can certainly
configure OpenVPN to use it, and/or configure it not to use --mssfix by 
setting it to 0.


Openvpn-users mailing list