OpenBSD Journal

NetFlow support with pflow(4)

Contributed by jason on from the don't-forget-to-put-the-seat-down-when-you're-done dept.

Henning Brauer (henning@) has just committed a new pseudo-device to OpenBSD-current. The pflow(4) interface exports IP accounting data over UDP that is compatible with NetFlow version 5. Please continue to read Henning's commit message and a brief introduction to pflow(4) usage.

CVSROOT:	/cvs
Module name:	src
Changes by:	henning@cvs.openbsd.org	2008/09/09 07:56:39

Modified files:
	sbin/ifconfig  : ifconfig.c 
	sbin/pfctl     : parse.y pf_print_state.c pfctl_parser.c 
	sys/conf       : files 
	sys/net        : if_types.h pf.c pfvar.h 
	sys/sys        : sockio.h 
Added files:
	share/man/man4 : pflow.4 
	sys/net        : if_pflow.c if_pflow.h 

Log message:
welcome pflow(4), a netflow v5 compatible flow export interface.
flows export data gathered from pf states.
initial implementation by Joerg Goltermann , guidance and many
changes by me. 'put it in' theo

In typical OpenBSD style, this new pseudo-device works seamlessly with the rest of the networking subsystem. It behaves similarly to other virtual networking devices in that you manage it with ifconfig(8) and can even use tcpdump(8) on the interface to monitor flow exports. Setting it up is very simple:

$ sudo ifconfig pflow0 create
$ sudo ifconfig pflow0 flowsrc 10.0.0.200 flowdst 10.0.0.1:1234
$ ifconfig pflow0
pflow0: flags=41 mtu 1464
        pflow: sender: 10.0.0.200 receiver: 10.0.0.1:1234
        groups: pflow

Flows are tracked using the state-tracking capabilities in pf(4). States that are marked with the pflow state-opts keyword will be exported by the pflow interface once the state is expired from the session table. Here is a sample pf filter rule that enables flow accounting for outbound ICMP traffic:

pass out inet proto icmp keep state (pflow)

Once the ruleset is loaded, pfctl(8) will report which states are being tracked for pflow exports:

$ sudo pfctl -vss | grep -B2 pflow | head -3
all tcp 10.0.0.200:38336 -> 38.68.100.209:22       ESTABLISHED:ESTABLISHED
   [3825225521 + 17376] wscale 0  [3569953586 + 16384] wscale 0
   age 00:32:58, expires in 23:59:57, 888:894 pkts, 75601:180313 bytes, pflow

This is a very useful feature for IP accounting and can even be handy for network troubleshooting. It effectively replaces the userland pfflowd daemon (net/pfflowd) created by Damien Miller (djm@), although we would still need a collector to receive the exports. Fortunately, Damien also created flowd (net/flowd), a secure NetFlow collector, and the perfect complement to pflow(4).

As a self-described network geek, I'm thrilled by this new addition to OpenBSD. Joerg Goltermann created the initial implementation of this feature, while Henning refined it for the initial import. I expect additional enhancements to pflow(4) as it stabilizes in the tree from testing and daily use. Although this won't be included with OpenBSD 4.4, buying a pre-order would be a great way to show our appreciation for this type of work!

(Comments are closed)


  1. By Anonymous Coward (89.104.121.248) on

    Long live OpenBSD! (:

    1. By Anonymous Coward (60.53.30.214) on

      Does it support features like to:

      1. check ingress traffic only,
      2. check egress traffic only,
      3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?

      Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)

      -malaysia boleh-

      1. By Anonymous Coward (60.53.30.214) on

        And because it is compatible with NetFlow version 5, is it possible to export it to any netflow collector such as Solarwinds Orion NetFlow Traffic Analyzer, or probably opensource tool like ntop?




        1. By jason (jason) on http://www.dixongroup.net/

          > And because it is compatible with NetFlow version 5, is it possible to 
          > export it to any netflow collector such as Solarwinds Orion NetFlow 
          > Traffic Analyzer, or probably opensource tool like ntop?
          

          Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...

          NetFlow Dashboard

          :)

          1. By Anonymous Coward (81.57.42.108) on

            >
            > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
            >
            > NetFlow Dashboard
            >
            > :)

            Cute!
            Is this Dashboard distributed?

            1. By jason (jason) on http://www.dixongroup.net/

              > >
              > > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
              > >
              > > NetFlow Dashboard
              > >
              > > :)
              >
              > Cute!
              > Is this Dashboard distributed?

              It will be soon. I'm wedging it into the chroot with mod_perl, then will announce it officially with an OpenBSD port/package.

              1. By Terrell Prude' Jr. (151.188.18.46) tprude@cmosnetworks.com (this is a spamtrap address) on http://www.cmosnetworks.com/

                > > >
                > > > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
                > > >
                > > > NetFlow Dashboard
                > > >
                > > > :)
                > >
                > > Cute!
                > > Is this Dashboard distributed?
                >
                > It will be soon. I'm wedging it into the chroot with mod_perl, then will announce it officially with an OpenBSD port/package.

                Will it be available in a traditional tarball as well? We use the Flow-Tools here at work (yes, on Linux, it was pulling teeth to get *that* allowed in our data center). Such a Dashboard would be great.

                --TP

          2. By Loop (203.194.27.78) on

            >
            > And because it is compatible with NetFlow version 5, is it possible to
            > export it to any netflow collector such as Solarwinds Orion NetFlow
            > Traffic Analyzer, or probably opensource tool like ntop?
            >
            >
            > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
            >
            > NetFlow Dashboard
            >
            > :)

            That is dead sexeh!

            WANT!!!!

      2. By jason (jason) on http://www.dixongroup.net/

        > Does it support features like to:
        >
        > 1. check ingress traffic only,
        > 2. check egress traffic only,
        > 3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?

        Sure, just use the "pflow" state-opt keyword only on those filter rules.

        > Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)

        :)

        1. By Anonymous Coward (60.53.30.214) on

          > > Does it support features like to:
          > >
          > > 1. check ingress traffic only,
          > > 2. check egress traffic only,
          > > 3. check traffic at specific interface, example a pf-capable FreeBSD router which have 3 interface, em0 (wan),em1 (lan), em2 (dmz), and only capture em2 traffic (which we're interested due to specific reason)?
          >
          > Sure, just use the "pflow" state-opt keyword only on those filter rules.
          >
          > > Banzai OpenBSD. Just ordering 4.4 via Int Order with 1 t-shirt. ;)
          >
          > :)


          >
          > And because it is compatible with NetFlow version 5, is it possible to
          > export it to any netflow collector such as Solarwinds Orion NetFlow
          > Traffic Analyzer, or probably opensource tool like ntop?
          >
          >
          > Sure, as long as the collector is compatible with NetFlow version 5. I use flowd/Flowd.pm for capturing my traffic with [warning: blatant project plug]...
          >
          > NetFlow Dashboard
          >
          > :)


          Dear Mr Jason,

          Thank you very much for above reply. I'm looking forward for pflow(4) manual to be updated and give it tries in my lab.

          Have a nice day!

          1. By Anonymous Coward (60.53.30.214) on

            Last question, are you the one in this video?

            http://talks.dixongroup.net/nycbsdcon2006/

            It is very nice, funny and interesting video that I've ever seen in BSD world. ;)

            1. By jason (jason) on http://www.dixongroup.net/

              > Last question, are you the one in this video?
              >
              > http://talks.dixongroup.net/nycbsdcon2006/
              >
              > It is very nice, funny and interesting video that I've ever seen in BSD world. ;)

              Guilty as charged. :)

        2. By Anonymous Coward (83.88.170.104) on

          > Sure, just use the "pflow" state-opt keyword only on those filter rules.

          I often miss an alternative to "pass ..." and "block..." that doesn't change whether the packet will pass or not. It wold be also usefull for adding tags, logging and queueing.

          Off cause there would be no flow if the packet ended up being blocked.

          Maybee a "match" keyword. I know it would simplify my rulesets.

          1. By henning (130.237.95.167) on

            > > Sure, just use the "pflow" state-opt keyword only on those filter rules.
            >
            > I often miss an alternative to "pass ..." and "block..." that doesn't change whether the packet will pass or not. It wold be also usefull for adding tags, logging and queueing.
            >
            > Off cause there would be no flow if the packet ended up being blocked.
            >
            > Maybee a "match" keyword. I know it would simplify my rulesets.

            that (with exactly that keyword) is on my virtual todo list for ages. 4 years at least. over time my idea on how it is supposed to work got clearer, and be warned: it is entirely nonobvious. well, ok, if you just do match it is easy, but to be really useful you have to think about when what applies. for example, logging only happens on the last matching rule, so a "match log" doesn't help you.

  2. By Anonymous Coward (24.84.63.46) on

    How is this better than the pfflowd util? Cramming more into the kernel is not a good idea.

    1. By jason (jason) on http://www.dixongroup.net/

      > How is this better than the pfflowd util? Cramming more into the kernel is not a good idea.

      First, it has full access to the PF state table. Since it only needs information about state deletion, it doesn't have all the overhead that pfflowd has (listening to all state updates). In addition, there are other things planned that will probably require access to the PF internals, but I'm just guessing.

      Just because it *can* be done in userland doesn't always mean it must. I think this is a good use of in-kernel functionality. CARP *could* have been done in userland, but nobody is complaining about having that in the kernel. ;)

      1. By mpf@ (88.217.158.50) on

        > > How is this better than the pfflowd util? Cramming more into the kernel is not a good idea.
        >
        > First, it has full access to the PF state table. Since it only needs
        > information about state deletion, it doesn't have all the overhead that
        > pfflowd has (listening to all state updates).

        Actually, if you start pfflowd with a pcap filter like: "link[2]==0x03",
        the kernel will only pass it state deletions (via pfsync).

      2. By Frank DENIS (82.224.188.215) on http://00f.net

        > Just because it *can* be done in userland doesn't always mean it must. I think this is a good use of in-kernel functionality. CARP *could* have been done in userland, but nobody is complaining about having that in the kernel. ;)


        Actually some people use the userland version of CARP even on OpenBSD, because they need a custom setup (specific scripts to be spawned when ownership is taken, etc).

        1. By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on

          > > Just because it *can* be done in userland doesn't always mean it must. I think this is a good use of in-kernel functionality. CARP *could* have been done in userland, but nobody is complaining about having that in the kernel. ;)
          >
          >
          > Actually some people use the userland version of CARP even on OpenBSD, because they need a custom setup (specific scripts to be spawned when ownership is taken, etc).

          You can have scripts spawned without needing UCARP.

  3. By Wouter (2001:888:1b6b:b0e::6965:6b73) on

    Wasn't Netflow patented?

    1. By jason (jason) on http://www.dixongroup.net/

      > Wasn't Netflow patented?

      [IANAL] I believe that refers to sampled NetFlow, which this isn't.

      1. By ldso (208.5.80.104) ldso@sourceforge.net on http://marmot.dudeabides.net

        > > Wasn't Netflow patented?
        >
        > [IANAL] I believe that refers to sampled NetFlow, which this isn't.

        I would like to hear more about this. So Ciscos and Junipers that we get flows from are sampled. But this isn't, because it shoots out flow data for every connection via pf? I'm interested in what kind of load it puts on various hardware. We are currently using the classic FreeBSD flow-tools solution.

        But the fact that it is not sampled doesn't matter I guess, as long as your tools are net-flow v5 capable? I wonder how flow-tools might cope with this, as well as how well our Intel 1U boxes would perform.

        Very cool work, good job :) I'll have to play with this when I get back from vacay.

  4. By ates (78.25.11.204) ates@ipv6.dp.ua on

    WOW! It's very greate news! OpenBSD best! Thank a lot!

  5. By coward1 (81.169.155.246) on

    Could kernel recognize traffic streams not only by port but also by application features, then do QoS and/or netflow export? .i.e layer 7 aware?

  6. By joe (98.97.67.6) on

    crud. i was hoping to see this in 4.4!

    :(

  7. By Anonymous Coward (130.237.95.124) on

    The p must flow.

  8. By Jessicaparker (38.103.14.140) on

    Are any of these netflow analyzers able to be used with P flow? list of netflow analyzers i dont see any mention in this and nothing is mentioned in this article either: netflow openbsd guide thx

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]