Have you ever been monitoring network traffic and been suspicious of NetFlow overstating utilization? The first thing to consider is the interface speed, is it set correctly as generally this information is pulled from the device using SNMP and sometimes the interface speed is set incorrectly. Secondly, if it was a network traffic trend using NetFlow that you were looking at, you may want to verify that the command ip flow-cache timeout active 1 had been configured on the Cisco router. Without this command entered into the NetFlow configuration, the trends will likely be overstated and understated at times. This article explains how and why flows are exported.
Conventional network traffic entries in the flow cache table are exported when one of four events occur:
- The active timer expires for long-lived flows. Generally this is set to 60 seconds as most reporting tools like to report on data with a granularity of 1 minute intervals. For example, if a connection or flow to download a file takes 4.5 minutes, the delta byte count would export the contents of the flow record every 60 seconds. In the fifth minute, the flow would end and the remaining delta bytes and packets with the flow are exported. The flow entry is also removed from the flow cache. Alternatively, if the active timeout is configured for a longer interval (e.g. every five minutes), a flow that lasts 2 or 3 minutes could get its data exported all at once. The potential problem with an active timeout of 5 minutes: If the reporting tool expects the data in 1 minute intervals, spikes greater than 100% utilization will likely be displayed in the data trend. To avoid this problem, always set the active timeout for 60 seconds.
- The flow becomes inactive after a period set by a parameter known as the inactive timeout. Often times this is set at 15 seconds (e.g. this could happen if no traffic is seen on a TCP connection or if the flow is using UDP).
- The flow ended as observed by the TCP flags: Finished (FIN) or reset (RST). NOTE: not all hardware platforms support this.
- Flows are exported early if the flow cache becomes full. Cisco calls this emergency expire where flows are randomly chosen for early expiry at 90% of the cache being full.
Up to 30 flows can be placed into a NetFlow v5 datagram and up to 24 flows (unless fields exported are modified) in a NetFlow v9. The flows exported end up consuming about 1.5% of the switched traffic in the router which is considered very efficient and this is all while capturing 100% of the traffic. Once the flows are exported and collected by a server, they are ready for reporting. Now, what transport layer protocol are you using to export the flows?
Export using UDP or SCTP?
In the youtube video “The Four Steps to Configuring Flexible NetFlow,” Step 2 specified a command “transport udp 2055”. The port may change but, UDP is by far the most popular transport layer to send flow data with however, it is not the only option. Because UDP is an unreliable mechanism for sending datagrams across the network, Cisco provides a 2nd option called the Stream Control Transmission Protocol (SCTP). Since there are plenty of materials on the Internet that cover this protocol, only a short paragraph is needed here.
In computer networking, the Stream Control Transmission Protocol (SCTP) is a transport layer protocol, serving in a similar role to the popular protocols Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP.
Although UDP cannot help guarantee delivery, the engineers at Cisco did provide a mechanism for collectors to determine if flows are missing. It is called the flow sequence number. Obviously, missing flows would cause understating utilization which of course would be another blog topic.