Overview
NetFlow collects various statistics about the network traffic passing through network equipment. However, not all network equipment supports exporting statistics as NetFlow.
NetFlow protocols were originally established by Cisco® but are not actual standards. The major NetFlow versions in use are:
-
NetFlow v5: The most common version, offering basic statistics export. However, it is limited to IPv4.
-
NetFlow v9: A more advanced version leveraging a template-based approach to provide flexibility and extensibility. For more information, see RFC 3954 (https://tools.ietf.org/html/rfc3954).
-
IPFIX: Also referred to as "NetFlow v10," it is inspired by NetFlow v9 but is not directly compatible. IPFIX has been standardized in RFC 5101 (https://tools.ietf.org/html/rfc5101).
Cisco Provider Connectivity Assurance (formerly Skylight) requires the NetFlow emitter to send data at least once per minute. See configuration details below.
Assurance Sensor Capture and Equipment Configuration
The equipment must aggregate flows based on time rather than sending per-packet or per-event flows. This is because Assurance Sensor Capture does not determine the event triggering the flow when using NetFlow v9 or IPFIX.
Key Configuration Requirements:
-
Accurate Timestamps: Assurance Sensor Capture relies on timestamps in NetFlow packets. Therefore, it is essential that these timestamps are accurate. Configure NTP on both Assurance Sensor Capture and your equipment to ensure synchronization.
-
Flow Reporting Frequency: Equipment’s NetFlow configuration should ensure that flows are sent, at least, every minute and the sampling rate must match this sending rate.
You can check this sampling rate with Wireshark when analyzing the Netflow data. The relevant (computed) field is named Duration in Wireshark. An example is shown in the section Examples.
This Duration must be at most 60 seconds.
The equipment should not be configured to send flows less frequently (for example, every 10 minutes).
Rates higher than 1 minute, such as 30 seconds, are supported. Assurance Sensor Capture will then aggregate them as it does for sniffed flows. -
Sniffer Ports: By default, the sniffer listens on the standard UDP ports
2055
and4739
. It also listens on UDP ports9555
and9995
for completeness. You can configure the sniffer to listen on other ports via the Nodes Management page.
NetFlow v5
NetFlow v5 is static and does not support IPv6. Assurance Sensor Capture can retrieve and integrate certain statistics reported by this version.
Assurance Sensor Capture uses these fields from the NetFlow v5 header and flow data to export statistics:
From the NetFlow v5 header:
Cisco Name | Wireshark Name | Description |
---|---|---|
SysUptime | SysUptime | Network equipment uptime, in milliseconds |
unix_secs | CurrentSecs | Timestamp, in seconds, since Epoch |
unix_nsecs | CurrentNSecs | Nanoseconds to be added to the timestamp |
From the NetFlow v5 flow data:
Cisco Name | Wireshark Name | Description |
---|---|---|
srcaddr | SrcAddr | IPv4 source address |
dstaddr | DstAddr | IPv4 destination address |
input | InputInt | Network equipment input interface number |
output | OutputInt | Network equipment output interface number |
dPkts | Packets | Number of packets in this flow |
dOctets | Octets | Number of octets in this flow |
First | StartTime | Network equipment SysUptime at the start of the flow |
Last | EndTime | Network equipment SysUptime at the end of the flow |
srcport | SrcPort | TCP or UDP source port |
dstport | DstPort | TCP or UDP destination port or ICMP type and code |
prot | Protocol | IP protocol |
tos | IP ToS | IP Type of Service |
- NetFlow v5 is not officially described; Cisco and Wireshark field names are included here for reference.
- Assurance Sensor Capture only handles the following IP protocols: ICMP (1), TCP (6), and UDP (17).
- For ICMP, the destination port encodes both the ICMP type and code as (ICMP type * 256 + ICMP code).
NetFlow v9 and IPFIX
NetFlow v9 and IPFIX offer more extensive and flexible statistics compared to NetFlow v5, with approximately 500 standardized entities. For a list of standardized IPFIX entities, go to: https://www.iana.org/assignments/ipfix/ipfix.xhtml
Vendors may also define custom extensions.
Templates allow NetFlow v9 and IPFIX extensibility, they are special flows that define which entities other flows can contain. The sniffer stores templates in the memory for each NetFlow sender, and flows are dropped when their associated templates are not detected.
The NetFlow sender either sends templates regularly and separately, or with other flows.
NetFlow v9 entities declared in the RFC are compatible with IPFIX entities; this section uses IANA or RFC names.
Configure your templates to include entities described in this section.
Assurance Sensor Capture uses these fields from the NetFlow v9 or IPFIX header and flow data to export statistics:
From the NetFlow v9 Header:
RFC Name | Wireshark Name | Description |
---|---|---|
sysUpTime | SysUptime | Network equipment uptime, in milliseconds |
UNIX secs | Timestamp | Timestamp, in seconds, since Epoch |
From the IPFIX Header:
RFC Name | Wireshark Name | Description |
---|---|---|
Export Time | Timestamp | Timestamp, in seconds, since Epoch |
From the NetFlow v9 or IPFIX Flow Data:
Required time fields:
IANA Names | Wireshark Name | Description |
---|---|---|
flowStartSysUpTime, flowStartMilliseconds, flowStartDeltaMicroseconds | StartTime | Start of the flow, varying unit |
flowEndSysUpTime, flowEndMilliseconds, flowEndDeltaMicroseconds | EndTime | End of the flow, varying unit |
The sniffer supports having the flowStartSysUpTime
sent within an optional record, and the other timestamps as part of the flow data when in IPFIX.
Other supported fields:
IANA Name | Wireshark Name | Description |
---|---|---|
sourceIPv4Address | SrcAddr | IPv4 source address |
sourceIPv6Address | SrcAddr | IPv6 source address |
destinationIPv4Address | DstAddr | IPv4 destination address |
destinationIPv6Address | DstAddr | IPv6 destination address |
ingressInterface | InputInt | Network equipment input interface number (usually the interface SNMP ID) |
egressInterface | OutputInt | Network equipment output interface number (usually the interface SNMP ID) |
packetDeltaCount | Packets | Number of packets in this flow |
octetDeltaCount | Octets | Number of octets in this flow |
sourceTransportPort | SrcPort | TCP or UDP source port |
destinationTransportPort | DstPort | TCP or UDP destination port or ICMP type and code |
protocolIdentifier | Protocol | IP protocol |
ipClassOfService | IP ToS / Traffic Class | IPv4 Type of Service / IPv6 Traffic Class |
icmpTypeCodeIPv4 | ICMP Type | ICMP type and code |
icmpTypeIPv4 | IPv4 ICMP Type | ICMP Type |
icmpCodeIPv4 | IPv4 ICMP Code | ICMP Code |
icmpTypeCodeIPv6 | ICMP Type | ICMP type and code for IPv6 |
icmpTypeIPv6 | IPv6 ICMP Type | ICMP Type for IPv6 |
icmpCodeIPv6 | IPv6 ICMP Code | ICMP Code for IPv6 |
sourceMacAddress | Source Mac Address | Ethernet source MAC address |
destinationMacAddress | Destination Mac address | Ethernet destination MAC address |
Multiple NetFlow v9 or IPFIX entities may map to the same or similar information, as shown in the previous tables.
Not all standardized entities are implemented due to either a lack of production site examples or limitations in integration design. If a missing entity's information is deemed useful for the sniffer, it may be added later in exchange of a PCAP file.
Many of the required entities are comparable to those found in NetFlow v5.
The base information required for any flow includes:
- Start and end times of the flow
- Ingress and egress interfaces
- IP protocol and Type of Service (ToS)
- Source and destination addresses
- Number of bytes
- Number of packets
Assurance Sensor Capture will not ingest any flow that does not include this base information.
Additional layer-specific details required:
- TCP: Source and destination ports
- UDP: Source and destination ports
- ICMP: Type and code
Due to variations in implementations, Assurance Sensor Capture cannot guarantee that the destinationTransportPort
field contains ICMP information as it does in NetFlow v5. Therefore, it relies on the ICMP entities.
Examples
Example 1: Problematic Flow
A flow with excessively long duration:
$ tshark -V -r some.pcap
...
Flow 5
SrcAddr: 1.2.3.4 (1.2.3.4)
DstAddr: 6.7.8.9 (6.7.8.9)
SrcPort: 3544
DstPort: 51655
IPv4 ICMP Type: 0
IPv4 ICMP Code: 0
IP ToS: 0x00
Protocol: 17
InputInt: 43
TCP Flags: 0x00
Octets: 548
Packets: 4
[Duration: 75.000000000 seconds]
StartTime: May 5, 2017 17:06:28.056000000 CEST
EndTime: May 5, 2017 17:07:43.056000000 CEST
OutputInt: 0
...
ICMP information may still be sent, depending on your templates, even if the IP protocol is UDP.
Example 2: Rejected Flow
A flow missing required fields:
$ tshark -d 'udp.port==9995,cflow' -V -r some.pcap
...
Flow 14
SrcAddr: 1.2.3.4 (1.2.3.4)
Post NAT Source IPv4 Address: 10.20.30.40 (10.20.30.40)
DstAddr: 6.7.8.9 (6.7.8.9)
Post NAT Destination IPv4 Address: 60.70.80.90 (60.70.80.90)
SrcPort: 64507
Post NAPT Source Transport Port: 23644
DstPort: 22652
Post NAPT Destination Transport Port: 22652
Ingress VRFID: 0
Protocol: 6
Nat Event: 2
Observation Time Milliseconds: Aug 5, 2014 13:18:46.246000000 CEST
...
Assurance Sensor Capture does not use NAT entities.
Example: Commands for Cisco Switches
collect timestamp absolute first
collect timestamp absolute last
match interface input
collect interface output
match ipv4 protocol
match ipv4 tos
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
match transport icmp ipv4 type
match transport icmp ipv4 code
collect counter bytes long
collect counter packets long
cache timeout inactive 60
cache timeout active 60
cache timeout update 60
© 2025 Cisco and/or its affiliates. All rights reserved.
For more information about trademarks, please visit: Cisco trademarks
For more information about legal terms, please visit: Cisco legal terms
For legal information about Accedian Skylight products, please visit: Accedian legal terms and tradmarks