Date: Thu, 09 Sep 2004 22:11:11 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: net@freebsd.org Subject: Re: [TEST/REVIEW] Netflow implementation Message-ID: <4140B8DF.FB83435C@freebsd.org> References: <20040905121111.GA78276@cell.sick.ru> <4140834C.3000306@freebsd.org> <20040909171018.GA11540@cell.sick.ru> <414093DE.A6DC6E67@freebsd.org> <20040909194117.GB12168@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff wrote: > > On Thu, Sep 09, 2004 at 07:33:18PM +0200, Andre Oppermann wrote: > A> The only thing the kernel *may* know about is the right- and leftmost AS. > A> It may be more efficient to send the netflow data through a small helper > A> application that just fills in the two AS number based on a mrt dump. > A> > A> > This feature is going to be utilized not only for Netflow, but also > A> > in ipfw/dummynet. I think it would be very nice to shape bandwidth or > A> > make policy routing decisions using AS path regexes in ipfw rules. > A> > A> Ugh. No, better have a way to 'tag' routes and make your decision based > A> on those tags. Keep all the policy definition out of the kernel table. > > Isn't reference to extended information a tag? No. The information referenced by the tag (ie. a u_int32_t) is not stored in the kernel. It is a reference to 'external' information. Think of the kqueue API. There you can store a reference to anything in your program within the kevent structure and the kernel will present it to you when get that specific event. > A> Additionally you have the tables support in ipfw already. It's far easier > A> to extend Quagga/Zebra/etc to properly feed that table than to mangle the > A> whole kernel for those purposes. > > That is a good idea, too. If I remeber correctly it was written for exactly the purpose you are referring to. Distinguish between different classes of traffic based on source/destination prefixes. The ipfw tables concept is very powerful in this context. You put the prefixes for which the traffic is for free into one table, the prefixes which are cheap into another and everything else is expensive. The prefix tables are either managed from a live [BGP] feed or updated priodically. They alway err on the side of expesive. ;-) ipfw add 1000 permit ip from [custA] to table [free] out ipfw add 1000 permit ip from [custA] to table [cheap] out ipfw add 1000 permit ip from [custA] to any out This is easily coupled with dummynet too. Just because you have to use Netflow on Cisco IOS doesn't mean you don't have (or can invent) better tools on FreeBSD. > A> > P.S. And we should keep an eye on XORP. It is young now, but is going to > A> > be a BSD-licensed alternative to zebra. > A> > A> Have a look at OpenBGPd in OpenBSD. Does a lot more, and is useable for > A> production networks. > > If it had a nice interaction with OSPF, like zebra does, I'd consider moving > to it. It doesn't interact with OSPF at all at the moment. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4140B8DF.FB83435C>