From owner-freebsd-hackers Sun Mar 24 16:30:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA06066 for hackers-outgoing; Sun, 24 Mar 1996 16:30:57 -0800 (PST) Received: from cicerone.uunet.ca (cicerone.uunet.ca [142.77.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA06056 for ; Sun, 24 Mar 1996 16:30:54 -0800 (PST) Received: from why ([205.150.249.1]) by cicerone.uunet.ca with SMTP id <10839-4>; Sun, 24 Mar 1996 19:30:50 -0500 Date: Sun, 24 Mar 1996 19:30:34 -0500 From: Andrew Herdman X-Sender: andrew@why To: "Louis A. Mamakos" cc: Brian Tao , FREEBSD-HACKERS-L Subject: Re: Changing Ethernet frame size to 576 bytes? In-Reply-To: <199603240511.AAA20790@wa3ymh.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Actually Brian is having a fragment problem, this is from the IRC server machine which I run the IRC server on: ip: 44034396 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 245769 fragments received 0 fragments dropped (dup or out of space) 1886 fragments dropped after timeout 39671 packets reassembled ok 43571756 packets for this host 256542 packets for unknown/unsupported protocol 0 packets forwarded 0 packets not forwardable 0 redirects sent 40712754 packets sent from this host 816 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 13 output packets discarded due to no route 20314 output datagrams fragmented 91863 fragments created 0 datagrams that can't be fragmented Quite a bit really, perhaps Brian should drop it down to 1006. On my workstation at work I get the following, although not much traffic has occured since the last boot: ip: 281116 total packets received 0 bad header checksums 0 with size smaller than minimum 79 with data size < data length 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 276621 packets for this host 335 packets for unknown/unsupported protocol 0 packets forwarded 4081 packets not forwardable 0 redirects sent 702701 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented Andrew ----------------------------------------------------------------------- On Sun, 24 Mar 1996, Louis A. Mamakos wrote: > > There is much confusion evident in the email message. > > First, the 576 byte packet size mentioned is the *minimum* MTU which > is "required" to be supported. Or something like that. In practice, > most every link level encapsulation in use supports a 1500 byte MTU. > The big exception to this these days is SLIP/PPP where a much smaller > MTU is used to prevent interactive traffic from being "stuck" behind > really large packets and screwing the echo response. > > Second, any fragmentation which would occur would happen in a IP > router, which has an IP datagram it needs to transmit. If the > interface which the packet needs to be forwarded over has an MTU > smaller than the packet, then the fragmentation function occurs at > that point. That is, unless the "don't fragment" bit is set. It's > somewhat likely that it may be set, as the TCP in FreeBSD does MTU > path discovery to "feel" the MTU along the path from the sender to the > recpient's TCP. This is done by setting "Don't Fragment", and looking > for ICMP messages coming back. When the path's MTU is discovered, the > TCP can arrange to not send TCP segments larger than the MTU. > > Third, most long-haul links on the Internet today likely have 4K MTUs, > which is usually used on FDDI and HSSI (to connect to DS3 links) > interfaces. So, it's pretty unlikely that ethernet MTU sizes packets > would be a problem. > > Fourth, you can verify that there's actually dropped fragments > happening by looking on the receiving machine and doing a 'netstat -s' > to look for the number of fragments received, as well as the number > dropped due to reassembly timeouts. I suspect that the number will be > 0. > > I don't think that you actually have a problem, or anything that you > need to change.. > > louie > > > > Anyone know what this guy is saying? I figured fragmentation and > > reassembly would happen between the FTP server's Ethernet interface > > and that of the router to the Internet. Is there any validity to this > > guy's suggestion? >