One of the most difficult steps on a monitoring deployment scenario is to choose where is the best point where traffic has to be monitored, and what is the best strategy to observe this traffic. The main options are basically:
- Port Mirroring/Network Tap
- NetFlow/sFlow Flow Collector
Port Mirroring/Network Tap
Port mirroring (often called span port) and network tap have already been covered on a previous post. They are two techniques used to provide packet access that often are the best way to troubleshoot network issues as packets are often perceived as the ground truth (“packets never lie”). This means that we are able to have a “full packet visibility” because we have visibility of L2 (mirror) or L1 (taps). There are various types of hardware taps where the most complex is called network packet broker. A good introduction to this topic, Tap vs. Span, can be found on this deep dive article. Note that is you are monitoring traffic on a computer you have access to, you can avoid this technique by simply running your monitoring tool on this host: just be aware that you will introduce some extra load on the server and thus that you network communications might be slightly affected by your monitoring activities.
NetFlow/sFlow Flow Collector
In flow collection we have no direct access to packets with some little differences. In NetFlow/IPFIX is the probe running inside the router that clusters together similar packets according to a 5-tuple key (proto, IP/port src/dst) and computes metrics such as bytes, packets; in a way NetFlow/IPFIX “compresses” (not literally) traffic in order to produce a “digest” of network communications. In sFlow instead, the probe running inside the network switch emits samples that include “packet samples” that in essence are packets captured on switch ports cut to a snaplen (usually 128 bytes) and send to a sFlow collector encapsulated on sFlow packet format. When comparing sFlow to packet capture you have no full packet visibility (both in terms of packet length and ability to see all packets but just a sample), but on the other hand you have access to additional metadata such as the name of the authenticated user (e.g. via Radius or 802.1X) that made such traffic. This is a very important information that can be very helpful during troubleshooting or security analysis.
In flow collection, ntopng will show you flows collected by nProbe and sent to ntopng via ZMQ. This has the advantage of being able to monitor multiple NetFlow/sFlow/IPFIX exporters and combine all of them into a single ntopng instance. Doing the same with packets would have been much more complicated if doable at all. In this scenario, you need to keep in mind that you can see only prefiltered and presummarized traffic from the device that is sending flow: it mean that you can’t have “full packet visibility” but only a summarized version of it.
Which Option is the Best?
It is now time to decide the flow visibility strategy to follow, this based on your monitoring expectation. Taps are definitively a good options for packet-oriented people, but keep in mind that is possible to have also mixed scenarios where some networks are monitored using packets, and others with flows.
Physical or Virtual Monitoring Tools?
Often people ask us whether a physical box has advantages over a VM used to monitor traffic. IT trend is towards virtual but physical could help and could help you on the proof of concept scenario. Remember, there is not “best scenario” to follow. Virtual environment allow you to avoid possible hardware problems but require a dedicated physical NIC for TAP mode scenario, that isn’t always possible. Hardware could be easier but it can vary every time.
Technical requirements depends on what you need to see and collect, but the minimum should be:
- Intel CPU with two cores
- 4 Gb of RAM
- 120 Gb of Disk Space. SATA or SSD depend on the traffic you need to verify but SSD is preferred.
- 1 NIC. 1 NIC only for Flow Collector mode. 2 NIC, at least for TAP Visibility.
- Linux operating system. ntop builds prepackages packages for Debian, Ubuntu LTS and CentOS. You can choose the nitro you like, but if you ask us we suggest you to use Ubuntu LTS.
Most ntop software is open source, that for most people free of licensing fees. However even in the case of ntopng we offer premium versions that allows us to keep developing the product. Hence sot all the components are freely available so you need to choose the right deployment based on the budget or based on the feature you need. ntopng could run on community mode: it means that you can catch from the wire all the flows presented to ntopng via tap Interfaces but you are going to have limited functions and capabilities. If you choose to have all the features on, you need a simple ntopng Pro or Enterprise license.
Otherwise if you plan to add or to use flow collector mode, remember you need to buy a nprobe license to allow you to grab all the flows form devices and present them to ntopng, better if licensed so that you can have for instance full integration with other protocols such as SNMP. Probably, if you try both scenario, you will adopt a ntopng plus nprobe scenario (check main feature here https://www.ntop.org/products/traffic-analysis/ntop/).
PS: Many thanks to Giordano Zambelli for writing this post.