Powered by Zoomin Software. For more details please contactZoomin

Flowmon User Guide

Advanced Settings

  • Last Updated: May 5, 2026
  • 12 minute read
    • Flowmon Products
    • Flowmon
    • Documentation

In the Advanced settings tab, you can configure various options that affect the performance and capabilities of a Monitoring port in addition to the content of flow records originating from it.

Advanced settings tab

In the Optional Lx values for NetFlow/IPFIX record list, you can enable monitoring of additional information from the L2, L3/L4, and L7 layer. To view a full list of supported fields, refer to the following document: Flowmon Supported Flow Standards.

Note:

Each enabled option has an impact on the performance of the Monitoring port. Some other Flowmon modules (FPI Probe, APM Probe, and IDS Probe) also affect the performance of the Monitoring port when enabled.

Note:

For proper monitoring of optional values, it is highly recommended to connect the probe by a SPAN port because both directions of communication must be monitored by the same Monitoring port. If the probe is connected by TAP and each direction of communication is received by a different Monitoring port, then the monitoring capabilities can be limited or less accurate.

Any changes made on this tab are only applied after clicking Save.

Packet sampling rate

The Packet sampling rate defines the deterministic packet sampling (for example, sampling interval 1 in 3 packets) for incoming packets. Enter 0 to disable this feature.

Light mode

You can enable the Light mode to achieve maximum performance of a Monitoring port. This option is necessary for reaching wire-speed monitoring at 25Gbps and 100Gbps networks. This option disables monitoring of all additional information from the L2, L3/L4, and L7 layers. Decapsulation capabilities in Light mode are limited to VLAN and MPLS tunnel protocols.

Optional L2 values for NetFlow record

For L2, you can select monitoring of MAC, VLAN, and MPLS tags (MPLS is not supported for NetFlow v5). The Flowmon Probe supports parsing information from up to two VLAN tags (QinQ protocol) and up to four MPLS labels per packet.

You can add a MAC address, VLAN tag, and MPLS label to the list of flow identifiers (that is, SRC IP, DST IP, SRC port, DST port, L4 protocol) by checking Add L2 fields to the NetFlow identifier and selecting the desired identifier. We recommend extending flow identifiers in the following situations:

  • You have overlapping IP address spaces across VLANs or MPLS L3VPNs.
  • You must distinguish per-segment traffic across a multi-link (trunk) path through a device such as a router or firewall where the IP 5-tuple stays the same but the MAC address or VLAN ID changes at each hop. Adding MAC or VLAN to the key prevents all segments from collapsing into a single flow.
  • You must distinguish physical devices that share or rapidly reuse IP addresses (for example, short DHCP lease times or cloned virtual machines before readdressing).
Note:

Due to performance optimizations, it is possible that MAC, MPLS, or VLAN values may be missing in some flows.

Optional L3/L4 values for IPFIX record

For L3/L4, you can enable monitoring of extended values from L3/L4 (TCP TTL, TCP SYN packet size, and TCP window size) and Network Performance Monitoring metrics (NPM - see the Network Performance Metrics paragraph below for more information). All these values are available for the IPFIX protocol only.

Network Performance Metrics

The Flowmon Probe can monitor useful metrics which can be used to measure the quality of connection. All metrics are measured in microseconds. The NPM checkbox (Network Performance Metrics) enables the measuring of Round Trip Time, Server Response Time, TCP Retransmissions, and TCP Out of Order values. The NPM extended checkbox enables measuring of Jitter and Delay values. The metrics are listed below:

  • Round Trip Time - Network delay during TCP connection establishment (it is measured over TCP traffic only). In detail, it measures the time between SYN and ACK packets (between the first and second packets sent from the client). The metric is measured on flows sent from client to server only.

  • Server Response Time - Application delay for the first request of data. In detail, it measures the time between request acknowledgment by the server and the first packet of reply. The metric is measured on flows sent from the server to the client.

  • TCP Retransmissions and TCP Out of Order packets - Count of retransmitted and out of order packets in a TCP flow.

  • Jitter - The deviation from true periodicity of inter-packet gaps. It is measured for flows with three or more packets. In detail, it measures the delay between the first and second packet and then between the second and third packet. The difference of these two values is Jitter. The same applies to other packets. As an output, it provides average Jitter, min, max value, and standard deviation.

  • Delay - Inter-packet delay. In detail, it subtracts packet N and packet N-1 timestamps, and so on. As an output, it provides the average delay, min and max value, and standard deviation.

The detailed description of how the NPM metrics are calculated can be found in the Calculation of Flowmon NPM Metrics page.

Optional L7 values for IPFIX record

L7 options typically enable monitoring of specific application protocols. The monitoring functionality inspects packets and looks for communication of the selected protocol. We recommend only enabling the options that are necessary for your use case, because each enabled option has an impact on the performance of the Monitoring port (especially for 100 Gbps network interfaces).

DHCP

Enables monitoring of the DHCP protocol. It inspects UDP packets on standard ports 67 and 68.

DNS

Enables monitoring of the DNS protocol. It inspects UDP and TCP packets on standard port 53.

HTTP

Enables monitoring of the HTTP protocol. It inspects all TCP packets and looks for HTTP communication even on non-standard ports.

Email

Enables monitoring of the SMTP, POP, and IMAP protocols. It inspects TCP packets on standard ports 25, 587, 110, and 143.

NBAR2

Enables the detection of L7 protocols, which are exported in NBAR2 format.

Samba

Enables monitoring of the SMB protocol. It inspects TCP packets on standard port 445.

VoIP and Extended VoIP

Both options enable the monitoring of Session Initiation Protocol (SIP), which is an L7 signaling protocol used in Voice over IP technology (VoIP) for initiating, modifying, and terminating so-called sessions. Packet headers of SIP protocol contain information regarding initiated VoIP sessions (ID of the caller and the called party, how long the call was, whether it was initiated successfully, negotiated IP addresses and ports for Real-time Transport Protocol (RTP)). SIP protocol usually works over UDP on port 5060.

The difference between VoIP and Extended VoIP is that Extended VoIP also attempts to match the corresponding RTP and RTCP traffic to the initiated SIP session. This allows the user to see additional information regarding RTP traffic such as the audio or video codec which was used, the number of transmitted bytes and packets, traffic jitter, and the number of lost packets. However, matching RTP traffic with SIP sessions significantly impacts the performance of the Flowmon Probe appliance. Therefore, it is not recommended to use Extended VoIP on appliances where the expected network traffic rate exceeds 10 Gbps per Monitoring port.

These options are mutually exclusive.

MSSQL

Enables monitoring of the TDS protocol, which is a database communication protocol used by Microsoft SQL server. It monitors TCP packets on standard port 1433.

PostgreSQL

Enables monitoring of the database communication protocol used by a PostgreSQL database. The monitoring functionality inspects all TCP packets and looks for the PostgreSQL communication even on non-standard ports.

MySQL

Enables monitoring of the database communication protocol used by the MySQL database. The monitoring functionality inspects all TCP packets and looks for the MySQL communication even on non-standard ports.

QUIC

This option enables monitoring of QUIC protocol to parse QUIC version and Server Name Indication (SNI). When monitoring of the HTTP protocol is enabled, the SNI value is also filled into the HTTP hostname field and the HTTP method is set to SSL. The monitoring functionality inspects UDP traffic on port 443. Supported QUIC versions for SNI monitoring are:

  • Version 1 (defined by RFC 9000)
  • IETF draft versions starting from 22 to 34
  • Facebook's MVFST versions 1 and 2

TLS

The monitoring functionality inspects all TCP packets and looks for the TLS communication even on non-standard ports. There are four TLS options that can be enabled independently:

  • TLS main enables the monitoring of basic information from the TLS protocol. When monitoring of the HTTP protocol is enabled, the Server Name Indication (SNI) value is also filled into the HTTP hostname field and the HTTP method is set to SSL.
  • TLS client enables the monitoring of client-specific information from the TLS protocol.
  • TLS certificate enables monitoring of the server certificate information from the TLS protocol.
  • TLS JA3 enables the computation of the JA3 fingerprint from TLS flow records.

IEC 104

Enables the monitoring of the IEC104 protocol. IEC104 allows communication between two systems in electrical engineering and power system automation. The monitoring functionality inspects all packets even on non-standard ports.

COAP

Enables monitoring of the COAP protocol, which is a communication protocol in an IoT environment. It inspects packets on standard port 5683.

GOOSE

Enables monitoring of the GOOSE protocol. GOOSE is a peer-to-peer communication protocol used for information exchange between IEDs ( IED – Intelligent Electronic Device ) in a Substation over the Ethernet and is defined in IEC61850 standard. The monitoring functionality detects packets with the following EtherTypes:

  • 0x88b8 - Goose Type 1, Goose Type 1A

  • 0x88b9 - GSE Management

  • 0x88ba - Sampled Values

Packets with EtherType 0x88b8 are further inspected and monitored.

Note:

Because GOOSE packets do not contain IP addresses and are needed for proper flow analysis on the Flowmon Collector, the IPv6 addresses are generated and exported in GOOSE flows. The MAC addresses from the Ethernet layer are converted into link-local IPv6 addresses using a standard conversion mechanism.

MMS

Enables monitoring of the MMS protocol. MMS is a client-server protocol used for information exchange between IEDs (IED – Intelligent Electronic Device) and higher level devices (such as SCADAs) over the Ethernet and is defined in the IEC61850 standard. The monitoring functionality inspects all TCP packets and looks for the MMS communication even on non-standard ports.

DLMS

Enables monitoring of the DLMS protocol. DLMS is a protocol used for messaging to and from (energy) distribution devices. The monitoring functionality inspects all packets even on non-standard ports.

VxLAN

This option enables monitoring of the VxLAN VNI. If this option is enabled and Decapsulate is disabled, the VNI is added to the list of flow identifiers. This means that a new flow is created with every unique VNI. The VxLAN VNI is exported whether the Decapsulate option is enabled or disabled. All UDP packets where the source or destination port is equal to the number defined in the Port field (default 4789) are inspected.

Modbus

Enables monitoring of the Modbus protocol. It inspects TCP packets on standard port 502.

DNP3

Enables monitoring of the DNP3 protocol used in SCADA and energy automation environments. It inspects TCP packets even on non-standard ports.

S7COMM

Enables monitoring of the Siemens S7 communication protocol (S7comm) used for PLC programming and process data exchange. It inspects TCP packets even on non-standard ports.

MQTT

Enables monitoring of the MQTT publish/subscribe messaging protocol commonly used in IoT deployments. It inspects TCP packets on standard ports 1883.

Decapsulate tunnel protocols

Decapsulation options let the Monitoring port look inside supported tunneling or encapsulation protocols and build flows from the innermost (original) payload rather than from the outer transport headers. When you enable a decapsulation option:

  • The probe strips the recognized outer tunnel (and any nested supported tunnels in sequence) and classifies flows using the inner source IP, destination IP, L4 protocol, and ports (and any enabled extended identifiers such as VLAN, MPLS, or MAC) of the final decapsulated payload.
  • Outer (encapsulating) headers (for example, outer MAC or IP addresses, L4 ports) are not exported as part of the flow.
  • Flow counters (for example, bytes) apply to the inner traffic after decapsulation.

We recommend enabling decapsulation for known tunnels on your network to achieve accurate flow visibility and maximize the analytical value of flow records. Keeping encapsulation disabled preserves the outer addressing, which can be useful for capacity planning, or troubleshooting of the transport/overlay itself.

GRE

Enables decapsulation of Generic Routing Encapsulation (GRE) tunnels as described in RFC 1701 and RFC 2784.

ESP

Enables ESP tunnel parsing when the ESP payload is not encrypted. Due to the protocol characteristics, it is not possible for the Flowmon Probe to conclusively decide whether the ESP payload is encrypted from the packet payload alone. Therefore, if the traffic also consists of encrypted ESP packets, a very small portion of these packets may be misidentified, and subsequently incorrectly parsed.

VxLAN

Enables VxLAN decapsulation (RFC 7348). This option is a shortcut for enabling the VxLAN option under Decapsulate in the Optional L7 values for IPFIX record section.

ERSPAN

Enables decapsulation of Encapsulated Remote Switched Port Analyzer (ERSPAN) traffic (Type II and Type III). ERSPAN is typically used to encapsulate mirrored Layer 2 Ethernet frames inside GRE over IP and send them across a routed network to a remote analysis device (for example, a Flowmon Probe). GRE decapsulation is automatically enabled when ERSPAN decapsulation is enabled.

PPPoE

Enables parsing and decapsulation of PPP over Ethernet (PPPoE) session frames (RFC 2516).

4in6

This option enables parsing of decapsulated IPv4 network traffic transported over an IPv6 network as specified in RFC 2473.

When the 4in6 option is enabled, a subsequent option (Process as DS-Lite) is shown. Enabling this subsequent option allows the analysis of network traffic in the context of Dual-Stack Lite broadband deployments, as specified in RFC 6333. In such deployments, traditional 4in6 decapsulation that leads to the loss of the IPv6-related metadata is not sufficient, because the DS-Lite use-case requires unique identification of the originating Customer Premise Equipment (CPE) device (at Layer 3, this device is uniquely identified only by its IPv6 address). Therefore, it is desirable to retain the IPv6 addressing information and present it as the primary means of device identification of the collected flow data.

If the only enabled option is 4in6, then the exported flow contains a tunneled IPv4 source and destination addresses. The IPv6 addresses are not present in the flow. If both options are enabled, then the tunneled IPv4 address is mapped to the IPv6 address as specified in RFC 4291, section 2.5.5.

MPLS decapsulation mode

MPLS decapsulation mode allows you to select the type of MPLS decapsulation. The Flowmon Probe supports three modes of MPLS decapsulation:

  • Auto - this mode uses a heuristic to automatically detect the type of MPLS decapsulation.
  • EoMPLS (Ethernet over MPLS) - this mode is used for decapsulation of MPLS packets in which the payload is an Ethernet frame.
  • MPLS-IP (IP over MPLS) - this mode is used for decapsulation of MPLS packets in which the payload is an IP packet.

We recommend using Auto mode. Only select other modes if you suspect that the automatic detection is not working properly.

Packet deduplication

Depending on the placement of monitoring points within a network, a Flowmon Probe appliance may receive duplicated packets. The preferred way of avoiding duplicates is to select monitoring points and/or configure a traffic mirroring, TAP, or SPAN in such a way that multiple copies of the same packet will not reach the Flowmon Probe appliance. If other means are not available, packet deduplication can be used to identify and remove packet duplicates directly on the Monitoring ports of the Flowmon Probe appliance.

This option should be the last resort for removing duplicated packets that could not be dealt with by any other means. This functionality is computationally intensive and enabling it is going to negatively impact the monitoring performance of the appliance.

To start packet deduplication, enable Packet deduplication and specify the Deduplication interval in milliseconds. Duplicates received outside this interval will not be detected and removed. You can choose a value in the range of 1 to 1000 ms.

To identify duplicated packets, hashes of selected packet fields are used. The hash is a combination of a flow hash and a packet hash. Flow hash is computed from typical flow identification fields such as IP addresses, port numbers, and the L4 protocol number. The packet hash computation depends on the L4 protocol. For TCP, UDP and ICMP(v6) protocols the checksum field in the L4 header is used. For other protocols, the whole L4 header plus 64 bytes of payload data is used.

Because the checksum field in the UDP header is optional, this field is used for hash computation only if its value is different from 0. Otherwise, the hash of a UDP packet is computed the same way as for other protocols (L4 header and 64 bytes of payload).

If the hash of two received packets is the same and the interval between these packets is smaller than the chosen Deduplication interval, the second packet is considered to be a duplicate and is removed. Packet deduplication is primarily designed for deduplicating packets in pairs, as they would arrive when both the sender and the receiver of the packet are subject to the same traffic mirroring policy. In a general use case where one packet may have more duplicates, packet deduplication will decrease the number of duplicates but it will not remove them entirely.

Enabling packet deduplication will impact Flowmon's ability to correctly detect packet retransmission rates and report issues that use this metric as an indicator. A retransmitted packet will be treated as a duplicate if it arrives within the deduplication interval. Since packet duplication works with packets in pairs, Flowmon will be able to deduplicate and detect some retransmissions at the same time; however, the resulting packet retransmission statistics will be skewed.

Packet deduplication processes packets for every Monitoring port independently, duplicates passing through separate Monitoring ports will not be detected.

Autonomous systems list

You can select an autonomous systems list to allow the export of information concerning the source and destination autonomous systems (Origin AS method). Flow record fields with ID 16 (bgpSourceAsNumber) and ID 17 (bgpDestinationAsNumber) are filled with values based on the provided autonomous system list.

You can manage autonomous systems lists on the Autonomous Systems Lists page.

TitleResults for “How to create a CRG?”Also Available inAlert