(Message mtu:18) Date: 03 Dec 1997 00:34:53 MST From: Chris Morrell Newsgroups: comp.dcom.sys.cisco Subject: Re: Cannot reach sites with MTU<1500 Approved: news@news.colorado.edu X-Return-Path: dhesi@rahul.net X-Nojunk-Status: OK 0 Organization: UUNET Canada Inc. Sender: daemon@lace.colorado.edu Distribution: world References: Nntp-Posting-Host: lace.colorado.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) X-Note1: message-id generated by recnews X-Note2: mail msgid was <3484686F.41C67EA6@uunet.ca> Xref: samba.rahul.net comp.dcom.sys.cisco:41145 Franck Martin wrote: > > I had this strange problem with a very few sites on the net: I've seen this problem before. It occurs when the destination machine is sitting behind a firewall that is blocking ICMP. I once wrote up a paper on why it was bad to firewall ICMP because it creates this problem but I can't find it right now. Let me try and remember as many details as I can. Most hosts on the net have TCP stacks that have MTU Path Discovery enabled. This is supposed to optimize the TCP conversation so that the packets use the largest packets that they can get through the path to the destination server. The connection is initialized by the source host sending TCP packets to the destination host with the "do not fragment" flag set in the IP header. The sender also tries to use a packet sized as defined by the local interface MTU as a starting point. If somewhere along the path, there is an interface MTU which is smaller than that which can pass along the packet intact, the host to which that interface belongs is supposed to send an ICMP message back to the source saying: "packet too large for MTU" (I can't remember the actual ICMP message type). You can probably see right here where I'm going with this explanation. When the webserver starts to send back data in full packets with the "do not fragment" bit set and your local MTU is too small to handle it, you'll send the nifty ICMP complaint back to the webserver. If the webserver is sitting behind a firewall which is not forwarding ICMP packets, you'll never negotiate your TCP connection. I hope this explanation is somewhat understandable. I'm rather tired. Basically the moral to the story is NEVER, NEVER firewall ALL ICMP. Some ICMP is very necessary. The thing that fixed my problem was to convince the webmaster of said sites to allow these ICMP types as well as change all of my legacy interfaces to an MTU of 1500. Of course there's no way you're going to convince all network operations types to stop firewalling all ICMP, so you're basically out of luck unless you can make a change on your side. Sorry for rambling. I'm tired and hungry. Chris > www.hotmail.com > www.compaq.com > www.ausaid.gov.au > > The connection to my ISP is very slow 9600bps, therefore at these speeds > it is better to put an MTU of 576 for better usage, I set it up on my > CISCO 2500 on the serial port. Unfortunately, I was not able to browse > these particular sites, but I had no problem with 99.9% of the INTERNET > web sites. > > I set the MTU to 1500 and everything went fine. Please note that I did > it at the same time as my ISP did it. > > I wrote to the webmaster of these sites, and so far only one answered me > letting me know that they use a cisco local redirector. > > It seems that these few sites set the don't fragment flag in their > packets, which is highly strange, or is it the cisco local redirector > which has got this behavior? > > If anyone can bring the light on this issue. > > Cheers. > > Franck Martin > Database Development Officer > SOPAC South Pacific Applied Geoscience Commission > Fiji > E-mail: franck@sopac.org.fj > Web site: http://www.sopac.org.fj/