Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Best Practices for Configuring Active Flow Monitoring Version 9

 

Four settings control the behavior of active flow monitoring: Sampling rate, sampling run-length, flow active timeout, and flow inactive timeout. When you tune these settings, consider the following:

  • Choosing a higher sampling rate or higher run-length increases the load on the services PIC.

  • Selecting a higher sampling rate collects more information and provides finer grain flow information.

  • A nonzero run-length provides trailing context regarding the packets immediately following a triggered sample.

  • Selecting a larger active or inactive timeout value reduces the load on the export CPU and reduces the rate of packets going to the flow collector.

Active and Inactive Timeouts

A flow is considered inactive if a packet matching the filter is not received for a duration longer than the inactive timeout value.

Flow monitoring tracks flows as unidirectional streams of packets. It is not aware of application-level session properties or protocol details. However, there is some minimal awareness of TCP/IP properties. A flow is considered inactive when a TCP FIN, FIN-ACK, or RST control signal is received.

When the inactive timeout is triggered, the services PIC purges the flow from its flow table and generates an export record for the flow.

The inactive timeout can be set to as small a value as can be handled considering the load on the services PIC. The inactive timeout is typically several seconds (30 to 60 seconds). The administrator can tune the timeout to a larger value to try to reduce the load on the control CPU. The effectiveness of this setting for reducing CPU load depends on the overall input flow rate and the rate at which flows are expiring.

In a similar manner, an active timeout is triggered when the active timer expires and the flow is still active. The active timeout is intended to capture information about long-lived flows.

In the absence of an active timeout mechanism, a collector might not receive any information about a flow until it expires due to inactivity. Hence, the goal is to send periodic updates about a flow that has not expired.

When an active timeout is triggered, the flow start timestamp is not reset. Therefore, the collector can correlate a sequence of active timeout export packets and use the start time to identify long-lived flows, such as bulk transfers like FTP and peer-to-peer downloads of large files.

It is recommended to have a value higher than the default for the active timeout. Typical settings are in the range of several minutes (up to 10 minutes).

Sampling Rate

There is extensive research that helps identify the best choice for a sampling rate. Duffield et al (“Properties and Prediction of Flow Statistics from Sampled Packet Streams”, ACM SIGCOMM 2002) consider a variety of objectives and recommend heuristics and formulas to compute the sampling rate.

If the objective is to obtain an accurate measurement of the original number of packets, the error in an estimate derived from sampled packets reduces in proportion to the square root of the sampling rate. For example, if the sampling rate is 100 and the original number of packets is 1 million, the expected error is on the order of (100/1,000,000) or about 1 percent. In other words, if the sampled packet count is 10,000, the original packet count can be in the range 990,000 to 1.01 million. This agrees with the idea that a higher sampling rate reduces the error in estimation.

Sampling Run Length

The run-length statement specifies the number of matching packets to sample following the initial one-packet trigger event. By default, the run length is 0, which means that no more traffic is sampled after the trigger event. The range is from 0 through 20 packets. Configuring a run length greater than 0 allows you to sample packets following those already being sampled.