|
|
On Tue, Oct 25, 2005 at 10:47:27AM -0600, James Yonan wrote: > 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 That's one way if seeing it. Unfortunately for the Internet, I'll grant you that it's a correct way of seeing enough of the time to justify your approach :-( > IP fragmentation has two major problems: > > (1) Fragmentation is inefficient, and makes a terrible impact on latency. But when the tunnel carrier packets are fragmented (as will happen most of the time for MTU 1500 tunnels with large, non TCP packets like UDP) it's just as bad. --fragment would also experience that issue to some extent. > (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. True. So here's another way to look at that. For packets that are going to be fragmented anyway, (e.g. large UDP where MSS rewriting cannot help) arranging for the packets to be fragmented on tunnel entry by having the tun0 MTU set low enough will actually be better because the carrier packets will then not need to be fragmented "out there" on the Internet somewhere on the tunnel path where there may be all manner of misconfigured routers and firewalls over which the VPN administrator has no control, but instead on the intranet (most likely on the OpenVPN peer machine itself, in fact) where the OpenVPN user at least has the ability to correct problems. See the following paragraph. I would also add that fragmentation can be buggy. I recently worked with Cisco over a period of several months nailing down an IP fragmentation bug on some of their 12000 router linecards. -Phil |