My 2.4 IP always sends packets with DONT FRAGMENT

My 2.4 IP always sends packets with DONT FRAGMENT

Post by Paul W. Nelso » Tue, 23 May 1995 04:00:00



I have two 2.4 systems (one SPARC and one X86) and both seem to
always send packets with the DONT FRAGMENT bit set.

Has anyone else had this problem?  I particularly have problems
Apple routers such as my Webster Appletalk/Ethernet router.

I don't recall having done anything to the network I/F configuration.
Can you even configure something like this??

Paul Nelson

 
 
 

My 2.4 IP always sends packets with DONT FRAGMENT

Post by Casper H.S. Dik - Network Security Engine » Wed, 24 May 1995 04:00:00



Quote:>I have two 2.4 systems (one SPARC and one X86) and both seem to
>always send packets with the DONT FRAGMENT bit set.
>Has anyone else had this problem?  I particularly have problems
>Apple routers such as my Webster Appletalk/Ethernet router.

Then those routers are buggy.

Quote:>I don't recall having done anything to the network I/F configuration.
>Can you even configure something like this??

The solaris FAQ says:

5.16) Solaris 2.x can't set up any TCP/IP connections to certain hosts.

    Solaris 2.x sets the don't fragment bit on all packets it send
    as part of MTU path discovery.  The Solaris 2.x implementation
    is RFC compliant, but the MTU path discovery protocol will
    fail when there are broken routers in the path.
    Typical symptom is not being able to connect from a
    Solaris 2.x hosts but having no trouble from other hosts or
    being able to start a TCP/IP connection but not move any
    significant amount of data.

    /usr/sbin/ndd -set /dev/ip ip_path_mtu_discovery 0

    (See also 5.15)

    Please note that Solaris 2.x will still send large packets over
    such links but without the don't fragment bit set.  On a number of
    occasions, I've come accross links that don't properly handle
    such packets.  They're not fragmented, they're dropped instead.

    So if the above fix doesn't work you can resort to the following
    drastic measure which negatively impacts network performance:

    /usr/sbin/ndd -set /dev/tcp tcp_mss_max 536

    536 is the standard packet size that is guaranteed to work by virtue
    of the fact that most system will communicate outside the local
    net with packets that big.  If the connection then starts to work,
    it's time to find the largest value that works.

    It's also worth mentioning that the "ip_path_mtu_discovery" needs
    to be applied at both sides of a connection to fully work, applied
    at one side it will only affect outgoing large packets.  (I.e.,
    downloads from the site will succeed but uploads from a other
    Solaris 2.x machine w/o the workarounf applied may still fail). The
    "tcp_mss_max" workaround need only be applied at one side.

    If you need the "tcp_mss_max" workaround for some sites,
    there a problem on the link between you and those sites.
    Get it fixed.

    --- end of excerpt from the FAQ

Questions marked with a * or + have been changed or added since
the FAQ was last posted

The most recently posted version of the FAQ is available from
ftp.fwi.uva.nl in directory /pub/solaris
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.