ntop - network top

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 nBox86 (nProbe v4 on nBox availability 3Q 2005).

Main nProbe Features

Available for Unix (including MacOS X), Windows, and embedded environments.
NetFlow v9/IPFIX (draft) 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.
[ New ] VoIP (SIP and RTP) traffic analysis.
[ New ] Plugin architecture for easy extensibility via custom V9/IPFIX tags.
[ New ] Ability to save specified traffic on disk.
[ New ] Fully interoperable with commercial collectors.
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.

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 the following setup (Dual CPU, 64-bit PCI/PCI-X Gbit Card, Linux/*BSD) nProbe can be used for capturing packets at full speed with no/very little (< 1%) packet loss. Better results can be achieved using packet sampling (i.e. the probe does not receive all the packets but just a sample), enabling kernel device polling or using techniques such as the device ring (PF_RING).

Packet Size (Bytes) nProbe Throughtput (Pkt/sec)

64 376'453 [~144 Mbit]

512 213'548 [~850 Mbit]

1500 82'616 [~970 Mbit]

Packet Size (Bytes)	nProbe Throughtput (Pkt/sec)
64	376'453 [~144 Mbit]
512	213'548 [~850 Mbit]
1500	82'616 [~970 Mbit]

The table above shows the nProbe performance a Pentium 4 1.7 GHz (no HyperThreading) with a 32-bit Intel Gigabit Ethernet card and Linux with PF_RING support.

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.

# nprobe -h

24/Aug/2005 17:35:56 Loading plugins.
24/Aug/2005 17:35:56 Looking for plugins in ./plugins
24/Aug/2005 17:35:56 Loaded './plugins/sipPlugin.so'
24/Aug/2005 17:35:56 Loaded './plugins/rtpPlugin.so'
24/Aug/2005 17:35:56 Loaded './plugins/dumpPlugin.so'
24/Aug/2005 17:35:56 Initialized SIP plugin
24/Aug/2005 17:35:56 Initialized RTP plugin
24/Aug/2005 17:35:56 Initialized dump plugin
24/Aug/2005 17:35:56 3 plugin(s) loaded [3 delete][3 packet].

Welcome to nprobe v.4.0 for i686-redhat-linux-gnu
Built on 08/24/05 05:35:27 PM
Copyright 2002-05 by Luca Deri 

Usage: nprobe -n  [-i ] [-t ]
              [-d ] [-l ] [-s ]
              [-p ] [-f ] [-a] [-b ] [-G] [-O <# threads>]
              [-P ] [-D ] [-u ] [-Q ] [-v]
              [-I ] [-w ] [-e ] [-B ]
              [-z ] [-M ][-R ]
              [-x ] [-E ] [-C ]
              [-m ] [-r ] [-q ]
              [-S ] [-A ] [-g ]
              [-T ] [-U ] [-F]
              [-o ] [-L ]


-n <host:port>     | 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.
                   | or to all defined collectors if the -a flag is used.
                   | Note that you can specify both IPv4 and IPv6 addresses.
-i <interface>     | Interface name from which packets are captured
-t <dump timeout>  | It specifies the maximum (seconds) flow lifetime
                   | [default=120]
-d <idle timeout>  | It specifies the maximum (seconds) flow idle lifetime
                   | [default=30]
-l <send timeout>  | It specifies how long expired flows queued in nprobe for delivery
                   | are emitted [default=30]
-s <scan cycle>    | It specifies how often (seconds) expired flows are emitted
                   | [default=30]
-p <level>         | It specifies the flow aggregation level. Available levels:
                   | 0 - IP address: TCP/UDP port numbers are ignored and set to 0
                   | 1 - Ports: IP addresses are ignored and set to 0.0.0.0
                   | 2 - IP Protocol: IP addresses/ports/tos/AS are ignored
                   |     and set to 0.0.0.0/0/0/0
                   | 3 - IP address + IP protocol: TCP/UDP port and IP protocol
                   |     are ignored and set to 0
-f <BPF filter>    | BPF filter used to select captured packets
                   | [default=no filter]
-a                 | If several collectors are defined, this option gives the
                   | ability to send all collectors all the flows. If the flag
                   | is omitted collectors are selected in round robin.
-b <level>         | Verbose output:
                   | 0 - No verbose logging
                   | 1 - Limited logging (periodic traffic statistics)
                   | 2 - Full verbose logging
-G                 | Start as daemon.
-O <# threads>     | Number of fetch packet threads [default=1].
-P <path>          | Directory where dump files will be stored.
-D <format>        | <format>: flows are saved using the specified text format (see below).
                   | b       : raw/uncompressed NetFlow flow format
                   | c       : raw/compressed (gzip) NetFlow flow format
                   | <format>: text format (see below)
                   | Example: -D b. Note: this flag has no effect without -P.
-u <in dev idx>    | Index of the input device used in the emitted flows.
                   | If you don't set any value, the input device is dynamically
                   | set to the last two bytes of the MAC address of the
                   | flow originator.
-Q <out dev idx>   | Index of the output device used in the emitted flows.
                   | If you don't set any value, the output device is dynamically
                   | set to the last two bytes of the MAC address of the
                   | flow receiver.
-v                 | Prints the program version.
-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.
-h                 | Prints this help.
-I <probe name>    | Log to syslog as <probe name> [default=stdout]
-w <hash size>     | Flows hash size [default=4096]
-e <flow delay>    | Delay (in ms) between two flow exports [default=0]
-B <packet count>  | Send this many packets before the -e delay [default=0]
-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]
-M <max num flows> | Limit the number of active flows. This is useful if you want
                   | to limit the memory/CPU allocated to nProbe in case of non
                   | well-behaved applications (e.g. worms, DOS) [default=4294967295]
-R <payload Len>   | Specify the max payload length [default: 0 bytes]
-x <payload policy>| Specify the max payload export policy. The format is:
                   | 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 only for TCP sessions with SYN flag [TCP only]
                   | Example -x 2:0:0:0 [default=2:0:0:0]
-E <engine>        | Specify the engine type and id. The format is
                   | engineType:engineId. [default=0:0]
-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]
-r <dump file>     | Read packets from the dump file (pcap format).
-q <host:port>     | Specifies the address:port of the flow sender. This option
                   | is useful for hosts with multiple interfaces
                   | or if flows must be emitted from a static port
-S <sample rate>   | Rate at which captured packets are processed.
                   | Default: 0 [no sampling]
-A <AS list>       | File containing the list of known ASs.
-g <PID file>      | Put the PID in the specified file
-T <Flow Template> | Specify the NetFlow v9 template (see below).
-U <Flow Temp. Id> | Specify the NetFlow v9 template identifier [default: 257]
-V <version>       | NetFlow Version: 5 (NetFlow 5), 9 (NetFlow 9), 10 (IPFIX)
-o <v9 Temp. Exp>  | Specify how many NetFlow v9 pkts are exported between template exports [default: 10]
-L <local nets>    | If specified, all the IPv4 hosts outside the local network lists will be set to 0.0.0.0.
                   | This significantly reduces the load on the probe instead of discarding flows on the
                   | collector side.

Contrary to (most) hardware NetFlow v9 probes, nProbe has the ability to specify NetFlow v9/IPFIX using a very flexible format. The following tags can be used to specify the flow format (nProbe extensions with respect to the standard are highlited):

ID	Flow Label	Description	Tag Type
1	%IN_BYTES	Incoming flow bytes	Standard
2	%IN_PKTS	Incoming flow packets	Standard
3	%FLOWS	Number of flows	Standard
4	%PROTOCOL	IP protocol byte	Standard
5	%SRC_TOS	Type of service byte	Standard
6	%TCP_FLAGS	Cumulative of all flow TCP flags	Standard
7	%L4_SRC_PORT	IPv4 source port	Standard
8	%IPV4_SRC_ADDR	IPv4 source address	Standard
9	%SRC_MASK	Source subnet mask (/)	Standard
10	%INPUT_SNMP	Input interface SNMP idx	Standard
11	%L4_DST_PORT	IPv4 destination port	Standard
12	%IPV4_DST_ADDR	IPv4 destination address	Standard
13	%DST_MASK	Dest subnet mask (/)	Standard
14	%OUTPUT_SNMP	Output interface SNMP idx	Standard
15	%IPV4_NEXT_HOP	IPv4 next hop address	Standard
16	%SRC_AS	Source BGP AS	Standard
17	%DST_AS	Destination BGP AS	Standard
21	%LAST_SWITCHED	SysUptime (msec) of the last flow pkt	Standard
22	%FIRST_SWITCHED	SysUptime (msec) of the first flow pkt	Standard
23	%OUT_BYTES	Outgoing flow bytes	Standard
24	%OUT_PKTS	Outgoing flow packets	Standard
27	%IPV6_SRC_ADDR	IPv4 source address	Standard
28	%IPV6_DST_ADDR	IPv6 destination address	Standard
29	%IPV6_SRC_MASK	IPv6 source mask	Standard
30	%IPV6_DST_MASK	IPv6 destination mask	Standard
32	%ICMP_TYPE	ICMP Type * 256 + ICMP code	Standard
34	%SAMPLING_INTERVAL	Sampling rate	Standard
35	%SAMPLING_ALGORITHM	Sampling type (deterministic/random)	Standard
36	%FLOW_ACTIVE_TIMEOUT	Activity timeout of flow cache entries	Standard
37	%FLOW_INACTIVE_TIMEOUT	Inactivity timeout of flow cache entries	Standard
38	%ENGINE_TYPE	Flow switching engine	Standard
39	%ENGINE_ID	Id of the flow switching engine	Standard
40	%TOTAL_BYTES_EXP	Total bytes exported	Standard
41	%TOTAL_PKTS_EXP	Total flow packets exported	Standard
42	%TOTAL_FLOWS_EXP	Total number of exported flows	Standard
56	%IN_SRC_MAC	Source MAC Address	Standard
57	%OUT_DST_MAC	Destination MAC Address	Standard
58	%SRC_VLAN	Source VLAN	Standard
59	%DST_VLAN	Destination VLAN	Standard
60	%IP_PROTOCOL_VERSION	[4=IPv4][6=IPv6]	Standard
61	%DIRECTION	[0=ingress][1=egress] flow	Standard
70	%MPLS_LABEL_1	MPLS label at position 1	Standard
71	%MPLS_LABEL_2	MPLS label at position 2	Standard
72	%MPLS_LABEL_3	MPLS label at position 3	Standard
73	%MPLS_LABEL_4	MPLS label at position 4	Standard
74	%MPLS_LABEL_5	MPLS label at position 5	Standard
75	%MPLS_LABEL_6	MPLS label at position 6	Standard
76	%MPLS_LABEL_7	MPLS label at position 7	Standard
77	%MPLS_LABEL_8	MPLS label at position 8	Standard
78	%MPLS_LABEL_9	MPLS label at position 9	Standard
79	%MPLS_LABEL_10	MPLS label at position 10	Standard
80	%IN_DST_MAC	Source MAC Address	Standard
81	%OUT_SRC_MAC	Destination MAC Address	Standard
90	%FRAGMENTED	1=some flow packets are fragmented	Standard
91	%FINGERPRINT	TCP fingerprint	Standard
92	%NW_LATENCY_SEC	Network latency (sec)
93	%NW_LATENCY_USEC	Network latency (usec)	nProbe Extension
94	%APPL_LATENCY_SEC	Application latency (sec)	nProbe Extension
95	%APPL_LATENCY_USEC	Application latency (sec)	nProbe Extension
96	%IN_PAYLOAD	Initial payload bytes	nProbe Extension
97	%OUT_PAYLOAD	Initial payload bytes	nProbe Extension
98	%ICMP_FLAGS	Cumulative of all flow ICMP types	nProbe Extension
130	%SIP_CALL_ID	SIP call-id	nProbe Extension
131	%SIP_CALLING_PARTY	SIP Call initiator	nProbe Extension
132	%SIP_CALLED_PARTY	SIP Called party	nProbe Extension
133	%SIP_RTP_CODECS	SIP RTP codecs	nProbe Extension
134	%SIP_INVITE_TIME	SIP SysUptime (msec) of INVITE	nProbe Extension
135	%SIP_TRYING_TIME	SIP SysUptime (msec) of Trying	nProbe Extension
136	%SIP_RINGING_TIME	SIP SysUptime (msec) of RINGING	nProbe Extension
137	%SIP_OK_TIME	SIP SysUptime (msec) of OK	nProbe Extension
138	%SIP_ACK_TIME	SIP SysUptime (msec) of ACK	nProbe Extension
139	%SIP_RTP_SRC_PORT	SIP RTP stream source port	nProbe Extension
140	%SIP_RTP_DST_PORT	SIP RTP stream dest port	nProbe Extension
150	%RTP_FIRST_SSRC	First flow RTP Sync Source ID	nProbe Extension
151	%RTP_FIRST_TS	First flow RTP timestamp	nProbe Extension
152	%RTP_LAST_SSRC	Last flow RTP Sync Source ID	nProbe Extension
153	%RTP_LAST_TS	Last flow RTP timestamp	nProbe Extension
154	%RTP_IN_JITTER	RTP Jitter (ms * 1000)	nProbe Extension
155	%RTP_OUT_JITTER	RTP Jitter (ms * 1000)	nProbe Extension
156	%RTP_IN_PKT_LOST	Packet lost in stream	nProbe Extension
157	%RTP_OUT_PKT_LOST	Packet lost in stream	nProbe Extension
158	%RTP_OUT_PAYLOAD_TYPE	RTP payload type	nProbe Extension
159	%RTP_IN_MAX_DELTA	RTP max delta (ms * 100) between consecutive pkts	nProbe Extension
160	%RTP_OUT_MAX_DELTA	RTP max delta (ms * 100) between consecutive pkts	nProbe Extension
100	%DUMP_PATH	Path where dumps will be saved	nProbe Extension

nProbe is also able to save flows on disk using a simple, printf-like, format. The following options are available:

Source IP Address (IPv4/6)
Destination IP Address (IPv4/6)
Source MAC Address
Destination MAC Address
Input interface index
Output interface index
Packets sent in Duration (ms between 1st & last packet in this flow)
Octets sent in Duration (ms between 1st & last packet in this flow)
Packets rcvd in Duration (ms between 1st & last packet in this flow)
Octets rcvd in Duration (ms between 1st & last packet in this flow)
SysUptime at start of flow
SysUptime at last packet of the flow
TCP/UDP source port number (.e.g, FTP, Telnet, etc., or equivalent)
TCP/UDP destination port number (.e.g, FTP, Telnet, etc., or equivalent)
Cumulative OR of tcp flags
IP protocol, e.g., 6=TCP, 17=UDP, etc...
dst peer/origin Autonomous System
source peer/origin Autonomous System
IP Type-of-Service
0=no fragmented pkts, 1=fragmented pkts
Host fingerprint
VLAN Tag (802.1q only)
MPLS header (MPLS traffic only)
TCP NetworkLatency: Current seconds since 0000 UTC 1970
TCP NetworkLatency: Residual microseconds since 0000 UTC 1970
ApplicationLatency: Current seconds since 0000 UTC 1970
ApplicationLatency: Residual microseconds since 0000 UTC 1970
ICMP flags
payloadLen
payload

Any standard NetFlow collector (e.g ntop, Cisco FlowCollector, IBM, Trendium or HP-OV) 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.

Availability

nProbe is available under the GPL licence for a little fee, that's used for running the project and funding the new developments. Note that for nProbe OEM reselling (including device embed) you need a written commercial licence that's available on request from its author.

The following table compares the current version with the previous one:

	v. 4.x	v. 3.x
Support for Unix and Win32	Yes	Yes
NetFlow v5/v9/IPFIX (draft) Compliant	Yes	Partial
IPv6 Support	Yes	Yes
Flexible v9/IPFIX flow format	Yes	Yes
Fully Multithreaded	Yes (further speed improvements)	Yes (few threads)
Gigabit Aware	Yes	Yes
Dynamic Flow Format (v9/IPFIX)	Yes (full)	Yes (limited)
Dynamic Flow Optimization (v9/IPFIX)	Yes (full)	No
Multiple Collectors	Yes	Yes
Reflector Mode	Yes	Yes
Win32 Service	Yes (on NT/2K/XP)	Yes (on NT/2K/XP)
VoIP (Voice over IP) Traffic Analisys	Yes	No
Extensible via plugins	Yes	No
Ability to Save Traffic on Disk	Yes	No
Available on Embedded System	Yes	Yes

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 you can have nProbe at no cost even if your donations are welcome: please drop us a mail where you explain why you qualify.

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.
Q: Is nProbe for Win32 able to work on multiprocessor machines?
A: nProbe is multiprocessor aware both on Unix and Windows.