In this mode, you need to configure port mirror / SPAN / TAP from your switch or router device. We suggest using a separate interface for management connection with FastNetMon for reliability reasons.
Enable plugin for mirror capture:
sudo fcli set main mirror_afpacket enable
List all available interfaces for your system:
sudo fcli show interfaces
Enable capture for specific port (you may specify any number of ports):
sudo fcli set main interfaces em1 sudo fcli commit
Then enable port mirroring on the router or switch side.
By default, FastNetMon samples traffic 1 to 100 for better accuracy on low speeds, but if your capture 1G or more, we recommend increasing the sampling rate to at least 1 to 1000 to avoid traffic drops:
sudo fcli set main mirror_af_packet_sampling enable sudo fcli set main mirror_af_packet_sampling_rate 1000 sudo fcli commit
By default, FastNetMon relies on the Linux kernel to do packet sampling and then receives data using a single thread. If you use sampling, you must enable this mode, or you will have enormous traffic spikes during FastNetMon restart, which will lead to false positives:
sudo fcli set main mirror_af_packet_disable_multithreading enable sudo fcli commit
Each AF_PACKET socket has multiple counters for the number of packets dropped due to performance issues. This option is disabled by default, but you can easily enable it in the following way:
sudo fcli set main mirror_af_packet_socket_stats enable sudo fcli commit
After enabling this option, you will see two more counters for the following debug command:
sudo fcli show system_counters |grep socket
Example output:
socket_received_packets 0 socket_dropped_packets 0
If you do not use sampling (not recommended for production setups), FastNetMon will run 1 worker thread for each queue on the NIC. For many modern NICs number of queues is set to the number of active cores. In cases when your machine has many cores (16, 24 or more), it may lead to lock contention, and you will see all CPU cores busy, but traffic will be undercounted. In this case, we suggest setting a lower number of queues on the NIC in the following way:
sudo ethtool --set-channels eth4 combined 8
Another option to improve mirror capture performance is the fanout type. FastNetMon has support for the following fanout algorithms (for more details, please check this page in PACKET_FANOUT section):
- cpu
- lb
- hash
- random
- rollover
- queue_mapping
By default, FastNetMon uses “cpu”, but you can easily change it in the following way:
sudo fcli set main mirror_af_packet_fanout_mode cpu sudo fcli commi
Some routers, such as Juniper MX, have the capability to sample mirrored traffic on the router’s data plane. It’s a very good approach as it reduces the amount of traffic delivered from the router to the machine with FastNetMon and significantly reduces the amount of required CPU resources. To get the correct traffic, all data has to be multiplied by the sampling rate by FastNetMon. Port mirror has no options to encode the sampling rate in the traffic stream, and you need to specify it manually in the following way:
sudo fcli set main mirror_af_external_packet_sampling enable sudo fcli set main mirror_external_af_packet_sampling_rate 1000 sudo fcli commit
If you have any performance issues with this capture mode, we suggest testing the new experimental capture plugin: AF_XDP.
If you’re looking for GRE support, please check this article.
Starting from version 2.0.368, you can use GTPv1 tunnel stripping capability, which can be enabled this way:
sudo fcli set main af_packet_extract_gtp_v1_tunnels true sudo fcli commit
By default FastNetMon uses packet length as received from the interface for bandwidth calculation but on some platforms you may prefer to deliver first X bytes of packet instead of delivering full packet (“mirror first 64” on Cisco ASR 9000 or “maximum-packet-length 100” on Juniper MX) and in this case you need to switch FastNetMon to read packet length from IP header that way:
sudo fcli set main af_packet_read_packet_length_from_ip_header true sudo fcli commit