Date: Thu, 4 Mar 2004 12:25:30 -0500 From: James <haesu@towardex.com> To: Gleb Smirnoff <glebius@cell.sick.ru>, James <haesu@towardex.com>, Wes Peters <wes@softweyr.com>, Andre Oppermann <andre@freebsd.org>, freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: My planned work on networking stack Message-ID: <20040304172529.GA86502@scylla.towardex.com> In-Reply-To: <20040304131000.GA41474@cell.sick.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> J> why inject as_path info from userland to kernel "fib"? may be netflow turning > J> into an api that quagga can take advantage of to gather accounting information > J> is more feasible? > > James, can you please describe your idea more understandible? I can't understand > your last sentence, sorry. sorry, i wasn't writing clearly :) what i meant is, an implementation of an API for netflow gathering stats from the kernel. once you have that API, perhaps quagga can take advantage of that API, to support netflow accounting by itself, along with as path information and all that.. that was my thought initially, BUT.. actually... you can actually do this no problem using mrtd dumps and pick it up with a program via bgp device :P no need to create another api it seems :) -J -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040304172529.GA86502>