From owner-freebsd-net@FreeBSD.ORG Fri Mar 5 06:22:23 2004 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 5A3B916A4CF for ; Fri, 5 Mar 2004 06:22:23 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF0C43D45 for ; Fri, 5 Mar 2004 06:22:22 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 93242 invoked from network); 5 Mar 2004 14:22:20 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 5 Mar 2004 14:22:20 -0000 Message-ID: <40488D18.89A72F34@freebsd.org> Date: Fri, 05 Mar 2004 15:22:16 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> <20040302042957.GH3841@saboteur.dek.spc.org> <20040302082625.GE22985@cell.sick.ru> <20040303181034.GA58284@scylla.towardex.com> <20040304131000.GA41474@cell.sick.ru> <20040304172529.GA86502@scylla.towardex.com> <20040304172651.GA86659@scylla.towardex.com> <20040305140602.GB49148@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: James Subject: Re: My planned work on networking stack 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: Fri, 05 Mar 2004 14:22:23 -0000 Gleb Smirnoff wrote: > > On Thu, Mar 04, 2004 at 12:26:51PM -0500, James wrote: > J> > that was my thought initially, BUT.. actually... you can > J> > actually do this no problem using mrtd dumps and pick it up with a > J> > program via bgp device :P no need to create another api it seems :) > J> > J> errr??? I meant bpf device... > > Implementing traffic accounting like ip accounting or netflow through > a bpf is generally a bad idea, because of poor performance of such a solution. This is not the case. While common wisdom does indeed suggest that BPF is slow it is in fact not the case. We have a netflow-like per AS-number traffic accounting daemon which takes only 2-3% of the CPU on our core routers. We are currently preparing that software package for public release. -- Andre