From owner-freebsd-net Tue Jan 16 9:55:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 68D1137B401 for ; Tue, 16 Jan 2001 09:55:13 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.1/8.11.1) id f0GHstB09523; Tue, 16 Jan 2001 09:54:55 -0800 (PST) (envelope-from rizzo) From: Luigi Rizzo Message-Id: <200101161754.f0GHstB09523@iguana.aciri.org> Subject: Re: bandwith limitation In-Reply-To: <20010116194547.A1319@ramses.local> from Clemens Hermann at "Jan 16, 2001 7:45:47 pm" To: haribeau@gmx.de (Clemens Hermann) Date: Tue, 16 Jan 2001 09:54:55 -0800 (PST) Cc: martin@copyleft.no, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > so it is definitely impossible that a packet that passes ipfw (as every > packet does) enters the system even if ipf says "no", right? you have to look at the order of invokation of ipfw and ipfw in the kernel (/sys/netinet/ip_{input,output}.c) to make sure what happens. > I have some additional questions concerning the ipfw approach: > > - is it in general a bad thing to have ipf/ipfw together running on one > machine or ist it just o.k. to have ipf as firewall and IP-accounting > and ipfw for bandwith limitations? it is not bad, though you end up using two different packages and maybe do the classification twice. As far as i can tell the only real advantage of ipf is that you can do NAT in the kernel, for all the rest (including stateful filtering) ipfw is pretty much on par. The classification performance should be essentially the same -- both filters use the same technique for matching. > - is there a performance loss worth mentioning in using both tools > compared to only have ipfw running for all purposes? probably not. see above. > - does the bandwith-limitation that ipfw/dummynet offer tear down the > effective bandwith of my server? that is exactly what you want to do, right ? seriously, the shaper per se has very little cpu overhead (though you have to classify packets, but that is a price you have to pay anyways). Memorywise you need the buffers to store the packets that are delayed -- not a big deal unless you want to do something real unusual. > - does the bandwith-limitation (ipfw) cost a lot of cpu/memory > performance? see above cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message