• PF_RING Kernel module
  • - Support for injecting packets to the stack
  • - Added ability to balance tunneled/fragmented packets with the cluster
  • - Improved init.d script
  • - Packet len fix with GSO enabled, caplen fix with multiple clusters
  • - Bug fixes for race condition with rss rehash, memory corruption, transparent mode and tx capture, kernels >= 3.7.
• Drivers
  • - Added PF_RING-aware driver for Chelsio cards (cxgb3-2.0.0.1)
  • - New release for PF_RING-aware igb (igb-4.1.2)
• DNA
  • - Added support for Silicom 10 Gbit hw timestamping commodity NIC card
  • - Added pfring_flush_tx_packets() for flushing queued tx packets
  • - Fixes for cutting packets to snaplen, e1000-dna rx
• Libzero
  • - pfdnacluster_master support for multiple instances of multiple applications
  • - Added dna_cluster_set_thread_name() to name the master rx/tx threads
  • - Fix for direct forwarding with the DNA Cluster
  • - Changed len to a ptr in DNA Bouncer decision function to allow user change forwarded packet content and lenght
• Examples
  • - Added ability to replay a packet with pfsend passing hex from stdin
  • - Added pfwrite to the package
  • - Fix for rate control with huge files in pfsend

The way the original ntop was designed was IMHO very advanced for that time, but today is no longer so for many reasons. Today people want to have a flexible network monitoring engine able to scale at multi-Gbit, using limited memory, immune to crashes “no matters what”, scriptable and extensible, able to see what’s happening in realtime with 1-second accuracy, capable of characterising hosts (call it host reputation if you wish) and storing monitoring data on the cloud for (de-)centralised monitoring even of those devices that have no disk space. Over the past years we have tried to address ntop open issues, but the code base was too old, complicated, bug-prone. In essence it was time to start over, preserve the good things of ntop, and learn from mistakes. So basically looking forward by creating a new ntop, able to survive (hopefully) 15 more years and set new monitoring standards.

This has the motivation behind what I temporarily call ntopng (ntop next generation). The work to do is huge but as you can see many things are already working.

The main design principles are:

• Open source, self-contained with zero configuration, just like the original ntop.
• ntopng is a cache, just like the original ntop, but contrary to its predecessor we leverage on Redis for implementing multi-level caching:
  • ntopng keeps in memory the current network traffic
  • Redis keep the “recent network history”
  • (Optionally) Persistently dump traffic history on disk for long term traffic analysis.
• nDPI centric: ports are no longer enough, as we want to identify application protocols even on non standard ports.
• Ability to leverage on PF_RING for monitoring million packets/second with no drops.
• Written in C++, with clean code layout. Occasionally some routines from the original ntop will be ported to ntopng, but the idea is to write everything from scratch on a clean room. The ntop code didn’t have a real API and it was so complicated after years of patches, that people were scared of touching me.
• The web GUI is based on Twitter Bootstrap for modern, consistent, and mobile-friendly GUI.
• The ntopng engine is scriptable in LuaJIT.
• Web pages are written in Lua: everyone can write its on pages without having to code in C.
• ntopng, as well nProbe, leverage on the MicroCloud for creating a comprehensive network view.

This said, the work to do is huge and it will take some time before ntopng will be completed. This means that if you want, we need your help to expedite its development. You can access the ntopng code here:

svn co https://svn.ntop.org/svn/ntop/trunk/ntopng/

The core is stable (we have tested on Linux and OSX, but it will soon be tested/compiled on Windows) although it is still missing some pieces such as IPv6 support, historical charts, NetFlow/sFlow support and more reports. We encourage you to download and test it. Likely you can help us developing it, or at least testing it. As you can imagine, we have no time to support the original ntop, as we are focusing on this new release. We plan to have an initial release by late May: time is limited, but we’re confident to include all the core features on this release then refine it through the rest of the year.

For years network adapter manufacturer companies have educated their customers that network monitoring applications can’t live without hardware packet timestamps (i.e. the ability for the network adapter to report to the driver the time a given packet was sent or received). State of the art FPGA-based network adapters [1, 2, 3] have hardware timestamps with a resolution of +/- ~10 nsec and accuracy of +/- ~50 nsec so that monitoring applications can safely assume an accuracy of  100 nsec in measurements, for sub-usec measurements. Commodity adapters such as Intel 1 Gbit provide both RX and TX timestamps out of the box with IEEE 1588 time synchronisation, so the problem is on 10 Gbit (this until Intel comes us with a 10G adapter with hardware timestamps).

Who Really Needs Sub-microsecond Packet Timestamps?

This is a good question. Everyone seems to want it, but they in practice they might not need it. Let’s clarify this point a bit more in detail. For RTT (Round-Trip Time) measurements (i.e. I want to see how long a packet takes from location X to location Y) measurements on long-distance (e.g. Italy to USA and back) the order of magnitude is msec (actually tenth/hundred of msec) so usec are not needed, for a LAN is not needed either because if the probe packet used to monitor RTT is originated/received on the same adapter, 1 Gbit commodity adapters can do the trick and PF_RING supports them. For one-way delay (i.e. how to measure the time from A->B) on a WAN, 1G adapters+IEEE 1588 can do the trick (the delay is in msec), on a LAN same as above.

So who needs really sub-microsecond hardware timestamps at 10 Gbit (at 1 Gbit we have the solution as explained until now)? Reading on the Internet, it seems that one of the few markets where they are needed is in microburst detection [1, 2] in particular on critical networks such as high-frequency trading and industrial plants.

Can ntop Provide Sub-microsecond Timestamps in Software at 10 Gbit?

In short: yes we can. When we developed our n2disk application at 10 Gbit, we have faced with the problem of  timestamps as no commodity adapter supported them. We have spent quite some time to optimise this application and these are our findings:

• We suppose to use a server machine with a good motherboard (i.e. Dell, Supermicro, HP), no toy PCs. This guarantees that the clock on the board is of good quality.
• The call to clock_gettime() used to read the timestamp in software takes ~30 nsec in our tests. As at 10 Gbit the max packet ingress rate is (14.88 Mpps) is 67 nsec, reading the timestamp once the packet is received it overkilling (not to mention that the reported time will be shifted in the future with respect to real packet arrive).
• We decided to create a thread (we called it pulse thread) that calls clock_gettime() at full speed and shares the time with the capture thread.

On our E3-1230 (CPU cost ~200 USD) starting n2disk as follows

n2disk10g -o /tmp/ -p 1024 -b 2048 -i dna0 --active-wait -C 1024 -w 0 -S 2 -c 4  -v -R 6 --nanoseconds

we can achieve both 10 Gbit to disk

25/Apr/2013 10:20:37 [n2disk.c:576] [PF_RING] Total stats: 90843997 pkts rcvd/90843997 pkts filtered/0 pkts dropped [0.0%]
25/Apr/2013 10:20:37 [n2disk.c:592] Capture Duration: 00:00:06
25/Apr/2013 10:20:37 [n2disk.c:594] Average Capture Throughout: 10.00 Gbit / 14.88 Mpps
25/Apr/2013 10:20:37 [n2disk.c:1593] [writer] Thread terminated
25/Apr/2013 10:20:37 [n2disk.c:3664] Writer thread terminated
25/Apr/2013 10:20:37 [n2disk.c:2805] Packet capture thread terminated
25/Apr/2013 10:20:37 [n2disk.c:3668] Reader thread terminated
25/Apr/2013 10:20:37 [n2disk.c:3673] Time thread terminated

and high-accuracy timestamps. In fact this is what happens:

< 30 nsec timestamps (as in the above test)

60 1366418032.342040270 6726 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040355 6727 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040430 6728 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040502 6729 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040613 6730 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040728 6731 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040767 6732 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342040890 6733 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041036 6734 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041238 6735 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041427 6736 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041610 6737 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041685 6738 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041835 6739 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342041982 6740 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342042056 6741 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342042167 6742 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342042327 6743 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342042441 6744 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366418032.342042515 6745 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)

As you can see all packets have different timestamps

100 nsec timestamps

60 1366417070.119899160 5183 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899386 5184 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899501 5185 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899615 5186 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899615 5187 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899731 5188 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899846 5189 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119899960 5190 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900073 5191 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900187 5192 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900301 5193 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900417 5194 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900532 5195 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900646 5196 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900646 5197 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900762 5198 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900877 5199 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119900989 5200 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119901104 5201 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417070.119901218 5202 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)

Bad: some packets have the same timestamp.

500 nsec timestamps

60 1366417709.563877691 3466 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3467 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3468 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3469 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3470 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3471 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878226 3472 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3473 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3474 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3475 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3476 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3477 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563878763 3478 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3479 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3480 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3481 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3482 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3483 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879297 3484 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)
60 1366417709.563879832 3485 192.85.1.2 -> 192.0.0.1 IP Unknown (0xfd)

Very bad: too many packets have the same timestamp.

Conclusion

Using software timestamps and our “timestamp trick” you can achieve ~30 nsec timestamp precision, so that at 10 Gbit line rate all packets have a different timestamp (so we’re below 67 nsec timestamp resolution). This means that you can use n2disk for detecting microbursts at 10 Gbit line rate as:

1. It can handle 14.88 Mpps with no drops when dumping them to disk with nsec timestamps
2. You can avoid using hardware timestamps for sub-usec precision and leave them only for specific tasks where you need very accurate ~100 nsec timestamps. At this point in time however, we have not received any request from people who really need them, so we’re confident that our approach can be enough for most people.
3. Hardware timestamps still make sense in those cases where you need a NIC with a GPS signal ingress, so that you can accurately sync the time over long distance with an accuracy better than what IEEE 1588 can offer you.

• We have created the nBox GUI to enable you to use all our applications without the pain of compiling and configuring them. This is a free product that everyone can use to build their own measurement gear or just to start ntop using a web browser.
• We have refreshed all manuals and tried to include all your comments.

You can find all the documentation in the section Documentation of this web site and in particular:

• PF_RING User’s Guide
• vPF_RING User’s Guide
• nProbe User’s Guide
• n2disk User’s Guide
• nBox 2.0 QuickStart Guide
• nBox 2.0 Manual

We plan to soon write the nDPI manual and start working at ntop. Be patient.

As usual we await your comments and feedback. We apologise once again for you waiting so long.

Hardware

• Sandy-Bridge (or better)-based motherboard such as X9SLC.
• Intel E3 or E5 CPU (both CPUs with the above motherboard can do 10 Gbit NetFlow and packet-to-disk).
• At least 4 GB of RAM.
• A DNA-aware card.
• RAID controller and at least 8 x 10k RPM drives (for packet to disk only, not needed for flow monitoring).

Software

• Ubuntu Server x64 LTS. This is our favourite distribution.
• If you prefer CentOS/RedHat you can also use CentOS Server 6.x x64. We also support CentOS but to date we have not yet ported the nBox package to CentOS and thus you need to use it from the command line.

Once you have configured the machine and installed the base operating system, depending on your OS go to:

• Ubuntu Server: http://apt.ntop.org
  • apt-get install pfring nprobe n2disk ntop5 nbox
• CentOS: http://rpm.ntop.org
  • yum install pfring n2disk nProbe ntop5

and follow the instructions. In essence we have created an APT and YUM repository so you can use it in your favourite distro.

At this point your nbox in configured and you can point your browser to http://<your nbox IP> for accessing the nBox management interface.

For more information please refer to the nBox documentation and in particular:

• nBox QuickStart Guide
• nBox Manual

• Port to various platforms including Linux, MacOSX, Windows and FreeBSD.
• Enhancement of the demo pcapReader application both in terms of speed/features and encapsulations supported (for instance you can now analyse GTP-tunneled traffic).
• Ability to compile nDPI for the Linux kernel so that you can use it for developing efficient kernel-based modules.
• Various speed enhancements so that nDPI is now faster than its predecessor.
• Added many protocols (we not support almost 160 protocols) ranging from “business” protocols such as SAP and Citrix, as well as “desktop” protocols such as Dropbox and Spotify.
• Ability to define port (and port range)-based protocol detection, so that you can complement protocol detection with classic port-based detection.

In addition to all this, we have recently added in nDPI the ability to support sub-protocols using string-based matching. This is because many new sub-protocols such as Apple iCloud/iMessage, WhatsApp and many others use HTTP(S) can be detected by decoding the SSL certificate host or the HTTP “Host:”. Thus we have decided to embed in nDPI an efficient string-matching library based on the popular Aho-Corasick algorithm for matching hundred of thousand sub-strings efficiently (i.e. fast enough to sustain 10 Gbit traffic on commodity hardware). You can now specify sub-protocols at runtime  using a configuration file with the following format:

# Subprotocols
# Format:
# host:"<value>",host:"<value>",.....@<subproto>
host:"googlesyndacation.com"@Google
host:"venere.com"@Venere

in addition to port-based protocol detection using the following format:

#  Format:
#  <tcp|udp>:,<tcp|udp>:,.....@
tcp:81,tcp:8181@HTTP
udp:5061-5062@SIP
tcp:860,udp:860,tcp:3260,udp:3260@iSCSI
tcp:3000@ntop

You can test your custom configuration using the pcapReader (use -p option)  application or enhance your application using the ndpi_load_protocols_file() nDPI API call.

This said, every month new protocol are introduced and become popular, thus nDPI needs constant maintenance and enhancement. We need your help for developing new protocol dissectors. Please contact us if you want to join the nDPI team.

See also:

• nDPI Supports Skype, Whatsapp and Netflix

In essence as you will see from the screenshots below, using the nBox you forget the command line, and easily accomplish your tasks with a few mouse clicks.

In essence we have created a new web interface that can simplify your configurations, assist with complex things such as core affinity or DNA configuration, and let you focus on ntop applications rather than on their configuration. You can download the nBox from the packages site, or use (suggested) the apt site for configuring everything adding this repository to your apt sources as describe on the site.

Notes:

• The nBox GUI is released under GPLv3: feel free to use it and enjoy it.
• Initially we have packaged the nBox GUI for Linux Ubuntu, but we plan to port it soon to RedHat/CentOS.
• We encourage you to test the nBox GUI and send us patches and bug reports.
• Every night we build new/fresh packages, so you can keep your apps up-to-date with no hassle.
• Unfortunately Linux Ubuntu updates the kernel very often. This requires that the PF_RING package we build uses the same kernel version of your box. Make sure that both kernel versions are the same otherwise you need to update your kernel and align it to our version. You have been warned!

• Fix for corrupted VLAN tagged packets
• Userspace bpf support (when using dna)
• PF_RING-aware igb default moved to 4.0.17
• Flow Control  rx/tx automatically disabled by the driver
• Added DAQ drivers into RPM (http://packages.ntop.org)
• New pfring_open() flag PF_RING_DNA_FIXED_RSS_Q_0 to send all traffic to queue 0 and select other queues with hw filters (DNA cards with hw filtering only)
• Added check for modern libc versions
• New pfdnacluster_mt_rss_frwd sample app (packet forwarding using libzero dna cluster for rx/balancing and standard dna with zero-copy on rss queues for tx)
• Added ability to create a stats file under /proc/net/pf_ring/stats so that
• Applications can report stats via the /proc filesystem.
• Added pfring_set_application_stats() for reporting stats
• Added pfring_get_appl_stats_file_name() for getting the exact filename where the app sets the statistics
• Updated pfcount and pfsend to report stats using these new primitives
• pfcount: -v option changed
  •  -v 1: same as -v (in the previous version)
  •  -v 2: same as “-v 1″ with the difference that the whole packet is printed in hex
• Due to popular demand we moved from LGPL3 to LGPL2.1

Our goal has been the monitoring of mobile network traffic, similar to what happens on standard IP networks in order to answer with some extras. In mobile networks, there is a protocol called GTP (GPRS Tunnelling Protocol) that is decomposed in two separate protocols:

• GTP-U: used to carry user-data traffic, i.e. the network traffic you make with your handheld when accessing the Internet (e.g. email, web surfing, gaming).
• GTP-C: used to carry signalling within the GPRS core network. Whenever you connect/disconnect, hop inside the network with your handheld, the network generates a message. Monitoring GTP-C is the key for keeping and association between a user (i.e. IMSI) and the dynamic IP address associated to the user within the mobile network. There is much more than this in GTP-C, such as the user phone number, the cell where the user is connected (and thus it’s physical location), the APN, and the handheld model. GTP-C  is used to negotiate tunnel Ids, that are then used to carry user traffic, so GTP-C traffic state must be kept somewhere on a a database  in order to keep the association between a user and its IP address.

GTP-C is handled with two plugins (gtpv1 and gtpv2 plugins), as well the radius protocol.  The nProbe core instead has been updated to support many protocol and encapsulations used on mobile networks such as:

• PPP/Multilink PPP
• Mobile IP
• L2TP
• GTP v1 (2G/3G networks) and v2 (4G/LTE networks)
• GRE
• Radius with 3GPP extensions used on mobile networks.

All existing nProbe plugins have been updated so GTP-C is now first-class citizen. This means for instance that when nProbe sees some GTP-encapsulated HTTP traffic, along with the usual information (URL, Cookies, User-Agent….) information about the user who generated this traffic is also returned (i.e. the IMSI). This information correlation is implemented transparently in nProbe using the microcloud paradigm.

Whenever nProbe sees some GTP-C message, it dynamically (and automatically) updates the user status into the redis database, so that this information can be user to bind GTP-U to users.

Another advantage of the microcloud architecture, is that it allows traffic  to be correlated across various probes. In fact mobile networks are distributed by nature, and it is usually not possible to aggregate all traffic into a single place. The microcloud allows all probes to share data (of course data caching is implemented on teach nProbe instance to avoid too many communications), so that all combinations are supported.

PF_RING clustering has also been updated so that whenever a server running nProbe, incoming traffic can shared across all running nProbe instances. This happens by honouring GTP tunnelling as PF_RING will not balance on the external packet envelope but on tunnelled traffic. Using this approach, PF_RING allows incoming network traffic (also on multiple incoming interfaces)  to be balanced across multiple instances and thus to monitor multi-Gbit traffic on a single server.

Of course nDPI is able to dissect GTP-encapsulated traffic, and thus you can configure nProbe (by means of the specified template, -T) to analyse traffic at application level and thus learn the layer-7 protocol.

nProbe can export information via NetFlow v9/IPFIX using the following information elements:

Plugin GTPv1 Signaling Protocol templates:
[NFv9 57692][IPFIX 35632.220] %GTPV1_REQ_MSG_TYPE GTPv1 Request Msg Type
[NFv9 57693][IPFIX 35632.221] %GTPV1_RSP_MSG_TYPE GTPv1 Response Msg Type
[NFv9 57694][IPFIX 35632.222] %GTPV1_C2S_TEID_DATA GTPv1 Client->Server TunnelId Data
[NFv9 57695][IPFIX 35632.223] %GTPV1_C2S_TEID_CTRL GTPv1 Client->Server TunnelId Control
[NFv9 57696][IPFIX 35632.224] %GTPV1_S2C_TEID_DATA GTPv1 Server->Client TunnelId Data
[NFv9 57697][IPFIX 35632.225] %GTPV1_S2C_TEID_CTRL GTPv1 Server->Client TunnelId Control
[NFv9 57698][IPFIX 35632.226] %GTPV1_END_USER_IP GTPv1 End User IP Address
[NFv9 57699][IPFIX 35632.227] %GTPV1_END_USER_IMSI GTPv1 End User IMSI
[NFv9 57700][IPFIX 35632.228] %GTPV1_END_USER_MSISDN GTPv1 End User MSISDN
[NFv9 57701][IPFIX 35632.229] %GTPV1_END_USER_IMEI GTPv1 End User IMEI
[NFv9 57702][IPFIX 35632.230] %GTPV1_APN_NAME GTPv1 APN Name
[NFv9 57703][IPFIX 35632.231] %GTPV1_MCC GTPv1 Mobile Country Code
[NFv9 57704][IPFIX 35632.232] %GTPV1_MNC GTPv1 Mobile Network Code
[NFv9 57705][IPFIX 35632.233] %GTPV1_CELL_LAC GTPv1 Cell Location Area Code
[NFv9 57706][IPFIX 35632.234] %GTPV1_CELL_CI GTPv1 Cell CI
[NFv9 57707][IPFIX 35632.235] %GTPV1_SAC GTPv1 SAC

Plugin GTPv2 Signaling Protocol templates:
[NFv9 57742][IPFIX 35632.270] %GTPV2_REQ_MSG_TYPE GTPv2 Request Msg Type
[NFv9 57743][IPFIX 35632.271] %GTPV2_RSP_MSG_TYPE GTPv2 Response Msg Type
[NFv9 57744][IPFIX 35632.272] %GTPV2_C2S_S1U_GTPU_TEID GTPv2 Client->Svr S1U GTPU TEID
[NFv9 57745][IPFIX 35632.273] %GTPV2_C2S_S1U_GTPU_IP GTPv2 Client->Svr S1U GTPU IP
[NFv9 57746][IPFIX 35632.274] %GTPV2_S2C_S1U_GTPU_TEID GTPv2 Srv->Client S1U GTPU TEID
[NFv9 57747][IPFIX 35632.275] %GTPV2_S2C_S1U_GTPU_IP GTPv2 Srv->Client S1U GTPU IP
[NFv9 57748][IPFIX 35632.276] %GTPV2_END_USER_IMSI GTPv2 End User IMSI
[NFv9 57749][IPFIX 35632.277] %GTPV2_END_USER_MSISDN GTPv2 End User MSISDN
[NFv9 57750][IPFIX 35632.278] %GTPV2_APN_NAME GTPv2 APN Name
[NFv9 57751][IPFIX 35632.279] %GTPV2_MCC GTPv2 Mobile Country Code
[NFv9 57752][IPFIX 35632.280] %GTPV2_MNC GTPv2 Mobile Network Code
[NFv9 57753][IPFIX 35632.281] %GTPV2_CELL_TAC GTPv2 Tracking Area Code
[NFv9 57754][IPFIX 35632.282] %GTPV2_SAC GTPv2 Cell Identifier

Plugin Radius Protocol templates:
[NFv9 57712][IPFIX 35632.240] %RADIUS_REQ_MSG_TYPE RADIUS Request Msg Type
[NFv9 57713][IPFIX 35632.241] %RADIUS_RSP_MSG_TYPE RADIUS Response Msg Type
[NFv9 57714][IPFIX 35632.242] %RADIUS_USER_NAME RADIUS User Name (Access Only)
[NFv9 57715][IPFIX 35632.243] %RADIUS_CALLING_STATION_ID RADIUS Calling Station Id
[NFv9 57716][IPFIX 35632.244] %RADIUS_CALLED_STATION_ID RADIUS Called Station Id
[NFv9 57717][IPFIX 35632.245] %RADIUS_NAS_IP_ADDR RADIUS NAS IP Address
[NFv9 57718][IPFIX 35632.246] %RADIUS_NAS_IDENTIFIER RADIUS NAS Identifier
[NFv9 57719][IPFIX 35632.247] %RADIUS_USER_IMSI RADIUS User IMSI (Extension)
[NFv9 57720][IPFIX 35632.248] %RADIUS_USER_IMEI RADIUS User MSISDN (Extension)
[NFv9 57721][IPFIX 35632.249] %RADIUS_FRAMED_IP_ADDR RADIUS Framed IP
[NFv9 57722][IPFIX 35632.250] %RADIUS_ACCT_SESSION_ID RADIUS Accounting Session Name
[NFv9 57723][IPFIX 35632.251] %RADIUS_ACCT_STATUS_TYPE RADIUS Accounting Status Type
[NFv9 57724][IPFIX 35632.252] %RADIUS_ACCT_IN_OCTETS RADIUS Accounting Input Octets
[NFv9 57725][IPFIX 35632.253] %RADIUS_ACCT_OUT_OCTETS RADIUS Accounting Output Octets
[NFv9 57726][IPFIX 35632.254] %RADIUS_ACCT_IN_PKTS RADIUS Accounting Input Packets
[NFv9 57727][IPFIX 35632.255] %RADIUS_ACCT_OUT_PKTS RADIUS Accounting Output Packets

and as well save traffic information on dump files using some command line options:

--gtpv1-dump-dir <dump dir> | Directory where GTPv1 logs will be dumped
--gtpv1-exec-cmd <cmd> | Command executed whenever a directory has been dumped
--gtpv2-dump-dir <dump dir> | Directory where GTPv2 logs will be dumped
--gtpv2-exec-cmd <cmd> | Command executed whenever a directory has been dumped
--radius-dump-dir <dump dir> | Directory where Radius logs will be dumped
--radius-exec-cmd <cmd> | Command executed whenever a directory has been dumped

In essence nDPI, PF_RING and nProbe are now able to monitor multi-Gbit mobile traffic and automatically correlate GTP-C to GTP-U traffic in the probe using the microcloud without doing it on the collector as other tools do. The advantage is that as soon as a flow is exported, the collector immediately knows the mobile user that has generated the traffic not to mention that correlation implemented on the collector is costly in terms of computing resources.  As the information in the microcloud is persistent, in the unlikely case of crash, nothing is lost as the user-to-GTP traffic correlation is maintained in the microcloud. This also applies in case mobile traffic grows and additional probes need to be started (also on different network locations that are still connected via IP to the microcloud): they automatically, since their startup, are able to correlate user-to-traffic.

To date, nProbe is used to permanently monitor the traffic of some country-wide mobile operators. If you are interested in testing it into your environment, you can download a ready-to-user nProbe binary package and have fun!