Date: Thu, 19 Sep 2002 15:10:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-chat@freebsd.org Subject: Re: FreeBSD NFS server using two NICs Message-ID: <3D8A4B40.67C8E2A2@mindspring.com> References: <3D8A3E52.2090202@centtech.com> <3D8A428B.B96FBE75@mindspring.com> <3D8A458B.2080608@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > > It would help if you gave a URL into the PR database for your > > problem report, if you are going to reference it this way. > > Right you are: > > It's PR# 35151: > http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/35151 Are the clients connectiong via TCP or UDP? There is a common problem with UDP, with clients connecting with a read/write size that is much larger than the MTU (mostly Linux clients), so you end up getting a crud-load of UDP packets sitting in the reassembly buffer for long periods of tiem, without a frag retansmit mechanism other than resending the whole of the data. The correct fixes for this are one of: o Use TCP instead o Drop the read/write size to less than or equal to the amount of data that can be sent in a single MTU. Basically, large UDP datagrams that get broken up are someone wanting the benefits of having a large window, without using a windowed protocol. The long term correction for this would probably be to do IP based RED queueing of requests (plain RED would result in the ability to DOS it with partial UDP requests, and saturation dropping of the reassembly queue would permit you to DOS real data out of the reassembly queue with "two packet, second half" attacks, at the expense of much > 2 packet reassemblies -- a statistical attack, in both cases). Another thing to look at is to do a dump of the raw packets on the wires; it may be that the Sun machine is sending the requests at random, with the multipath, and only accepting responses that come from the "right" place in response, retrying the failed ones forever, or until it gets a response it will accept. A dump of the packets on the wire should tell you if this is happening. This theory fits well with the delayed ramp-up, and the additional delay, if soft updates are disabled. Other than those theories, and what to look for, it's easier to point you back at Matt. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D8A4B40.67C8E2A2>