Date: Wed, 03 Mar 2004 11:20:17 +0300 From: Vladimir Grebenschikov <vova@express.ru> To: Bruce M Simpson <bms@spc.org> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: My planned work on networking stack Message-ID: <1078302016.6838.46.camel@localhost> In-Reply-To: <20040302193258.GD7115@saboteur.dek.spc.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
On =D7=D4, 2004-03-02 at 19:32 +0000, 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 m= e an > > other way to get AS information when constructing netflow exports in ke= rnel, > > I'd be thankful. I'd be also thankful if you describe how policy routin= g can be > > implemented while no AS info in kernel. > > What do other FreeBSD networking withards think? >=20 > I don't see any reason why we couldn't accept, for example, a 32-bit cook= ie > 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. This possible solution when you run accounting, but if you are going to do policy-routing, you need to get routing decision based on additional route information, and in this case you need keep this additional data in kerenl. But I agree with you that rtentry is bad place for that information. > 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 -curren= t or > -net with code able to panic a kernel through malformed rtmsg contents). We need ability to link rtentry records with custom kernel data handled by extension modules (such as cisco-like accounting or policy-routing) > BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1078302016.6838.46.camel>