Solaris 2.2 defaults to "do not fragment"?

Solaris 2.2 defaults to "do not fragment"?

Post by Mike Jenki » Fri, 25 Mar 1994 08:14:33



I noticed recently when telneting to a Solaris 2.2 host
that things worked for a bit and then the connection
would hang and timeout.  I traced it to the IP packets
coming from the Sun having the "do not fragment" flag
turned on.  This stopped the packets from reaching me
because an MTU along the way was too small for the packet
and the router dropped the packet.  Is this the default?
How do I change it?

  --- from snoop ---
  IP:   Flags = 0x4
  IP:         .1.. .... = do not fragment
  IP:         ..0. .... = last fragment

--
Mike Jenkins

(I must say NetBSD is looking better every day :-)

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by W. Richard Steve » Fri, 25 Mar 1994 09:12:38


Quote:> I noticed recently when telneting to a Solaris 2.2 host
> that things worked for a bit and then the connection
> would hang and timeout.  I traced it to the IP packets
> coming from the Sun having the "do not fragment" flag
> turned on.  This stopped the packets from reaching me
> because an MTU along the way was too small for the packet
> and the router dropped the packet.  Is this the default?
> How do I change it?

It's called "Path MTU Discovery" and is described in RFC 1191.
Solaris 2.x is one of the few systems that implements it today.
Lots of details on it, and examples of it in use are in Sections
11.6, 11.7, 11.8, and 24.2 of my recent book "TCP/IP Illustrated"
(Addison-Wesley, 1994).

To turn it off use ndd(8) and set ip_path_mtu_discovery to 0.
Notice that if the router with the interface with the smaller
MTU dropped your packet it should have also sent an ICMP
unreachable error (fragmentation required and DF bit set),
telling your Solaris host to cut back the segment size.



 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Karl Auerba » Fri, 25 Mar 1994 11:46:33


Quote:>I noticed recently when telneting to a Solaris 2.2 host...
> I traced it to the IP packets
>coming from the Sun having the "do not fragment" flag
>turned on.  This stopped the packets from reaching me
>because an MTU along the way was too small for the packet
>and the router dropped the packet.

Did you notice whether that router was sending back ICMP messages
saying that the destination was unreachable because to get there would
require fragmentation?  Routers are supposed to do that.

What you are probably seeing is the Sun trying to do MTU discovery.

MTU discovery is a good thing; there are too many hosts out there that
are sending unnecessarily small packets (often 512 to 576 bytes) around the
internet.  (And since overhead is often tied to the packet rate, not the
byte count, this hurts everyone.)

But MTU discovery can't work unless the routers follow the rules and tell the
Sun that the packets are too big and that the Sun should ratched
down the packet size.

             --karl--

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Peter Maurice-Jon » Fri, 25 Mar 1994 13:50:29



Quote:

>>I noticed recently when telneting to a Solaris 2.2 host...

>> I traced it to the IP packets
>>coming from the Sun having the "do not fragment" flag
>>turned on.  This stopped the packets from reaching me
>>because an MTU along the way was too small for the packet
>>and the router dropped the packet.

I've noticed the same problem on my SparcCenter2000 running 2.3 on FDDI.
The real pain here is that the 2000 panics and crashes after about
10 minutes of* due to packets not passing through the router.

I know that the router should return ICMP messages (it does not) but
should the 2000 really crash - I don't think so.
Sun have been bluffing about for the past 2 months on this problem
trying to isolate the problem ;)

Quote:>Did you notice whether that router was sending back ICMP messages
>saying that the destination was unreachable because to get there would
>require fragmentation?  Routers are supposed to do that.

>What you are probably seeing is the Sun trying to do MTU discovery.

>MTU discovery is a good thing; there are too many hosts out there that
>are sending unnecessarily small packets (often 512 to 576 bytes) around the
>internet.  (And since overhead is often tied to the packet rate, not the
>byte count, this hurts everyone.)

>But MTU discovery can't work unless the routers follow the rules and tell the
>Sun that the packets are too big and that the Sun should ratched
>down the packet size.

>             --karl--

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Jussi Eloran » Fri, 25 Mar 1994 19:51:05


...stuff removed...
Quote:

>(I must say NetBSD is looking better every day :-)

Try what happens when you run (for example):

main() { while(1) read(99,99); }

compile it and start it (not in background). Then type ctrl-z and try to leave
it in background... at least here it netbsd cuts off all network connections
for 15 mins or so. Even solaris can't do that ;-)

jussi

--
============================================================================
Jussi Eloranta               Dept. of physical chemistry

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Peter Maurice-Jon » Fri, 25 Mar 1994 20:22:10



>> I noticed recently when telneting to a Solaris 2.2 host
>> that things worked for a bit and then the connection
>> would hang and timeout.  I traced it to the IP packets
>> coming from the Sun having the "do not fragment" flag
>> turned on.  This stopped the packets from reaching me
>> because an MTU along the way was too small for the packet
>> and the router dropped the packet.  Is this the default?
>> How do I change it?

>It's called "Path MTU Discovery" and is described in RFC 1191.
>Solaris 2.x is one of the few systems that implements it today.
>Lots of details on it, and examples of it in use are in Sections
>11.6, 11.7, 11.8, and 24.2 of my recent book "TCP/IP Illustrated"
>(Addison-Wesley, 1994).

>To turn it off use ndd(8) and set ip_path_mtu_discovery to 0.
>Notice that if the router with the interface with the smaller
>MTU dropped your packet it should have also sent an ICMP
>unreachable error (fragmentation required and DF bit set),
>telling your Solaris host to cut back the segment size.



Could someone please tell me whether RFC 1191 applies to
bridges as well as routers ???
I have an FDDI/ethernet bridge *NOT* sending back
ICMP messages when the MTU is eccede from FDDI-> ethernet.


 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by W. Richard Steve » Fri, 25 Mar 1994 22:14:18


Just a followup to this discussion on path mtu discovery ...  If you're
interested in seeing what the MTUs are like on the paths you're using,
and whether the routers you deal with can handle this correctly, I have
a hacked up version of traceroute that does path mtu discovery: it sends
the UDP packets with the don't fragment bit set, handles the returned ICMP
unreachables, cuts back the datagram size, and prints the results as it
goes along.  Anon ftp the file /published/books/stevens.tcpipiv1.tar.Z
and compile the file traceroute.pmtu.c that's in there.  Be sure to read
the file README in that directory, as there are some funnies on certain
systems that I've tried it on.

        Rich Stevens

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by W. Richard Steve » Sat, 26 Mar 1994 00:16:50



> Anon ftp the file /published/books/stevens.tcpipiv1.tar.Z
> and compile the file traceroute.pmtu.c that's in there.

I seem to have forgotten to give the host name ... it's ftp.uu.net.

        Rich Stevens

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Dave Johns » Sat, 26 Mar 1994 00:58:57



(quoting from a previous article...)

Quote:>> I noticed recently when telneting to a Solaris 2.2 host
>> that things worked for a bit and then the connection
>> would hang and timeout.  I traced it to the IP packets
>> coming from the Sun having the "do not fragment" flag
>> turned on.  This stopped the packets from reaching me
>> because an MTU along the way was too small for the packet
>> and the router dropped the packet.  Is this the default?
>> How do I change it?

>It's called "Path MTU Discovery" and is described in RFC 1191.

.
.
.
Quote:>To turn it off use ndd(8) and set ip_path_mtu_discovery to 0.

.
.
.

We've been suffering with this problem under Solaris2.3 for
some months now, and contrary to the suggestions by Sun and
others to set ip_path_mtu_discovery to 0, this does not help
a bit.  Only setting the interface to an mtu of 850 will allow
us to ftp large files or receive large email messages from
crimelab.com; this is terribly undesirable.

Perhaps crimelab's ftp machine is also running solaris, and
transfer will continue to fail unless they also turn off
ip_path_mtu_discovery, but I think Sun's code needs to do a
better job of detecting when the packets are getting lost and
fall back to smaller packets or packets without the DF bit.

        Dave Johnson
        Gradient Technologies, Inc.

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by Ken Min » Sat, 26 Mar 1994 10:12:27



> But MTU discovery can't work unless the routers follow the rules and tell the
> Sun that the packets are too big

  I believe that's not exactly correct.  Old-style ICMPs __are__ supported by
  correct PMTU implementations.  In that case, the implementation should
  choose a default MTU and __not__ set DF in future packets (i.e., let the
  router fragment).

  However, I believe that some routers can be configured to __not__ send
  ICMPs (at least some ICMPs).  Certainly, PMTU will fail in that case if the
  originally-chosen MTU is too big.

-- Ken Mintz

 
 
 

Solaris 2.2 defaults to "do not fragment"?

Post by W. Richard Steve » Sun, 27 Mar 1994 06:28:15


Quote:> I've not heard the phrase "Old-style ICMPs" ??

The "old" ICMP Unreachable (fragmentation required) had 16 bits of 0.
Path MTU discovery changes this so that these 16 bits contain the MTU
of the outgoing interface that was larger than the datagram with the
DF bit.  But path MTU does *not* require this "newer" ICMP to work.
If the MTU is there, great, it tells the sender additional information,
but if the bits are 0, path mtu still works.

        Rich Stevens