fprobe man page

User documentation
03/07/2012

NAME

fprobe - a NetFlow probe

SYNOPSIS

fprobe [ options ] remote:port[/[local][/type]] ...

DESCRIPTION

fprobe - libpcap-based tool that collect network traffic data and emit
it as NetFlow flows towards the specified collector.

OPTIONS

  • -h
    Display short help
  • -p
    Don't put the interface into promiscuous mode. Note that even if
    this option is used, the interface might be in promiscuous mode for
    some other reason.
  • i <interface>
    Listen on interface. If unspecified, fprobe will use result
    of pcap_lookupdev() function. On Linux systems with 2.2 or later
    kernels, an interface argument of `any' can be used to
    capture packets from all interfaces. Note that captures on the
    `any' device will not be done in promiscuous mode.
    You may use `-' as interface name to process files produced
    by tcpdump with -w flag. fprobe will read data from
    stdin.
  • -f <expression>
    Filter expression selects which packets will be captured. If no
    expression is given, all packets on the net will be captured.
    Otherwise, only packets for which expression is `true' will be
    captured.
    fprobe use silly IP-packet detection method, so it is bad idea to
    leave the filter empty. For general use `ip' (-fip) is good filter
    expression.
    Read tcpdump manual for detailed expression syntax.
  • -s <seconds>
    How often scan for expired flows. [default=5]
  • -g <seconds>
    Fragmented flow lifetime. [default=30]
  • -d <seconds>
    Idle flow lifetime (inactive timer). [default=60]
  • -e <seconds>
    Active flow lifetime (active timer). [default=300]
  • -n <version>
    NetFlow version for use (1, 5, 7). [default=5]
  • -a <address>
    Use address as source for NetFlow flow.
  • -x <inputID>[:<outputID>]
    Workaround for SNMP interfaces indexes. [default=0]
    The second parameter may be omitted - in this case its value will be
    equal to the first.
    See BUGS section.
  • -b <flows>
    Memory bulk size. [default=200 or 10000]
    Note that maximum and default values depends on compiling options (
    --with-membulk
    parameter).
  • -m <kilobytes>
    Memory limit for flows cache (0=no limit). [default=0]
  • -q <flows>
    Pending queue length. [default=100]
    Each captured packet at first puts into special buffer called `pending
    queue'. Purpose of this buffer is to separate most time-critical packet
    capture thread from other.
  • -B <kilobytes>
    Kernel capture buffer size (0=don't change). [default=0]
    Increase kernel capture buffer size is most adequate way to prevent
    packets loss. Unfortunately, at present there is no straight way to set
    the buffer size throught libpcap, so this option is a hack. Moreover,
    now this hack take effect only on socket()-based capture mechanisms: it
    mean that it work on Linux and don't work on BSD systems with their
    bpf().
    Note that maximum allowed size of the buffer in Linux limited and
    generally relatively small, so it should need to change the maximum:
    sysctl -w net/core/rmem_max=4194304
  • -r <priority>
    Real-time priority (0=disabled). [default=0]
    If parameter greater then zero fprobe will use real-time
    scheduling policy to prevent packets loss. Note that possible values
    for this option depends on operating system.
  • -t <B:N>
    Emitting rate limit (0:0=no limit). [default=0:0]
    Produce N nanosecond delay after each B bytes sent. This
    option may be useful with slow interfaces and slow collectors. Note
    that the suspension time may be longer than requested because the
    argument value is rounded up to an integer multiple of the sleep
    resolution (it depends on operating system and hardware) or because of
    the scheduling of other activity by the system.
    See BUGS section.
  • -S <bytes>
    Snaplen (0=whole packet). [default=256]
    Number of bytes to capture from packet on wire.
  • -K <bytes>
    Link layer header size. By default fprobe take this information
    from libpcap, but sometimes obtained size unsuitable for our purpose.
    It occurs, for example, on trunk interfaces in VLAN enviroment, where
    link layer header contain additional VLAN header.
    See EXAMPLES section.
  • -k
    Don't exclude link layer header from packet size. By default
    fprobe counts only IP-part of packet.
  • -c <directory>
    Directory to chroot to.
  • -u <user>
    User to run as.
  • -v <level>
    Maximum displayed log level. (0=EMERG, 1=ALERT, 2=CRIT, 3=ERR,
    4=WARNING, 5=NOTICE, 6=INFO, 7=DEBUG) [default=6]
  • -l <[dst][:id]>
    Log destination (0=none, 1=syslog, 2=stdout, 3=both) and log/pidfile
    identifier. [default=1]
    This option allows to select opportune log destination and process
    identifier. The identifier helps to distinguish pidfile and logs of one
    fprobe process from other.
    Note that if log destination contains `_stdout_' (equal 2 or 3)
    fprobe will run in foreground.
  • remote:port/local/type
    Parameters remote and port are respectively define address
    and port of the NetFlow collector.
    The local parameter allows binding certain local IP address with
    specified collector. If the parameter is omitted the value (if any) of
    -a option will be used.
    The type parameter determines emitting behavior. It may be `m'
    for mirroring (by default) and `r' for collectors round-robin rotating.
    You may specify multiple collectors.

EXAMPLES

Web traffic trivial capturing:
fprobe -ippp0 -f"tcp&&port 80" localhost:2055

Capturing from trunk interface:
fprobe -ieth0 -f"vlan&&ip" -K18 localhost:2055

Reasonable configuration to run under heavy load:
fprobe -fip -B4096 -r2 -q10000 -t10000:10000000 localhost:2055

Send packets to collector at 10.1.1.1:2055 and distribute them between
collectors at 10.1.1.2:2055 and at 10.1.1.3:2055 on a round-robin basis:

fprobe 10.1.1.1:2055 10.1.1.2:2055//r 10.1.1.3:2055//r

BUGS

SNMP interfaces indexes and packet direction.
Unfortunately libpcap don't provide any routing-related information about
captured packet, therefore there are no straight ways to determine and
distinguish input and output interfaces. However -x option at least
can tell that flow was passed through the certain interface. Also you may
launch several instances of the program with tricky set of filters to mark
out each possible packet direction:
fprobe -x1:2 -ieth1 -f"ip&&dst net 10.2" localhost:2055
fprobe -x2:1 -ieth2 -f"ip&&dst net 10.1" localhost:2055

Slow interfaces and slow collectors.
There are may be problems with slow interfaces and slow collectors. It
effects as emitted packets loss. On the one hand silent non-blocking
sendto() implementation can't guarantee that packet was really sent to
collector - it may be dropped by kernel due to outgoing buffer shortage
(slow interface's problem) and on the other hand packet may be dropped on
collector's machine due the similar reason - incoming buffer shortage (slow
collector's problem).
Use -t option as workaround for this issue.

SEE ALSO**

tcpdump pcap(3)
http://www.cisco.com/go/netflow

Files