On Thu, May 22, 2008 at 8:54 AM, John Smith <snafu_101@xxxxxxxxxxx> wrote: > > > > > > Linux 2.6.17 & Linux 2.6.20 > > I encountered a problem recently with a server that raised my awareness of Path MTU Discovery. > > The > server was sending HTTP replies where the DNF flag bit of the IP > packets was set. A downstream server/router returned an ICMP packet > "Fragmentation Required MTU=1300". Initially the firewall was blocking > this ICMP message and the transaction failed since all the outbound > packets> 1300 were dropped. Opening up the firewall to pass the > ICMP packets back to the server resulted in no difference in behavior > and the transactions still failed. This is a well known issue (RFC 2923), and was the motivation for the development of MTU probing (RFC 4821), enabled with tcp_mtu_probing. > Experimentation on another > Linux system showed a similar behavior. Just guessing I turned on > 'tcp_mtu_probing'. This seemed to result in the 'correct' behavior of > the TCP stream. Once it received the ICMP message from downstream it > reduced the packet length to < the MTU. However it seemed to default > to a 562 byte MTU and not the 1300 as requested. It seems likely that this system in fact is not getting the ICMP. MTU probing is robust to failure of ICMP delivery, but may use a sub-optimal MTU (in this case 562) when this occurs. > Another > experiment was to just turn ON 'ip_no_pmtu_disc'. This resulted in > outbound packets without the DNF flag set and the transactions worked > ok. > > On both systems I checked tcp_mtu_probing was ON and > ip_no_pmtu_disc was OFF by default. It appears that in this case TCP > doesn't work correctly over the WAN? Now I'm confused. Usually tcp_mtu_probing is off by default, and you just said it worked when you turned it on. > In the interest of safety I > turned ON 'ip_no_pmtu_disc' on the web server. I believe this just > makes it work in the 'old fashioned' Internet way allowing routers to > fragment the packets on the fly. This should work for you, but there are good reasons why this is not the best idea. See: http://www.ecse.rpi.edu/Homepages/shivkuma/teaching/sp2001/readings/ccr-9501-mogulf1.pdf and RFC 4963. > Is this a real problem with the Linux network stack or am I just doing something wrong? I would try doing a tcpdump on the sender to verify that the ICMP is getting delivered, if you haven't done that. Good luck, -John -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
