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>