nProbe/ntopng can now operate both in pull/push mode.In the latest development versions of ntopng and nProbe, we have introduced several enhancements to address these issues. on a cheap VPS host) and nProbe on a private network, ntopng is unable to connect to the probe and thus flow collection won’t work. In fact, in case you run the ntopng collector on a public IP (e.g. This architecture however is unable to operate in case of a NAT.
This practice optimises network traffic and limits the CPU cycles to those really necessary to carry on to collect flows. Via ZMQ ntopng dynamically subscribes to the probe, tells the probe what type of flow data it is interested in, and the probe sends ntopng only this information, without sending all flows to ntopng as probes do. Ntopng has reverted this paradigm using a poll-mode architecture. Another issue is that data exchanged is in clear, meaning that anyone intercepting flows sent by the probe, can find out what happens in the monitored network we are aware that you can setup a dedicated VLAN/VPN to avoid this but this practice adds complexity. collector X cannot tell the probe that it is interested only to HTTP-based flows, but it has to collect everything and discard un-needed information) and also because in case a new collector has to be added, the probe has to be reconfigured (i.e. This architecture is suboptimal as the probe is pushing the same data to all collectors (i.e. Usually NetFlow/sFlow is a push mode paradigm as network devices have almost no memory/storage and thus they send out data as soon as possible towards a collector. flow exporter) and the flow collector/analyser. In flow-based monitoring there are two main components: the probe (a.k.a.