nProbe
An Extensible NetFlow v5/v9/IPFIX GPL Probe for IPv4/v6
In commercial environments, NetFlow is probably the de-facto standard for network traffic accounting. ntop includes both a NetFlow v5/v9/IPFIX probe and collector that can be used to play with NetFlow flows. This means that you can use ntop:
- for analysing NetFlow flows generated by your border gateway
- replacing the embedded, low-speed, NetFlow probe available on your gateway
- analyzing Gbit networks at full speed with no (or very moderate) packet loss exploiting nProbe
- as a NetFlow probe that sends flows towards a collector either ntop or a commercial one (e.g. Cisco NetFlow Collector or HP-OV)
- both as a probe and collector.
Nevertheless, due to the
original ntop design, it cannot be easily deployed as a pure NetFlow
collector in environments such as a diskless embedded system with
limited resources or a corporate firewall.
In addition, in some environments it would be nice to distribute
light network probes on the network that send traffic information
towards a central traffic analysis console such as ntop.
In order to satisfy the above
requirements nProbe has been designed. Currently nProbe is a software
application available stand-alone or as an embedded system named nBox 
.
Main nProbe Features
- Available for Unix (including MacOS X and Solaris), Windows, and embedded environments.
- NetFlow v9/IPFIX support for efficient flow handling.
- Support for IPv4 and v6
- Limited memory footprint (less that 2 MB of memory regardless of the network size) and CPU savvy.
Ability to natively save flows into MySQL and SQLite, as well as text and binary.
- Native PF_RING support for high speed flow generation
- Support of acceleration cards such as Endace, Mutina Technology, and Tilera.
- Ability to act as flow collector and proxy
- Support of detect protocols via DPI (deep packet inspection) and report protocol name in flows for precise collector protocol accounting
- Ability to forge NetFlow interfaceIds based on MAC/IP addresses.
- New nprobe architecture for better performance with respect to previous versions.
- Support of both flow and packet sampling
- Support of Flexible Netflow: create your netflow templates
- VoIP (SIP and RTP) traffic analysis.
- Plugin architecture for easy extensibility via custom V9/IPFIX tags.
- Fully interoperable with commercial collectors such as Fluke, Cisco, Dartware, AdventNet, Arbor Networks, Plixer.
- Designed for running on environments with limited resources (the nProbe binary < 100 Kb) and embedded systems.
- It can be used to build cheap NetFlow probes using commodity hardware.
- Able to save flows on disk for later analysis or integration into an existing monitoring application.
- Fully user configurable.
- High-performance probe: commercial probes included those embedded on routers and switches are often not able to keep up with high-speeds.
- Ntop can be used as collector and analyser for NetFlow v5/v9/IPFIX flows such as those generated by nProbe and commercial routers.
Using nProbe
The current nProbe version is much more that a simple netflow probe.
| Mode | Scenario |
|---|---|
| Probe |  Command: |
| Collector |  Command: |
| Proxy |  Command: |
It can be a probe, probe+collector, collector, or a proxy. In proxy mode you can convert from/to IPFIX/NetFlow v5/v9 in order to smoothly upgrade to newer netflow protocol versions while capitalizing on previous protocol versions. So you can for instance convert flows coming from your v5 router into IPFIX and vice-versa. Note that with some combinations (e.g. from v9 to v5) you might loose some flow information.
Performance
Many people are aware that not all the available NetFlow probes are scalable. nProbe has been designed to keep up with Gigabit speeds on commodity hardware. Using a dual core CPU, nProbe can be used for capturing packets at full speed with no/very little (< 1%) packet loss using PF_RING. Better results can be achieved using packet/flow sampling (i.e. the probe does not receive all the packets but just a sample), or using an accelerated packet capture card.
| Packet Size (Bytes) | nProbe Sustained Throughtput with no packet loss | |
|---|---|---|
| PF_RING | Endace DAG Mutina IPX Gig | |
| fixed 64 | 462 Kpps [~237 Mbit] | Wire rate |
| fixed 512 | Wire rate | |
| fixed 1500 | ||
| random 64-1500 | ||
The table above shows the result of a worst-case performance test using
- nProbe 5.x Professional (native PF_RING support)
- Ubuntu Linux 8.04 (Hardy Heron)
- PF_RING 3.8.x
- Supermicro PDSM4+ board
- Intel(R) Core(TM)2 CPU 6320 [1.86GHz]
- Intel PCIe Gbit card
- IXIA 400 Traffic Generator
- 100K rotating IP addresses
- Generation of 6'500 flows/minute
- Command used: nprobe -i eth4 -b 1 -w 512000
- No flow storage on DB or disk, just forwarding to a collector
Availability
nProbe is available in two flavours:
- Standard version: nProbe and plugins source code.
You can compile this software on Unix, Linux, Solaris, OSX and Win32 (nProbe for Win32 is available in both binary and source format). - Professional version: same as standard version with native PF_RING support (i.e. full packet capture acceleration) and ability also to compile on embedded platforms such as the Tilera TILE card. This version is available only for Linux.
nProbe is available under the GPLv2 licence for a little fee, that's used for running the project and funding the new developments. You can purchase online your copy of nProbe at the ntop e-shop site. After the transaction is completerd you can download your nProbe copy immediately.
If you are an existing nProbe owner, you can get the v5 standard version and we'll give you a free upgrade to the professional version (do not forget to send us a mail after completing your transaction).
If you want to test drive nProbe you can fetch a demo copy limited to 2,000 flows export.
If you are a no profit institution or a university, you can have nProbe at no cost (even if your donations are welcome): please drop us a mail where you explain why you qualify.
Note that for nProbe OEM,
reselling, repackaging (including device embed) you need a written commercial
licence that's available on request from its author. This because this is
considered as derived work
as specified in the GPL license.
Documentation
nProbe Compatibility List and Deployment Guides
Running nProbe at 10 Gbit
As of today (October 2008), commodity hardware cannot provide full 10 Gbit traffic analysis. Using PF_RING and multicore-aware drivers designed to cope wit it, allow you to operate nProbe at multi-Gbit using commodity hardware. However if you need true 10G wire-rate NetFlow analysis you either need an accelerated card or a way to balance incoming traffic across a few nProbe-enabled devices such as the nBox.
The above figure shows a typical deployment of cPacket's cTap. You can use such device to filter (header or deep-packet-inspection) incoming packets, sample (if necessary), and divert/balance filtered packets across nBox machines at 10 Gbit full-duplex wire-rate (i.e. 20 Gbit), a speed that is well beyond the capability of current PC hardware generation (including PCIe bandwidth). Furthermore as of version 3.3.8, ntop is also able to collect and report monitoring statistics sent by the cTap for complete traffic analysis.
Usage
nProbe is distributed in both source and binary format. Once installed, nProbe is available for use with no further configuration. Similar to ntop, nProbe will be activated on a PC from which it is possible to see/capture the traffic you're interested in. For this reason, in case of switched networks, it is necessary to either mirror traffic (VLAN or port mirror) or place the probe on a location (e.g. by the border gateway) where most of tre traffic flows.
Once activated, nProbe will collect traffic data (see below) and emit NetFlow v5/v9/IPFIX flows towards the specified collector. A set of packets with the same (src ip & port, dst ip & port, protocol #) is called flow (note that some protocols such as ICMP have no concept of ports). Every flow, even a very long standing ISO CD image download, has a limited lifetime; this is because the flow collector should periodically receive flow chunks for accounting traffic precisely.
Usage:
nprobe -n <host:port|none> [-i <interface|dump file>] [-t <dump timeout>]
[-d <idle timeout>] [-l <send timeout>] [-s <scan cycle>] [-N]
[-p <aggregation>] [-f <filter>] [-a] [-b <level>] [-G] [-O <# threads>]
[-P <path>] [-F <dump timeout>] [-D <format>]
[-u <in dev idx>] [-Q <out dev idx>]
[-I <probe name>] [-v] [-w <hash size>] [-e <flow delay>] [-B <packet count>]
[-z <min flow size>] [-M <max num flows>][-R <payload Len>]
[-x <payload policy>] [-E <engine>] [-C <flow lock file>]
[-m <min # flows>][-q <host:port>]
[-S <sample rate>] [-A <AS list>] [-g <PID file>]
[-T <Flow Template>] [-U <Flow Template Id>]
[-o <v9 Templ. Export Policy>] [-L <local nets>] [-c] [-r]
[-1 <MAC>@<ifIdx>][-3 <port>] [-4] [-5 <port>] [-6]
[-9 <path>] [--black-list <networks>] [--pcap-file-list <filename>]
[--collector|-n] <host:port|none> | Address of the NetFlow collector(s).
| Multiple collectors can be defined using
| multiple -n flags. In this case flows
| will be sent in round robin mode to
| all defined collectors if the -a flag
| is used. Note that you can specify
| both IPv4 and IPv6 addresses.
| If you specify none as value,
| no flow will be export; in this case
| the -P parameter is mandatory.
[--interface|-i] <iface|pcap> | Interface name from which packets are
| captured, or .pcap file (debug only)
[--rflows-port|-W] <port> | Capture Rflows packets
[--lifetime-timeout|-t] <timeout> | It specifies the maximum (seconds) flow
| lifetime [default=120]
[--idle-timeout|-d] <timeout> | It specifies the maximum (seconds) flow
| idle lifetime [default=30]
[--queue-timeout|-l] <timeout> | It specifies how long expired flows
| (queued before delivery) are emitted
| [default=30]
[--scan-cycle|-s <scan cycle>] | It specifies how often (seconds) expired
| flows are emitted [default=30].
| If -P is used, the scan cycle will be
| set to the value of the -F parameter
[--rebuild-hash|N] | Rebuild the hash at each scan. Useful for
| producing flows that last as the scan
| cycle as netflow collectors do. This
| option is ignored when -P is not used.
[--aggregation|-p] <aggregation> | It specifies the flow aggregation level:
| <VLAN Id>/<proto>/<IP>/<port>/<TOS>/<AS>
| where each element can be set to 0=ignore
| or 1=take care. Example '-p 1/0/1/1/1/1'
| ignores the protocol, whereas
| '-p 0/0/1/0/0/0' ignores everything
| but the IP
[--bpf-filter|-f] <BPF filter> | BPF filter for captured packets
| [default=no filter]
[--all-collectors|-a] | If several collectors are defined, this
| option gives the ability to send all
| collectors allthe flows. If the flag is
| omitted collectors are selected in
| round robin.
[--verbose|-b] <level> | Verbose output:
| 0 - No verbose logging
| 1 - Limited logging (traffic statistics)
| 2 - Full verbose logging
[--daemon-mode|-G] | Start as daemon.
[--num-threads|-O] <# threads> | Number of packet fetcher threads
| [default=56828]. Use 1 unless you know
[--dump-path|-P] <path> | Directory where dump files will
| be stored.
[--dump-frequency|-F] <dump timeout>| Dump files dump frequencey (sec).
| Default: 60
[--dump-format|-D] <format> | <format>: flows are saved as:
| b : raw/uncompressed flows
| t : text flows
| d : SQLite
| Example: -D b. Note: this flag has no
| effect without -P.
[--in-iface-idx|-u] <in dev idx> | Index of the input device used in the
| emitted flows (incoming traffic). If no
| value is set, the input device is
| dynamically set to the last two bytes of
| the MAC address of the flow sender.
[--out-iface-idx|-Q] <out dev idx> | Index of the output device used in the
| emitted flows (outgoing traffic). If no
| value is set, the output device is
| dynamically set to the last two bytes
| of the MAC address of the flow receiver.
[--vlanid-as-iface-idx] | Use vlanId (or 0 if the traffic isn't tagged)
| as interface index. Note that this option
| superseedes the --in/out-iface-idx options
[--nprobe-version|-v] | Prints the program version.
[--flow-lock|-C] <flow lock> | If the flow lock file is present no flows
| are emitted. This facility is useful to
| implement high availability by means of
| a daemon that can create a lock file
| when this instance is in standby.
[--help|-h] | Prints this help.
[--syslog|-I] <probe name> | Log to syslog as <probe name>
| [default=stdout]
[--hash-size|-w] <hash size> | Flows hash size [default=4096]
[--flow-delay|-e] <flow delay> | Delay (in ms) between two flow
| exports [default=0]
[--count-delay|-B] <packet count> | Send this many packets before
| the -e delay [default=0]
[--min-flow-size|-z] <min flow size>| Minimum TCP flow size (in bytes).
| If a TCP flow is shorter than the
| specified size the flow is not
| emitted [default=unlimited]
[--max-num-flows|-M] <max num flows>| Limit the number of active flows. This is
| useful if you want to limit the memory
| or CPU allocated to nProbe in case of non
| well-behaved applications such as
| worms or DoS. [default=4294967295]
[--payload-length|-R] <payload Len> | Specify the max payload length
| [default: 0 bytes]
[--payload-policy|-x] <policy> | Specify the max payload export policy.
| Format: TCP:UDP:ICMP:OTHER where all
| parameters can se set to:
| 0: no payload for the selected protocol
| 1: payload for the selected protocol
| 2: payload for TCP sessions with SYN flag
| Example -x 2:0:0:0 [default=2:0:0:0]
[--netflow-engine|-E] <engine> | Specify the engine type and id.
| The format is engineType:engineId.
| [default=0:0]
[--min-num-flows|-m] <min # flows> | Minimum number of flows per packet
| unless an expired flow is queued
| for too long (see -l) [default=30
| for v5, dynamic for v9]
[--sender-address|-q] <host:port> | Specifies the address:port of the flow
| sender. This optionis useful for hosts
| with multiple interfacesor if flows
| must be emitted from a static port
[--sample-rate|-S] <pkt rate>:<flow rate>
| Packet capture sampling rate and flow
| sampling rate. Default: 1:1 [no sampling]
[--as-list|-A] <AS list> | File containing the list of known ASs.
[--pid-file|-g] <PID file> | Put the PID in the specified file
[--flow-templ|-T] <Flow Template> | Specify the NFv9 template (see below).
[--flow-templ-id|-U] <Temp. Id> | Specify the NFv9 template identifier
| [default: 257]
[--flow-version|-V] <version> | NetFlow Version: 5=v5, 9=v9, 10=IPFIX
[--flows-intra-templ|-o] <num> | Specify how many flow pkts are exported
| between template exports [default: 10]
[--local-networks|-L] <networks> | Specify the local networks (see -c
| and -r options)
[--local-hosts-only|-c] | All the IPv4 hosts outside the local
| network lists will be set to 0.0.0.0
| (-L must be specified before -c).
| This reduces the load on the probe
| instead of discarding flows on the
| collector side.
[--local-traffic-direction|-r] | All the traffic going towards
| the local networks (-L must also be
| specified before -r) is assumed incoming
| traffic all the rest is assumed outgoing
| (see also -u and -Q).
[--src-mac-address|-1] <MAC>@<ifIdx>| Flow source MAC address (see below)
[--count|-2] <number> | Capture a specified number of packets
| and quit (debug only)
[--nf-collector-port|-3] <port> | NetFlow collector port: incoming port
[--remote-collector-port|-5] <port> | Remote pcap client: incoming port
[--no-promisc|-6] | Capture packets in non-promiscuous mode
[--dump-stats|-9] <path> | Periodically dump traffic stats into the
| specified file
[--black-list] <networks> | All the IPv4 hosts inside the networks
| black-list will be discarded.
| This reduces the load on the probe
| instead of discarding flows on the
| collector side.
[--pcap-file-list] <filename> | Specify a filename containing a list
| of pcap files.
| If you use this flag the -i option will be
| ignored.
Further plugin available command line options
---------------------------------------------------
16/Sep/2008 00:28:36 [plugin.c:136] Loading plugins from ./plugins
16/Sep/2008 00:28:36 [dbPlugin.c:141] WARNING: DB support is not enabled (disabled at compile time)
[MySQL DB]
--mysql=<host>:<dbname>:<table_prefix>:<user>:<pw> | Enable MySQL database support configuration
Contrary to (most) hardware NetFlow v9 probes, nProbe has the ability to specify NetFlow v9/IPFIX using a very flexible format, often known as flexible netflow. The following tags can be used to specify the flow format (nProbe extensions with respect to the standard are highlited):
NetFlow v9/IPFIX format [-T] ---------------- The following options can be used to specify the format: ID Flow Label Description ------------------------------------------------ [ 1] %IN_BYTES Incoming flow bytes [ 2] %IN_PKTS Incoming flow packets [ 3] %FLOWS Number of flows [ 4] %PROTOCOL IP protocol byte [164] %PROTOCOL_MAP IP protocol name [ 5] %SRC_TOS Type of service byte [ 6] %TCP_FLAGS Cumulative of all flow TCP flags [ 7] %L4_SRC_PORT IPv4 source port [167] %L4_SRC_PORT_MAP IPv4 source port symbolic name [ 8] %IPV4_SRC_ADDR IPv4 source address [ 9] %SRC_MASK Source subnet mask (/<bits>) [ 10] %INPUT_SNMP Input interface SNMP idx [ 11] %L4_DST_PORT IPv4 destination port [171] %L4_DST_PORT_MAP IPv4 destination port symbolic name [ 12] %IPV4_DST_ADDR IPv4 destination address [ 13] %DST_MASK Dest subnet mask (/) [ 14] %OUTPUT_SNMP Output interface SNMP idx [ 15] %IPV4_NEXT_HOP IPv4 next hop address [ 16] %SRC_AS Source BGP AS [ 17] %DST_AS Destination BGP AS [ 21] %LAST_SWITCHED SysUptime (msec) of the last flow pkt [ 22] %FIRST_SWITCHED SysUptime (msec) of the first flow pkt [ 23] %OUT_BYTES Outgoing flow bytes [ 24] %OUT_PKTS Outgoing flow packets [ 27] %IPV6_SRC_ADDR IPv6 source address [ 28] %IPV6_DST_ADDR IPv6 destination address [ 29] %IPV6_SRC_MASK IPv4 source mask [ 30] %IPV6_DST_MASK IPv4 destination mask [ 32] %ICMP_TYPE ICMP Type * 256 + ICMP code [ 34] %SAMPLING_INTERVAL Sampling rate [ 35] %SAMPLING_ALGORITHM Sampling type (deterministic/random) [ 36] %FLOW_ACTIVE_TIMEOUT Activity timeout of flow cache entries [ 37] %FLOW_INACTIVE_TIMEOUT Inactivity timeout of flow cache entries [ 38] %ENGINE_TYPE Flow switching engine [ 39] %ENGINE_ID Id of the flow switching engine [ 40] %TOTAL_BYTES_EXP Total bytes exported [ 41] %TOTAL_PKTS_EXP Total flow packets exported [ 42] %TOTAL_FLOWS_EXP Total number of exported flows [ 56] %IN_SRC_MAC Source MAC Address [ 57] %OUT_DST_MAC Destination MAC Address [ 58] %SRC_VLAN Source VLAN [ 59] %DST_VLAN Destination VLAN [ 60] %IP_PROTOCOL_VERSION [4=IPv4][6=IPv6] [ 61] %DIRECTION [0=ingress][1=egress] flow [ 70] %MPLS_LABEL_1 MPLS label at position 1 [ 71] %MPLS_LABEL_2 MPLS label at position 2 [ 72] %MPLS_LABEL_3 MPLS label at position 3 [ 73] %MPLS_LABEL_4 MPLS label at position 4 [ 74] %MPLS_LABEL_5 MPLS label at position 5 [ 75] %MPLS_LABEL_6 MPLS label at position 6 [ 76] %MPLS_LABEL_7 MPLS label at position 7 [ 77] %MPLS_LABEL_8 MPLS label at position 8 [ 78] %MPLS_LABEL_9 MPLS label at position 9 [ 79] %MPLS_LABEL_10 MPLS label at position 10 [ 80] %FRAGMENTED 1=some flow packets are fragmented [ 81] %FINGERPRINT TCP fingerprint [ 82] %CLIENT_NW_DELAY_SEC Network latency client <-> nprobe (sec) [ 83] %CLIENT_NW_DELAY_USEC Network latency client <-> nprobe (usec) [ 84] %SERVER_NW_DELAY_SEC Network latency nprobe <-> server (sec) [ 85] %SERVER_NW_DELAY_USEC Network latency nprobe <-> server (usec) [ 86] %APPL_LATENCY_SEC Application latency (sec) [ 87] %APPL_LATENCY_USEC Application latency (usec) [ 96] %IN_PAYLOAD Initial payload bytes [ 97] %OUT_PAYLOAD Initial payload bytes [ 98] %ICMP_FLAGS Cumulative of all flow ICMP types Plugin dump templates: [100] %DUMP_PATH Path where dumps will be saved Plugin Efficiency calculation templates: [165] %EFFICIENCY_SENT Avg. transmission efficiency % (send) [166] %EFFICIENCY_RCVD Avg. transmission efficiency % (rcvd) Plugin Flow Serial Identifier templates: [190] %FLOW_ID Serial Flow Identifier Plugin HTTP Protocol Dissector templates: [180] %HTTP_URL HTTP URL [181] %HTTP_RET_CODE HTTP return code (e.g. 200, 304...) Plugin RTP templates: [150] %RTP_FIRST_SSRC First flow RTP Sync Source ID [151] %RTP_FIRST_TS First flow RTP timestamp [152] %RTP_LAST_SSRC Last flow RTP Sync Source ID [153] %RTP_LAST_TS Last flow RTP timestamp [154] %RTP_IN_JITTER RTP Jitter (ms * 1000) [155] %RTP_OUT_JITTER RTP Jitter (ms * 1000) [156] %RTP_IN_PKT_LOST Packet lost in stream [157] %RTP_OUT_PKT_LOST Packet lost in stream [158] %RTP_OUT_PAYLOAD_TYPE RTP payload type [159] %RTP_IN_MAX_DELTA Max delta (ms*100) between consecutive pkts [160] %RTP_OUT_MAX_DELTA Max delta (ms*100) between consecutive pkts Plugin SIP templates: [130] %SIP_CALL_ID SIP call-id [131] %SIP_CALLING_PARTY SIP Call initiator [132] %SIP_CALLED_PARTY SIP Called party [133] %SIP_RTP_CODECS SIP RTP codecs [134] %SIP_INVITE_TIME SIP SysUptime (msec) of INVITE [135] %SIP_TRYING_TIME SIP SysUptime (msec) of Trying [136] %SIP_RINGING_TIME SIP SysUptime (msec) of RINGING [137] %SIP_OK_TIME SIP SysUptime (msec) of OK [138] %SIP_BYE_TIME SIP SysUptime (msec) of BYE [139] %SIP_RTP_SRC_IP SIP RTP stream source IP [140] %SIP_RTP_SRC_PORT SIP RTP stream source port [141] %SIP_RTP_DST_IP SIP RTP stream dest IP [142] %SIP_RTP_DST_PORT SIP RTP stream dest port Plugin SMTP Protocol Dissector templates: [185] %SMTP_MAIL_FROM Mail sender [186] %SMTP_RCPT_TO Mail recipient
Any standard NetFlow collector including ntop can be used to analyse the flows generated by nProbe (please note that not all the commercial collecotrs support v9). When used with ntop, the nProbe can act as a remote and light traffic probe, and ntop as a central network monitoring console for IPFIX/v5/v9.
FAQ
- Q: Is nProbe able to operate on Gbit networks at full speed?
A: Yes. Note that for exploiting the Gbit packet capture you need a 64-bit PCI Gigabit Ethernet interface. - Q: Is the nProbe source code available?
A: Yes of course, it's GPL. - Q: Why do you charge for nProbe although it's GPL?
A: GPL has nothing to do with price ([1] [2] [3]) but with freedom. Many open source companies ask a fee for their software. - Q: What do you do with the money you get charging for nProbe?
A: This money is invested for doing research in ntop, nBox and nProbe projects.
Credits
NetFlow is copyright Cisco Systems.