![]() Below is our configuration for push mode. Also because in case a new collector has to be added, the probe has to be reconfigured. collector X cannot tell the probe that it is interested only to HTTP-based flows, but it has to collect everything and discard unneeded information). This architecture is suboptimal as the probe is pushing the same data to all collectors (i.e. ![]() In push mode, nProbe sends data to ntpong (collector) as soon as possible. Note: in case you encounter problem with user, start ntopng with the option -dont-change-user. Below is the configuration of ntopng and nProbe in a poll mode. This practice optimises network traffic and limits the CPU cycles to those really necessary to carry on to collect flows. The probe sends ntopng only this information, without sending all flows to ntopng as probes do. In a poll mode, ntopng dynamically subscribes to the probe via ZMQ, telling the probe what type of flow data it is interested in. NProbe can work in two modes - poll mode and push mode. Note: Without valid license, nProbe is working in demo mode and it is limited to show only 25000 flows export. In fact, we are monitoring only Windows 7 machine that is connected to Fa0/3. Our goal is to monitor network traffic from all devices connected to the ports of Cisco Catalyst switch 3550. ntpong is running on Ubuntu 18.04.1 Server as the VirtualBox guest with the IP address 172.17.100.7/16. NProbe is running on Raspberry Pi 3B with the IP address 172.17.100.50/16. First, let's have a look at the network topology. This tutorial goes further and it covers configuration of the both ntopong and nProbe. The source of the traffic is the interface Fa0/3 where PC is connected and the destination port is Fa0/24 with connected Raspberry Pi 3B. We have also configured Cisco Catalyst switch 3550 for traffic mirroring. In the Part1 we have covered compilation of ntopng on Ubuntu 18.04.1 Server and installation of nProbe on Raspberry Pi 3.
0 Comments
Leave a Reply. |