From owner-freebsd-net@FreeBSD.ORG Mon Feb 14 13:26:09 2005 Return-Path: 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 7FAB616A4CE for ; Mon, 14 Feb 2005 13:26:09 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB3C443D46 for ; Mon, 14 Feb 2005 13:26:06 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D0gEm-0001J6-00; Mon, 14 Feb 2005 14:26:04 +0100 Received: from [84.128.141.74] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1D0gEl-0006rZ-00; Mon, 14 Feb 2005 14:26:03 +0100 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 14 Feb 2005 14:25:53 +0100 User-Agent: KMail/1.7.2 References: <16911.51264.86063.604597@canoe.dclg.ca> <16912.11613.216501.589279@canoe.dclg.ca> <20050214094353.GX82324@obiwan.tataz.chchile.org> In-Reply-To: <20050214094353.GX82324@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1483631.nVka8C0Pax"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502141426.01067.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Jeremie Le Hen cc: David Gilbert Subject: Re: altq for vlans? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 13:26:09 -0000 --nextPart1483631.nVka8C0Pax Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 14 February 2005 10:43, Jeremie Le Hen wrote: > > Anyways, the _real_ problem is that traditionally, I'd used firewall > > rules for accounting as well as security. To that end, labels are > > very cool. However, they have one rather large defect: > > > > If you're dealing with keep state rules, there seems to be no obvious > > way to account for incoming vs. outgoing traffic. The label only > > reports total traffic for the state matching the rule... which is both > > in and out. > > This is a workaround, but I found that ipfw's count rules are pretty > useful for this purpose. This would however add processing overhead > for each packet especially using gigabit Ethernet. Did you try to use tables? I think it's one of the best tools for easy=20 accounting. $pfctl -vvT show -t test 192.168.0.1 Cleared: Mon Feb 14 14:19:39 2005 In/Block: [ Packets: 0 Bytes: 0 = ] In/Pass: [ Packets: 2 Bytes: 168 = ] Out/Block: [ Packets: 0 Bytes: 0 = ] Out/Pass: [ Packets: 2 Bytes: 168 = ] It does count everything on stateful rules and it's easy to monitor subnets= =20 and whatnot. See the various manual pages and the OpenBSD FAQ for more abo= ut=20 tables. You might also want to have a look at pfflowd from ports, which is= =20 able to translate pfsync messages into flows for accounting purposes. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1483631.nVka8C0Pax Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCEKboXyyEoT62BG0RAtWoAJ9OJNvv7B51jcdZrY2glS8OHsuQmACfQ1EL TOOcX6N2znncsgg5GpXdKII= =Ecbd -----END PGP SIGNATURE----- --nextPart1483631.nVka8C0Pax--