Date: Sat, 27 Oct 2001 00:11:45 -0700 (PDT) From: john_wilson100@excite.com To: Matthew Dillon <dillon@apollo.backplane.com> Cc: drais@wow.atlasta.net, freebsd-stable@FreeBSD.ORG Subject: Re: 4.4-STABLE machine unusable (was Re: Openssh) Message-ID: <16946679.1004166720228.JavaMail.imail@pugsly.excite.com>
next in thread | raw e-mail | index | archive | help
On Thu, 25 Oct 2001 20:20:12 -0700 (PDT), Matthew Dillon wrote:
>
> :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.
Right. It turns out that Solaris has a parameter to switch path MTU
discovery on or off ("ndd /dev/ip ip_path_mtu_discovery"). Does FreeBSD
have anything similar?
If MTU discovery fails (and AFAIK, path MTU discovery is optional with IPv4
anyway), then doesn't it make sense not to set the no-frag bit? Why not
let the router fragment those datagrams whose sizes exceed the link MTU?
Why do we need IP fragmentation at all if not to handle cases like this one?
John
> :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
>
_______________________________________________________
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
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?16946679.1004166720228.JavaMail.imail>