Date: Sat, 18 Dec 1999 17:19:28 -0500 (EST) From: Jim Flowers <jflowers@ezo.net> To: freebsd-questions@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Natd with Pmtu Discovery Message-ID: <Pine.BSI.3.91.991218171411.16787A-100000@lily.ezo.net>
next in thread | raw e-mail | index | archive | help
Natd does not handle pmtu discovery well when the mtu for the interface it is using is changed, either manually or under program control, after natd is started. The following provides details of why, and a work-around. Problem ------- Gateway router with natd has erratic or poor TCP performance when the outbound (nat) interface is modified after startup or during startup subsequent to launcing natd from rc.network such as from scripts in /usr/local/etc/rc.d or /etc/rc.local. Analysis -------- 1. Natd learns the mtu value of its interface on startup from rc.network following ifconfig or DHCP initialization. 2. Skip startup from a startup script in /usr/local/etc/rc.d/skip.sh modifies the mtu value in the kernel interface structure. 3. On receiving a packet to transmit outbound, natd generates an icmp type 3 need-to-fragment packet back to the sending host using the value learned in paragraph 1. 4. The sending host retransmits using this size. The packet is still too large for the outbound interface to transmit. 5. If the sending host happens to be a WinNT with pmtu discovery enabled, paragraphs 3 and 4 are repeated until black hole discovery takes over, if enabled, or forever, if not enabled. The -dynamic flag does not cause natd to learn the new value when the interface mtu is modified. While this problem was discovered in gateways that use both skip and natd on the same interface, it has been confirmed that the problem exists any time the natd interface mtu is modified, either manually or during startup after the natd daemon has been started. Workaround ---------- This behavior can be avoided for the current autostart requirement by delaying the startup of natd until after the interface mtu is set by skip from skip.sh (such as placing the equivalent shell script line in /etc/rc.local). The program name, option flags and interface name will have to be given explicitly as these values from rc.conf are not available in rc.local. Correction ---------- The natd program should learn the modified value of the interface mtu before transmitting need-to-fragment messages. As this method of avoiding fragmentation is becoming more common (and is mandatory in IPV6) this would be a worthwhile modification. Wierd Note ---------- The problem does not appear to occur in 3 gateways that are bit-identical except that they are running unstripped binaries (identical, if stripped) of natd. Jim Flowers <jflowers@ezo.net> #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.91.991218171411.16787A-100000>