This article provides an introduction to flow and the configuration of routers to collect and export it.
Note: For information on configuring devices to send flow to Kentik, see Router Configuration and Host Configuration.
About Flow
Flow records are metadata about IP conversations that traverse devices like routers, switches, or hosts. If enabled, a device can collect flow records in a cache and export them to a destination (e.g., Kentik) at a specified interval.
For instance, if IP 1.1.1.1
sends packets to 2.2.2.2
through a flow-enabled device, the conversation is captured in a flow record that includes these basic fields:
Flow Field | Description |
---|---|
source IP | Source IP address |
dest IP | Destination IP address |
protocol | IP protocol type (for example, TCP = 6; UDP = 17) |
L4 source port | TCP/UDP source port number or equivalent |
L4 dest port | TCP/UDP destination port number or equivalent |
TCP flags (logical OR) | Cumulative OR of TCP flags |
input interface ID | SNMP index of input interface |
output interface ID | SNMP index of output interface |
byte count | Total number of Layer 3 bytes in the packets of the flow |
packet count | Packets in the flow |
ToS / DSCP value | IP type of service (ToS) |
next-hop IP | IP address of next hop router |
Note: For a list of devices that can send flow to Kentik, see Supported Device Types.
Flow Protocols
Four primary protocols exist for flow data, and Kentik accepts them all. Kentik recommends you choose a protocol based on what the router/switch supports and handles most efficiently. Where multiple protocols are supported, Kentik recommends them in this order:
sFlow: Designed by the sFlow.org consortium as a statistical monitoring tool for networks; configurable through SNMP.
IPFIX (Internet Protocol Flow Information Export): Created by the Internet Engineering Task Force (IETF) as a universal standard for exported flow data.
NetFlow version 9: Cisco flow protocol that is compatible with and nearly identical to IPFIX.
NetFlow version 5 (known as “JFlow” on Juniper devices): An earlier Cisco flow protocol.
Here are some supported features of the various protocols:
Features | NetFlow v5 | NetFlow v9 | IPFIX | sFlow |
---|---|---|---|---|
Basic flow fields | Yes | Yes | Yes | Yes |
Embedded sampling rate | Yes | No | Yes | Yes |
IPv6 support | No | Yes | Yes | Yes |
MAC address fields | No | Via custom template on some platforms | Via custom template on some platforms | Yes |
VLAN ID fields | No | Via custom template on some platforms | Via custom template on some platforms | Yes |
Includes payload sample | No | No | No | Yes |
Note: Some routers and switches will not report layer-2 traffic; they only report flows as they traverse a layer-3/route decision. For more information, consult your device vendor.
Flow Sampling
Flow sampling exports a flow record for only one in every X flows. When X is 1, then flow is unsampled (a record is generated for every flow), but when X is 10,000, a record is generated for one out of every 10,000 flows. Thus, the sampling rate (total vs sampled flows ratio) and resolution are inversely related, meaning a lower rate (100) is higher resolution than a higher rate (10,000).
While it's tempting to assume that accuracy requires the lowest possible rate (e.g., 1), testing by Kentik and others shows that even high sampling rates can accurately measure small traffic flows for common use cases (see our blog post Accuracy in Low-Volume Flow Sampling).
Why Flow Sampling
Flow sampling improves resource utilization devoted, enabling more network infrastructure to be covered for a given expenditure. It’s recommended regardless of the size of your operation for the following reasons:
Reduces device cycles for flow processing and collection.
Reduces network utilization (bandwidth) for sending flow data.
Enables real-time flow data visibility (unsampled data may be held for minutes or longer).
Sampling is especially important during unexpected high traffic volumes, such as attacks or high PPS events. Routers may be overwhelmed and stop processing flow, causing loss of visibility at critical times for data collection and analysis.
Optimal Sampling Rates
For a network device, the ideal sample rate both captures critical information and efficiently handles peaks. Optimal rates vary by device role, desired flow record dataset resolution (dependent on use case), and total active throughput. Kentik analyzed hundreds of devices in live production accounts to provide recommended sample rate ranges:
|
| Sampling rate (flows per sample), by max device throughput | |||
---|---|---|---|---|---|
Device role | Resolution | 1 Gbps | 10 Gbps | 100 Gbps | 1 Tbps |
Edge/Internet-facing | Standard | N.A. | 3000 - 7000 | 8000 - 10,000 | 11,000 - 15,000 |
Edge/Internet-facing | Enhanced | N.A. | 2000 - 4000 | 5000 - 7000 | 8000 - 10,000 |
Data Center and Core | Standard | 400 - 800 | 1000 - 1500 | 10,000 - 20,000 | 25,000 - 50,000 |
Data Center and Core | Enhanced | 200 - 400 | 500 - 800 | 5000 - 14,000 | 15,000 - 30,000 |
Notes:
Device vendors use various algorithms for flow sampling, and Kentik supports them all.
For sample rate considerations specific to hosts, see Sample Rate for Hosts.
For questions or help calculating the proper sampling rate for your environment, contact Customer Care.
Ingress and Egress
Depending how the device is configured, it creates flow by examining traffic at one of the following points:
Ingress: As traffic enters an interface
Egress: As traffic exits an interface
Kentik recommends you:
Enable flow on all interfaces.
Configure all devices for ingress flow creation only.
Enabling ingress flow creation on all interfaces provides a comprehensive view of all traffic traversing the router. Kentik groups flows destined for an interface as they enter the router from other interfaces.
Enabling both ingress and egress flow creation may result in double counting. Kentik helps you catch this by reporting both flow and SNMP traffic for an interface. The flow traffic should be within 20 percent of the SNMP recorded interface traffic.
Note:
NetFlow was designed for this scenario, but it now supports egress flow creation for special cases like compression and VPN services.
Kentik does not remove duplicate flows resulting from enabling both ingress and egress flow creation.
© 2014-25 Kentik