17. Components » Flow Sensor

Most routers and many enterprise switches can collect IP traffic statistics and export them as flow records to Flow Sensor. Because the flow protocol pre-aggregates traffic data, the flows sent to Flow Sensor are significantly smaller than the traffic being monitored. This makes Flow Sensor ideal for monitoring remote or high-traffic networks. For a comparison of flow-based and packet-based monitoring, see the Choosing a Method of Traffic Monitoring chapter.

Appendix 2 shows how to enable NetFlow, sFlow, or IPFIX on a number of devices, but the best and most up-to-date instructions can only be found in the vendor’s documentation.

To add a Flow Sensor, click [+] in the title bar of the Configuration » Components panel. To modify an existing Flow Sensor, go to Configuration » Components and click its name.

Flow Sensor Configuration parameters:

● Sensor Name – A short name to identify the Flow Sensor

● Sensor Visibility – Controls whether the Flow Sensor appears in Reports » Devicesa

● Device Group – Optional label for organizing components by location, characteristics, or for granular role-base access

● Sensor Server – Select a server that fulfills the minimum system requirements for running the Flow Sensor. If this is not the Console server, follow the NFS configuration steps to make the flow data visible in the web interface

● Sensor License – The license used by the Flow Sensor. Wanguard provides all features; Wansight does not provide traffic anomaly detection and reaction

● Listener IP:Port – The IP address (IPv4 or IPv6) and destination port on which flow packets are received. Each flow exporter must use a unique destination port if multiple exporters are sending flows to the same server

● Flow Protocol – The flow protocol used by the flow exporter:

▪ Netflow or IPFIX – Select if your router exports NetFlow v5, v7, v9 or IPFIX, then click on the options button on the right-hand side of the field for Netflow-specific options:

• Long Flows Timeout – For routers like Juniper MX that maintain the start time of previously exported flows, set this to the flow active/inactive timeout in the router’s config (commonly 60 seconds). For other exporters, leave None

• Sampling (1/N) – Enter the sampling rate configured on the exporter, or leave the default if no sampling is set

• Force Sampling Value – Override the exporter’s reported sampling value if misread

▪ sFlow – Choose this if your router exports flows using the sFlow protocol

● Exporter IP – IP address of the flow exporter (router, switch, or probe). For sFlow, specify the IP actually sending the flow packets (not the Agent IP)

● Exporter SNMP – You must enable SNMP on the flow exporter to allow Console to extract interface information automatically

▪ Enabled – Click the Options button beside Exporter SNMP to configure:

▪ Disabled – If SNMP is not set up, you must manually add each interface and specify its SNMP index, speed, etc.

● IP Zone – Flow Sensor uses the IP Zone to learn the network’s boundaries and apply per-subnet setting

● Flow Collector – When enabled, raw flow data is saved to disk. You can query flow records in Reports » Tools » Flows, and limit disk usage in General Settings » Data Retention

• Flow Filtering Expression - Restricts which flows are analyzed. Click the bookmark icon to see the correct syntax

• Repeater IP:Port – Enter the IP and port of another flow collector to which Flow Sensor will forward flow packets

• Compression Algorithm - Flow Sensor supports LZO, BZ2, LZ4, or ZSTD for compressing raw flow data. LZO is fastest, BZ2 has the best compression ratio (though ~30 times slower), and LZ4/ZSTD balance speed and efficiency

• Compression Threads - Allows multiple threads for compressing raw flows. Typically, 1 thread suffices. If CPU usage exceeds 50%, consider raising this number

• Compression Level - For LZ4 or ZSTD, specify a custom level. If empty or 0, the default compression level is used

● IP Validation – This parameter is frequently used for distinguishing the traffic’s direction (relative to the monitored network):

▪ Off – Disables IP Validation

▪ On – Flow Sensor examines only flows in which the source IP and/or destination IP belongs to the IP Zone. Traffic with a destination IP in the IP Zone is inbound. Traffic with a source IP in the IP Zone is outbound. This simplifies interface configuration (direction can be Auto), but inbound/outbound traffic is considered entering/exiting the network, rather than a specific interface (like SNMP Sensor and any other SNMP-based tool)

• Log Invalidated Flows – When set to Periodically, the event log shows the percentage of invalidated flows and lists ten flows that fail IP validation once every ten ticks

▪ Strict – Flow Sensor processes only flows where either the source or the destination IP is in the IP Zone

▪ Exclusive – Flow Sensor processes only flows with a destination IP inside the IP Zone

● AS Validation – BGP-enabled routers can export flows that contain the source and destination ASN (Autonomous System Number). In most cases, if the AS number is set to 0, then the IP address belongs to the local ASN. This option is rarely used for establishing traffic direction. AS Validation provides three choices:

▪ Off – Disables AS validation

▪ On – Flow Sensor processes only flows in which the source ASN and/or destination ASN is in the Local AS List (defined below).

• Local AS List – Enter your AS numbers, separated by spaces

• Log Invalidated Flows – When set to Periodically, the event log reports the percentage of invalidated flows and shows ten flows that fail AS validation every ten ticks

▪ Strict – Flow Sensor processes only flows in which either the source or destination ASN is in the Local AS List

● Granularity – Lower values improve Sensor graph accuracy but consume more RAM. The default 20-second interval is recommended for most setups

● Time Zone – Indicate the offset between the Flow Sensor server’s time zone and that of the flow exporter. It’s crucial to run NTP on both devices to keep their clocks in sync

● Monitored Interfaces – This grid lists all interfaces to be monitored. To avoid duplicate flow entries, it’s best to add only upstream interfaces. Click Add Interface to add interfaces one by one, or click Manage Interfaces to add multiple interfaces in bulk

▪ SNMP Index – Each interface is identified by its SNMP index. If SNMP is configured, Flow Sensor can auto-fill this number. Otherwise, retrieve it from the flow exporter and enter it manually

▪ Interface Name – Short descriptive name for the monitored interface. Descriptions longer than ten characters may clutter some reports

▪ Interface Color – Used in graphs. The default is random, but you can choose a different color from the drop-down menu

▪ Traffic Direction – Defines how traffic entering the interface relates to your network:

• Auto – Recommended in most scenarios. Direction is determined by IP/AS Validation or by the router (if supported in flow data)

• Upstream – For peering or internet-facing interfaces

• Downstream – For interfaces connected to your own network or customers

• Null – Traffic on these interfaces is discarded and thus ignored by Flow Sensor

▪ Stats Engine – Determines which traffic tops and AS (Autonomous System) data are collected:

• Basic – Enables tops for internal IPs (IPs within the IP Zone), IP protocols, TCP/UDP ports, and IP versions

• Extended – Includes Basic tops plus upstream ASNs and countries. If the router doesn’t export AS info in flows (e.g., non-BGP router), Flow Sensor uses a GeoIP database that might be slightly outdated. Performance impact is minimal

◦ Refresh Interval – Specifies how often the MRT file is reloaded in RAM. If set to Auto, it reloads whenever modified. If set to Never, it loads only when the Sensor starts

◦ BGP Dump File – If this field points to a valid BGPd MRT file file, Flow Sensor can show tops and graphs for Transit ASNs

◦ BGP Router IPv4/IPv6 – If you’ve specified a BGP Dump File, also enter the next-hop router’s IP address(es). You can find the NEXT_HOP in bgpdump output

• Full – Includes everything from Extended, plus external IPs (those not in the IP Zone). This setting can significantly increase RAM usage during spoofed attacks with randomized source IPs. It also enables threshold detection for external IPs, and ensures more accurate live AS and country stats

▪ Link Speed In & Link Speed Out – Specify the interface’s bandwidth or capacity. These values enable percentage-based reports and bits/s thresholds

● Comments – Enter remarks about the Flow Sensor. These notes are for internal reference only and will not appear elsewhere

To start the Flow Sensor, click the on/off button next to its name in Configuration » Components. Watch the event log and the traffic metrics in Reports » Devices » Overview to ensure it starts successfully. If traffic values remain incorrect after 5 minutes, try the troubleshooting steps listed below.

Note

For more details on attack sources detected by Flow Sensor, add a Flow Filter (default parameters are fine) and enable it in the “When an anomaly is detected…” panel of the Response. If the network supports BGP Flowspec, you can also mitigate DDoS attacks directly on the router by configuring a GoBGP Connector or ExaBGP Connector.

17.1. Flow Sensor Troubleshooting

✔ Check for any warnings or errors related to the Flow Sensor in the event log

✔ Go to Help » Software Updates to ensure you’re on the latest version

✔ Verify that each Flow Sensor parameter is correctly set (see the previous section for details)

✔ Verify the server is indeed receiving flow packets on the configured Listener IP:Port by executing the following command which shows the first 100 packets received from the flow exporter:

[root@localhost ~]# tcpdump -i <interface_eth0_p1p1_etc> -n -c 100 host <flow_exporter_ip> and udp and port <destination_port>

✔ Ensure the local firewall allows Flow Sensor to receive flow packets:

[root@localhost ~]# ufw status || firewall-cmd --list-all || iptables -L -n -v && iptables -t raw -L -n -v

✔ Confirm both the server and flow exporter have their clocks synced, ideally via the same NTP server. If they’re in different time zones, adjust Time Zone.

[root@localhost ~]# ntpq -p || chronyc tracking || timedatectl status

✔ Confirm that packets aren’t being dropped by reverse path filtering:

[root@localhost ~]# netstat -s | grep Filter

✔ If it takes too long for Flow Sensor to detect attacks, set your flow exporter to export flows more frequently. You can see the maximum flow export time in the Flow Delay column under Reports » Devices » Overview. Setting the Granularity parameter to 5 seconds may speed up detection. Some exporters need tens of seconds to assemble and export flows; if quicker detection (<1s) is vital, consider using Packet Sensor instead.

✔ If the event log receives a warning like Received flow <starting/ending> <X> seconds ago, check the following:

▪ When the warning refers to the starting time, make sure that the server’s clock and flow exporter’s clock are synchronized and that the time zone is set correctly on both devices. For some routers, such as Juniper MX, it is necessary to set the Flows Timeout parameter to the same value (usually 30 seconds) as the one configured on the router. These routers maintain the start time of exported flows

▪ When the warning refers to the ending time, make sure that the clocks are synchronized, the time zone is set correctly, the flow exporter is properly configured, and the PFC PIC is not overloaded (on Juniper in particular). If the number of seconds is around a multiple of 8600 seconds (1 hour), then the time zones may not be the same on both devices

▪ In some JunOS versions, there is a flow export rate limit with a default of 1k pps, which leads to flow aging errors. To raise the limit to 40k pps you need to execute:

set forwarding-options sampling instance NETFLOW family inet output inline-jflow flow-export-rate 40

▪ Some Cisco IOS XE devices do not export flows using NetFlow version 5 in under 5 minutes, even when configured to do so. In this case, switch to using Flexible NetFlow

▪ In order to provide fast and up-to-date traffic statistics, Flow Sensor accepts only flows describing traffic that started and ended in the last 5 minutes. All flows aged and exported with a delay exceeding 300 seconds are therefore ignored. This is a design decision that can’t be changed

▪ Flow Sensor does not misinterpret the start/end time of flows. Some flow exporters are known to have bugs, limitations, or inconsistencies regarding flow aging and stamping flow packets with the correct time. In this case, contact your vendor to ensure that the flow exporter is correctly configured, runs the latest firmware, and can expire flows in under 5 minutes. In some cases, a router reboot will fix all these issues

▪ You can double-check whether the Flow Sensor’s time and the flow’s start/end time differ by more than 300 seconds by inspecting the raw flow data. In Reports » Tools » Flows » Flow Records, select any interface of the Flow Sensor, set Display to Extended, and generate a listing for the last 5 minutes:

◦ Column “Received Time” indicates the time when the Flow Sensor received the flow packet, according to the clock of the server

◦ Column “Start Time” indicates the time when the flow started, according to the clock of the flow exporter

◦ Column “Stop Time” indicates the time when the flow ended, according to the clock of the flow exporter

✔ The event log warning Sensor frozen for <X> seconds. Restarting the collector can have several causes. It is generated when the flow packets are too scarce (1 every few seconds), or when flow packets are not received for tens of seconds (e.g., due to a network outage or router reload). Another cause indicates a performance issue, with the Flow Sensor not having enough CPU and I/O resources to analyze traffic and send data to the SQL server in a timely manner. In this case, use a physical server instead of a virtual machine, or decrease from the IP Zone the IP graphs and IP accounting data that need to be collected

✔ If you don’t see traffic on some/all of your monitored interfaces, but you see in Reports » Devices » Overview that the Flow Sensor is receiving flows (in the “Flows/s” column), you need to check if you have correctly configured the flow exporter to send flows to the server for each of the monitored interfaces. To list the interfaces that are actually sending flows, go to Reports » Tools » Flows » Flow Tops, select any Flow Sensor interface, set Top Type to Any Interface, check Include Unmonitored Ifs in the Display Options selector, and generate a top for the last 10 minutes. The column “In/Out If” lists the SNMP index of every interface that exports flows, even if it wasn’t configured as a monitored interface in the Flow Sensor configuration

✔ When you add interfaces with the Traffic Direction parameter set to Auto, and IP Validation is being used, make sure that the IP Zone you have selected contains all your IP blocks. To capture a sample of flows failing validation in the event log, set the Log Invalidated Flows parameter to Periodically

✔ The traffic readings of the Flow Sensor may differ from other SNMP-based monitoring tools. If IP Validation is enabled, Flow Sensor counts In/Out traffic as traffic entering/exiting the IP Zone, unlike SNMP-based tools which show In/Out traffic as traffic entering/exiting the interface. To see if the traffic readings differ, add an SNMP Sensor and configure it to monitor the same flow exporter and the same interfaces (the Interface Discovery parameter from the Components » SNMP Sensor section will make this very easy)

✔ If the Flow Sensor does not show the correct statistics after upgrading the router’s firmware, the SNMP index of each interface has probably changed. In this case, adjust the SNMP indexes of the monitored interfaces manually, or redefine them

✔ If you only see statistics for a single traffic direction, either inbound or outbound, go to Reports » Tools » Flows » Flow Records and generate a listing for the last 10 minutes. If all your IPs are listed in a single column, check the flow exporter’s configuration and feature list. Not all devices can export flows in both directions or with the same SNMP index. Some Brocade routers are known to generate only inbound sFlow

✔ Flow Sensor could crash during spoofed attacks for not having enough RAM if a monitored interface has the Stats Engine parameter set to Full. It is highly recommended to set this parameter to Extended, especially on systems that don’t have enough RAM

✔ If the registered traffic is too low after upgrading to JunOS 15.1F2 or 16.1R1, execute:

set chassis fpc inline-services flow-table-size ipv4-flow-table-size 15

✔ To troubleshoot Sensor graph or IP graph issues, follow the Graphs Troubleshooting guide

✔ The event log error License key not compatible with the existing server indicates that the server is unregistered and you need to send the string from Configuration » Servers » [Server] » Hardware Key to sales@andrisoft.com