Date: Thu, 25 Oct 2001 20:20:12 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: john_wilson100@excite.com Cc: drais@wow.atlasta.net, freebsd-stable@FreeBSD.ORG Subject: Re: 4.4-STABLE machine unusable (was Re: Openssh) Message-ID: <200110260320.f9Q3KC817332@apollo.backplane.com> References: <1406043.1004062911549.JavaMail.imail@pugsly.excite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Thanks guys, that certainly clears things up for me! : :I just have two questions: : :1) if my Solaris box is similarly firewalled, why doesn't it exhibit the :same behaviour? I realise that their MTU discovery algorithm is probably :very different, but perhaps worth exploring or even adopting (now that :Solaris source is freely available)? Path MTU discovery is a standard, so the implementation should be the same no matter the platform. Unless the solaris box is on exactly the same LAN segment as the FreeBSD box you can't really read anything into it. If the solaris box is not going through the same firewall that the FreeBSD box is going through, then it could be the firewall that is broken. :2) I want to have some proof and find out exactly which router or firewall :is causing this before I go medieval on them. Will I see MTU discovery in :a tcp dump? : :Thanks again, : :John Typically what you see is that the host trying to send a 'large' packet never gets a response back... neither an ack nor an ICMP error. The host will attempt to resend the packet several times and then give up and close the connection. If path MTU discovery is working and a host tries to send a too-large packet, it should get an ICMP error back which will cause it to set a new MTU and resend a smaller packet, which should then go through and get an ACK as expected. If reducing the MTU on the host sending the large packets solves the problem (e.g. reducing the MTU on the server in your case, which is producing the larger volume of output back to you), this is fairly good proof that path MTU discovery is not working as expected. Also note that ethernet switches do not typically return errors for too-large packets, they simply throw them into the bit-bucket. A standard ethernet interface should have an MTU of 1500. If you have gigabit ethernet somewhere in the path and attempting to set a larger MTU in order to make use of jumbo frames then the problem is likely that the gigabit switch or either the client or server does not support jumbo frames, in which case you have to set the MTU back to 1500. Firewalls are quite often misconfigured to block ICMP errors. If any firewall in the path between client and server blocks ICMP errors this will screw up path MTU discovery. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110260320.f9Q3KC817332>