From owner-freebsd-net@FreeBSD.ORG Fri Mar 31 22:17:44 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D27E16A458 for ; Fri, 31 Mar 2006 22:17:44 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from zig.murex.com (mail.murex.com [194.98.239.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id C874D43D49 for ; Fri, 31 Mar 2006 22:17:43 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from interscan.fr.murex.com (interscan.fr.murex.com [172.21.17.207] (may be forged)) by zig.murex.com with ESMTP id k2VMJgTg016147; Sat, 1 Apr 2006 00:19:42 +0200 (CEST) Received: from mxmail.murex.com (interscan.murex.fr [127.0.0.1]) by interscan.fr.murex.com (8.11.6/8.11.6) with ESMTP id k2VMnMj04695; Sat, 1 Apr 2006 00:49:22 +0200 Received: from [172.21.130.86] ([172.21.130.86]) by mxmail.murex.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 1 Apr 2006 00:17:08 +0200 From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Luigi Rizzo Date: Fri, 31 Mar 2006 17:17:07 -0500 User-Agent: KMail/1.9.1 References: <200603301657.43218.mi+mx@aldan.algebra.com> <20060330140636.A98058@xorpc.icir.org> In-Reply-To: <20060330140636.A98058@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200603311717.07894.mi+mx@aldan.algebra.com> X-OriginalArrivalTime: 31 Mar 2006 22:17:09.0249 (UTC) FILETIME=[DA08DF10:01C65510] Cc: ugen@netvision.net.il, archie@dellroad.org, net@freebsd.org Subject: Re: Is there an API for ipfw? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 22:17:44 -0000 четвер 30 березень 2006 17:06, Luigi Rizzo написав: > If you are doing it a lot more often, you should probably > also consider the effect of such frequent changes to the > pipe's configuration - e.g. pipes respond with a delay > which is inversely proportional to the bandwidth, so in > many cases still doesn't make sense to change the pipe's > rate 100 times per second. So far I'm just playing with the rules manually. I create a pipe with: ipfw pipe 1 config bandwidth 22200KByte/s and send all NFS traffic through it with: ipfw add 100 pipe 1 ip from any to 172.21.128.43 dst-port 2049 This works most of the times, but if sometimes, when I try to change the bandwidth from command line: ipfw pipe 1 config bandwidth 24MByte/s the NFS clients stops writing ALTOGETHER and begins logging complaints about the NFS server (172.21.128.43) not responding. At that point, I must delete the rule 100. The other rules are simply: 65533 allow ip from any to any 65535 deny ip from any to any Why would altering the bandwidth slightly (up) freeze all traffic through the pipe? Thanks! -mi