fprobe − a NetFlow probe
fprobe [options] remote:port[/[local][/type]] ...
fprobe − libpcap-based tool that collect network traffic data and emit it as NetFlow flows towards the specified collector.
-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.
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
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.
tcpdump
pcap(3)
http://www.cisco.com/go/netflow