FastNetMon supports many different implementations of 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 default port for Netflow protocol). You may add multiple ports if you prefer:
sudo fcli set main netflow_ports 2055
Then specify interface for listening (0.0.0.0 is default):
sudo fcli set main netflow_host 0.0.0.0
To listen on IPv4 and IPv6 protocols on same port you need to set host to following value:
sudo fcli set main netflow_host :: sudo fcli commit
If your run any kind of firewall on your network or on server with FastNetMon itself you will need to allow traffic over ports you’ve added towards 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 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 safe default we recommend setting active and inactive flow timeout for routers to 30 seconds. We do not recommend setting timeouts to very low values as it may overload router’s CPU.
In addition to flow timeout setup on router side you need to adjust average_calculation_time value on FastNetMon side. This value must exceed both active and inactive flow timeouts by 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 router uses correct flow duration using this command
sudo fcli show system_counters|grep duration
Apply changes and restart daemon:
sudo fcli commit
After this steps you need to configure Netflow / IPFIX on agent’s side (switch, router, server) to configured port.
If you run Juniper MX, Cisco ASR 9000, Cisco NSC 5500 based routers we recommend using modern protocols such us IPFIX 315 and Inline Monitoring services as both of them offer best detection speed and provide excellent traffic bandwidth calculation accuracy. You may find detailed configuration guide here. Othwerwise please follow guide below.
We have detailed guides for 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 counter about 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 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 number of following counter:
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 machine it will show drops for both services what makes debugging more complicated.
To pin point traffic drop issues we have alternative option to read UDP traffic which offers option to count 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 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 some cases when this counter does not track dropped packets even if drop occurred on FastNetMon’s socket.
If your network has very large amount of Netflow traffic (50+ Mbits of telemetry) you may reach limitation of single CPU core for Netflow parsing and in this case you may not see all traffic. To confirm such cases we recommend enabling option to show custom thread names in htop (F2, Display options, Show custom thread names).
FastNetMon has 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 thread and will spread traffic between them and it will reduce CPU pressure on particular CPU core. Unfortunately, traffic distribution between threads is not very predictable and may not be even. You may use more then 2 cores but we recommend not setting it to very large value as it will cause lock contention and will slow processing.
If you see significant differences in amount of traffic each Netflow worker threads 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
Could I use nfcapd or other Netflow forwarders?
Yes, you could. But all your devices should have unique source_id. Because we use agent_ip + source_id as unique identifier for templates. If you use Netflow forwarders/aggregators they replace agent’s IP by forwarder’s IP and you could hit templates conflict. Result of this conflict could be very dangerous: completely incorrect traffic calculation and dangerously high risk of false positive alerts.
Why flow counters are zero?
If you use sampling then due to sampling theory limitations we cannot calculate flow / second correctly.