In order to analyze network traffic, it’s necessary to feed ntop/nProbe with network packets. There are two solutions to the problem:

• port mirror (also called SPAN in Cisco parlance)
• network tap

Prior to explain the differences between these two solutions, it’s important to understand how ethernet works. In 100 Mbit and above, hosts usually speak in full duplex meaning that a hosts can both send and receive simultaneously. This means that on a 100 Mbit cable connected to a host, the total amount of traffic that a host can send/receive is 2 x 100 Mbit = 200 Mbit.

A port mirror is active packet duplication, meaning that a network device physically has the duty to copy packets onto a mirror port.

This means that the device has to carry on this task by using some resources (e.g. CPU) and that both traffic directions will be copied into the same port. As explained before, in full duplex links this means that the total of A->B and B->A can’t exceed the network speed before packet loss occurs. This because there’s physically no space to copy packets. The consequence is that a port mirror is a great technique as it can be performed by many switches (but not all) with the drawback of packet loss if you monitor a link with over 50% load, or mirror the ports onto a faster port (e.g. mirror 100 Mbit ports onto a 1 Gbit port). Not to mention that packet mirror might require switch resources that can load the unit and lead to reduced switching performance. Note that you can 1 port onto a port, or 1 VLAN onto 1 port, but usually you can’t copy many ports to 1. Please note that in this architecture, the switch is a point of failure as if it breaks the connectivity (and packet mirror) is lost.

A network tap instead is a fully passive device.

Electrically or optically (e.g. using a prism) packets are copied onto the tap ports. Unless you use an aggregation tap, a tap has one tap port per direction. This means that in order to monitor 1 link, you need 2 NICs, one for the first and the other for the second direction. In this case you won’t ever loose a single packet as in the mirror case, because each direction is using a link, instead of merging both directions onto the same link. If you want to merge both directions into one single port, you can use a network switch as depicted below:

As tap ports do not receive but transmit only, the switch has no clue who’s sitting behind the ports. The consequence is that it broadcast the packets to all ports. So if you connect your monitoring device to the switch, such device will receive all packets. Note that this mechanism works if the monitoring device does not send any packet to the switch, otherwise the switch will assume that the tapped packets are not for such device. In order to achieve that, you can either use a network cable on which you have not connected the TX wires, or use an IP-less (and DHCP-less) network interface that does not transmit packets at all. Finally note that if you want to use a tap for not loosing packets, then either don’t merge directions or use a switch where tapped directions are slower (e.g. 100 Mbit) that the merge port (e.g. 1 Gbit).

Bottom line. Packet mirror and tap have both pros and cons. You can select the right solution based on your network (and wallet).

If you want to know more about this topic, I suggest you to read this document named Multi-Tap Network Packet Capturing. It describes more in detail how to play with network taps and it highlights how to use NST (Network Security Toolkit, a Linux distribution that also includes ntop) in common network monitoring scenarios, where very likely your setup is also included.

Multi-Tap Network Packet Capturing