Re: [TEST/REVIEW] Netflow implementation

From: Andre Oppermann (andre_at_freebsd.org)
Date: 09/09/04

  • Next message: Bjoern A. Zeeb: "Re: [TEST/REVIEW] Netflow implementation" 
    Date: Thu, 09 Sep 2004 19:33:18 +0200
To: Gleb Smirnoff <glebius@freebsd.org>

    Gleb Smirnoff wrote:
    > A> In the README you are talking Netflow 5 and AS path's. I don't undestand
    > A> why
    > A> you want to pass the AS path into the rtentry structure? Wouldn't the
    > A> right-most AS sufficise?
    >
    > AFAIK, Cisco's netflow can be configured in two modes: "peer-as", when a
    > left-most is put into exports, and "orig-as" when a right-most is put.
    > "orig-as" mode is default one, since most interesting statistics
    > can be taken from it. However, "peer-as" is used for billing purposes,
    > when we need to know which peer was transit for this traffic.

    Ok, makes sense now.

    > A> A couple of people from OpenBSD and us are thinking of updating and
    > A> extending
    > A> the routing code and rtsocket framework for things like this most
    > A> importantly
    > A> the interaction between different routing daemons (EGP & IGP). However
    > A> this is
    > A> a more long-term thing and more targeted at FreeBSD 6.0.
    >
    > I'm working on a patch, which will bring AS path support. AS paths are going
    > to be stored separately from rtentries. The latter will have a reference to
    > AS paths. Each AS path is going to have a reference counter in self.

    Ugh, I don't like that at all. The AS path is of variable length and
    the kernel should not know anything about it.

    The only thing the kernel *may* know about is the right- and leftmost AS.
    It may be more efficient to send the netflow data through a small helper
    application that just fills in the two AS number based on a mrt dump.

    > This feature is going to be utilized not only for Netflow, but also
    > in ipfw/dummynet. I think it would be very nice to shape bandwidth or
    > make policy routing decisions using AS path regexes in ipfw rules.

    Ugh. No, better have a way to 'tag' routes and make your decision based
    on those tags. Keep all the policy definition out of the kernel table.
    Additionally you have the tables support in ipfw already. It's far easier
    to extend Quagga/Zebra/etc to properly feed that table than to mangle the
    whole kernel for those purposes.

    > P.S. And we should keep an eye on XORP. It is young now, but is going to
    > be a BSD-licensed alternative to zebra.

    Have a look at OpenBGPd in OpenBSD. Does a lot more, and is useable for
    production networks. 

    -- 
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Bjoern A. Zeeb: "Re: [TEST/REVIEW] Netflow implementation"

    Relevant Pages

    • Re: C++, kernel mode, NDIS
      ... Actually, this does not work, since the compiler will call delete without ... So you always new with the tag and the tag says you must ... other things that should never live in the kernel. ... The C++ side effects could be taken care of by a kernel C++ subset/library, endorsed and thoroughly tested by an entity setting standards in Windows driver development... ...
      (microsoft.public.development.device.drivers)
    • Re: [TEST/REVIEW] Netflow implementation
      ... better have a way to 'tag' routes and make your decision based ... Keep all the policy definition out of the kernel table. ... It is a reference to 'external' information. ... on source/destination prefixes. ...
      (freebsd-net)
    • [patch 11/15] kmsg: convert setup printk messages to kmsg api.
      ... * Tag: setup.1 ... * Severity: Informational ... * The kernel parameter 'noexec' has been specified. ...
      (Linux-Kernel)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... Node code compiles and loads into kernel without any problems. ... After some time experimenting with ng_bpfi was able to tag ... packets matched by bpf filter. ... is not correct as these are new files, not patch:) ...
      (freebsd-net)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... Node code compiles and loads into kernel without any problems. ... After some time experimenting with ng_bpfi was able to tag ... packets matched by bpf filter. ... is not correct as these are new files, not patch:) ...
      (freebsd-current)