Date: Tue, 27 Jan 2009 00:44:20 -0600 From: "David DeSimone" <fox@verio.net> To: <freebsd-net@freebsd.org> Subject: Re: MTU or Fragmentation Problems on 7.0? Message-ID: <20090127064419.GC1284@verio.net> In-Reply-To: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com> References: <27cb3ada0901251009x7a96019am672f8bd42380df90@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Len Gross <sandiegobiker@gmail.com> wrote: > > If I change the MTU on 192.168.1.1 to 1450 and the corresponding MTU > on 192.168.1.2 to 1450, then Web Browsing on FreeBSD2 continues to > work, BUT browsing on FreeBSD3 "fails" (mostly.) You are running into a common TCP methodology in use these days, called "Path MTU Discovery." In this process, both endpoints choose to set the "DF" (Don't Fragment) bit on all their TCP packets, and then they expect all routers along the path to send ICMP "network unreachable" packets with code "needs fragment", informing them of what maximum packet size is allowed along the path. Endpoints start out sending full-size frames and then reduce them in size whenever instructed to do so by ICMP messages. The reception of these ICMP messages is crucial to this process working, and if the frames are not received, the whole communication breaks down. > Using tcpdump there is lots of unusual stuff, some relating to > fragmentation ICMP? These are the messages I referred to. Be aware that, just because you see them arriving or leaving via tcpdump, does not mean that they are being received by the host. For instance, a host using PF or IPF or some other firewall would indeed see the frame arrive, but if its ruleset rejects the frame, it will not have a useful effect. > I have tried putting mtu = 1450 using route change on all the routes, > but that didn't help. > Amongst the strangest things is that FreeBSD 2 is unaffected; Firefox > runs fine there That is because, since it has a direct interface with a reduced MTU, it already knows to negotiate a smaller initial MSS with any endpoints out on the internet. Hosts behind BSD2 have to learn the Path MTU via the above Discovery process. In another message you mentioned that you have no firewalls in place, but that hardly seems likely. Everyone runs a firewall at some point, because it is too dangerous to leave your systems unprotected on the internet. I suppose you may be thinking that this is a problem that exists only on your local network, but you must realize that Path MTU Discovery works in both directions, from your systems out to the internet, and from those internet systems back to yours. For instance, if your BSD3 box sends a large packet, the BSD2 "router" realizes that it needs to be fragmented, but the DF-bit prevents this. So BSD2 sends a message to BSD3 that it must use a smaller packet size. If you have no firewalls in place, then this message will surely be received and acted upon. However, when web browsing, the more likely scenario is that the web server you've contacted will be the one trying to send large packets back to you. When those packets reach router BSD1, it realizes that the packet is too big, and sends an ICMP message back to the remote server. Does that ICMP message make it through your outbound filters further upstream? Perhaps. Will that message make it thorugh the firewalls that are surely guarding the remote server? Let's hope so! This is something that is not really under your control, so it's difficult to say. Your best method of troubleshooting this might be to test from a host outside your network to see if the ICMP packets from BSD1 are making it through. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090127064419.GC1284>