Since the introduction of nProbe Cento, we receive periodically emails of users wondering what are the differences between these two applications. This post is to clarify the differences, and better position them.
The nProbe family is a set of flow-oriented applications, meaning that each packet is not handled individually but as part of a flow (e.g. a TCP connection or a UDP communication such as a VoIP call). This task is significantly more expensive than handling packets individually because we need both to keep the flow state and process packets in order in addition to other restrictions (e.g. make sure all packets of the same flow are sent to the same processing core). Traditionally ntop has its roots in the network monitoring world, where people want to passively (i.e. without modifying the network traffic being watched) monitor their traffic in order to find out things like top talkers or troubleshoot problems. However in the past couple of years we have received many requests of users willing to do more than that (e.g. selectively drop traffic of specific applications via DPI) in a flow-oriented fashion. The advent of 40 and 100 Gbit ethernet, has pushed us to redesign nProbe and create an addition to the nProbe family targeting selected users who need to both monitor and manipulate traffic in a flow-oriented fashion. This is how nProbe Cento was born.
Below you can find some use-cases where we try to position all applications
| Family | Standard | Pro | Cento |
|---|---|---|---|
| Max Processing Speed | 1 Gbit | 10 Gbit | 40/100 Gbit |
| Packet Processing Mode | Passive | Passive and Inline | |
| Operating Systems | Linux and Windows | Linux | |
| PF_RING (ZC) Integration | No | Yes | |
| Platforms | ARM, MIPS, x64 | x64 | |
| DPI Traffic Inspection | Yes (nDPI) | ||
| DNS/HTTP Traffic Dissection | No | Full (with DNS/HTTP plugins) | Limited to core attributes |
| Flow-Latency Measurements | Yes | ||
| Flow Collection | Yes (both sFlow and NetFlow) | No | |
| Policy-based Interface Bridging | No | Yes | |
| Plugin Extensibility | No | Yes | No (DNS and HTTP dissection included) |
| Packet-to-Disk Integration | No | Yes (n2disk) | |
| IDS/IPS Integration | No | Yes (with optional packet shunting) | |
| Flow-based Interface Egress | No | Yes | |
| Flow-based Packet Policy | No | Yes | |
| Text/JSON/NetFlow v5/v9/IPFIX Export | Yes | ||
| ElasticSearch/Kibana Integration | No | Yes (With Export Plugin) | No |
| VoIP/GTP/Email/Radius… Dissection | No | Yes (With protocol Plugins) | No |
| Kafka Integration | No | Yes | |
One of the most popular questions we receive is whether plugin support will be supported in Cento. Currently we have no plans for that as they would introduce significant processing overhead that will prevent cento from running at 100 Gbit (this is support on adequate hardware platforms where you have at least 12 cores for 100 Gbit line rate processing). However we might consider adding support for additional protocols fields (e.e. Cento dissects DNS/HTTP core attributes such as DNS query and HTTP URL) based on user’s feedback.
In summary, if you need to do only passive traffic monitoring at no more than 10 Gbit, then nProbe Standard/Pro is what you are looking for. Instead if you need to do both flow-based traffic inspection and inline traffic management (e.g. selectively drop Skype or NetFlix traffic) or add traffic metadata (i.e. add application protocol and flow-identifier) to packets that are recorded on disk, then Cento is the application to use.