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