Date: Tue, 02 Mar 2004 22:19:20 +0100 From: Andre Oppermann <andre@freebsd.org> To: Bruce M Simpson <bms@spc.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: My planned work on networking stack Message-ID: <4044FA58.87832F22@freebsd.org> References: <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> <20040302042957.GH3841@saboteur.dek.spc.org> <20040302082625.GE22985@cell.sick.ru> <20040302084321.GA21729@xor.obsecurity.org> <20040302085556.GA23734@cell.sick.ru> <20040302092825.GD884@saboteur.dek.spc.org> <20040302095134.GA24078@cell.sick.ru> <40449B8E.A48B39B0@freebsd.org> <20040302160902.GB26977@cell.sick.ru> <20040302193258.GD7115@saboteur.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote: > > On Tue, Mar 02, 2004 at 07:09:02PM +0300, Gleb Smirnoff wrote: > > I do not insist that AS pathes in kernel are good idea. If you show me an > > other way to get AS information when constructing netflow exports in kernel, > > I'd be thankful. I'd be also thankful if you describe how policy routing can be > > implemented while no AS info in kernel. > > What do other FreeBSD networking withards think? > > I don't see any reason why we couldn't accept, for example, a 32-bit cookie > for abuse by a userland daemon, with pid, as it pleases (via an rtmsg > extension and PF_ROUTE). That is generic enough to provide the tie-in > needed with the userland RIB and the kernel FIB. Ugh, I'm happily running my accounting in userland via BPF/PCAP and it adds only 2-3% CPU load. The BGP information I get from MRT routing table dumps. Pretty slick stuff. We (Claudio and me) are preparing it for public release later this week. >From my experience here and a performance point of view there is no need to do netflow and related accounting stuff in the kernel at all. Userland is much more flexible. > ABI breakage may occur, but I would consider that the PF_ROUTE code is in need > of an overhaul anyway (see my mail to ru@ from some months ago on -current or > -net with code able to panic a kernel through malformed rtmsg contents). Please don't break the current RTM5 API. We will design a nice and much more flexible RTM6 message format later this year. It needs a good deal of deep thought and not be rushed just for the sake of it. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4044FA58.87832F22>