FastNetMon supports many different implementations of the standard NetFlow protocol:
- NetFlow v5
- NetFlow v9
- IPFIX
- NetFlow Lite
- Inline monitoring services
- Netstream
- jFlow
- cFlow
You can enable NetFlow plugin this way:
sudo fcli set main netflow enable
Specify port for Netflow capture (2055 is the default port for the Netflow protocol). You may add multiple ports if you prefer:
sudo fcli set main netflow_ports 2055
Then specify the interface for listening (0.0.0.0 is the default):
sudo fcli set main netflow_host 0.0.0.0
To listen on IPv4 and IPv6 protocols on the same port, you need to set the host to the following value:
sudo fcli set main netflow_host :: sudo fcli commit
If you run any kind of firewall on your network or on a server with FastNetMon itself, you will need to allow traffic over ports you’ve added towards the machine with FastNetMon.
FastNetMon could automatically extract sampling rate from Netflow v5, v9 and IPFIX, but in some rare cases, you should specify it explicitly
sudo fcli set main netflow_sampling_ratio 1 sudo fcli commit
The most important part of NetFlow / IPFIX configuration is the flow timeout setup. If you do not configure active and inactive flow timeouts correctly, then FastNetMon will not be able to calculate bandwidth correctly and traffic measurements will be wrong and it will lead to incorrect attack detection.
As a safe default, we recommend setting the active and inactive flow timeout for routers to 30 seconds. We do not recommend setting timeouts to very low values, as it may overload the router’s CPU.
In addition to flow timeout setup on the router side, you need to adjust average_calculation_time value on FastNetMon side. This value must exceed both active and inactive flow timeouts by a few seconds.
In case of standard setup with both active and inactive timeouts set to 30 seconds, we can recommend setting it to 45:
sudo fcli set main average_calculation_time 45 sudo fcli commit
To simplify flow duration configuration, we have official guides for multiple popular vendors below.
You can confirm that the router uses the correct flow duration using this command
sudo fcli show system_counters|grep duration
Apply changes and restart the daemon:
sudo fcli commit
After these steps, you need to configure Netflow / IPFIX on the agent’s side (switch, router, server) to the configured port.
If you run Juniper MX, Cisco ASR 9000, Cisco NSC 5500-based routers, we recommend using modern protocols such as IPFIX 315 and Inline Monitoring services as both of them offer the best detection speed and provide excellent traffic bandwidth calculation accuracy. You may find a detailed configuration guide here. Otherwise, please follow the guides below.
We have detailed guides for the following vendors:
- Juniper inline monitoring services (recommended)
- Juniper IPFIX
- Cisco IPFIX 315 (recommended)
- Cisco ASR 9000 Series Netflow
- Cisco ASR 1000 Series Netflow
- Nokia
- Netgate TNSR
- Huawei
- Mikrotik
- A-10 Networks
- VyOS
If you operate many devices which export Netflow or IPFIX, you may need better visibility about which device actually exports traffic to FastNetMon. To implement it, you will need to enable this flag:
sudo fcli set main netflow_count_packets_per_device true sudo fcli commit
And then you will be able to see the counter for the number of UDP packets received from each device using these commands:
sudo fcli show netflow9_packets_per_device sudo fcli show netflow5_packets_per_device sudo fcli show ipfix_packets_per_device
On deployments with a significant amount of Netflow / IPFIX traffic, you may face issues with UDP traffic drops due to UDP buffer overflow. You may detect such cases by increasing the number of the following counters:
sudo fcli show system_counters |grep global_system_rcvbuferrors; sleep 1; sudo fcli show system_counters |grep global_system_rcvbuferrors;
This counter is system-wide and if you have other UDP-based services on the machine, it will show drops for both services which makes debugging more complicated.
To pinpoint traffic drop issues, we have an alternative option to read UDP traffic, which offers the option to count the number of packets dropped due to UDP buffer size issues:
sudo fcli set main netflow_socket_read_mode recvmsg sudo fcli commit
After that change, you will be able to see an additional system counter which counters packets dropped on FastNetMon’s UDP socket:
sudo fcli show system_counters|grep drops netflow_ipfix_udp_packet_drops 0
Unfortunately, there are cases where this counter does not track dropped packets, even if the drop occurred on FastNetMon’s socket.
If your network has a very large amount of Netflow traffic (50+ Mbits of telemetry), you may reach a limitation of a single CPU core for Netflow parsing, and in this case, you may not see all traffic. To confirm such cases, we recommend enabling the option to show custom thread names in htop (F2, Display options, Show custom thread names).
FastNetMon has an option to run multiple threads for Netflow processing per port, and it can be enabled this way:
sudo fcli set main netflow_multi_thread_processing true sudo fcli set main netflow_threads_per_port 2 sudo fcli commit
After that, you will see that FastNetMon will spawn 2 threads and will spread traffic between them, and it will reduce CPU pressure on a particular CPU core. Unfortunately, traffic distribution between threads is not very predictable and may not be even. You may use more than 2 cores, but we recommend not setting it to a very large value as it will cause lock contention and slow processing.
If you see significant differences in the amount of traffic each Netflow worker thread receives, you may consider using BPF-based load balancing logic (available starting from 2.0.348), which will distribute traffic evenly. You can enable it that way:
sudo fcli set main netflow_multi_thread_mode random sudo fcli commit
Can I use nfcapd or other NetFlow forwarders?
Yes, you can. But all your devices should have a unique source_id. Because we use agent_ip + source_id as a unique identifier for templates. If you use NetFlow forwarders/aggregators, they replace the agent’s IP with the forwarder’s IP, and you could encounter a template conflict. The result of this conflict could be very dangerous: completely incorrect traffic calculation and dangerously high risk of false positive alerts.
Why are flow counters zero?
If you use sampling, then due to sampling theory limitations, we cannot calculate the flow / second correctly.
Can I limit devices which can send Netflow v5, v9 or IPFIX to FastNetMon?
Starting from 2.0.373 you can specify a list of IP addresses of devices which can send traffic telemetry to FastNetMon in the following way:
sudo fcli set main ipfix_devices_allow_list 10.0.0.0.1 sudo fcli set main ipfix_devices_allow_list 10.0.0.0.2 sudo fcli set main netflow_v9_devices_allow_list 10.0.0.0.3 sudo fcli set main netflow_v5_devices_allow_list 10.0.0.0.4 sudo fcli commit
As soon as you add at least a single element into any of these lists, FastNetMon will start blocking telemetry from all IPs which do not belong to the list.