RFC 3954
Cisco Systems NetFlow Services Export Version 9
RFC 3954: Cisco Systems NetFlow Services Export Version 9 🎀
okay bestie, let's get into it 💅 this is RFC 3954, a document from the Network Working Group that explains NetFlow version 9, Cisco Systems' flow export format. it's giving protocol deep dive ✨
- Author: B. Claise, Ed. (Cisco Systems) 🦋
- Category: Informational 🌸
- Date: October 2004 🍓
- Obsoletes / Updates: the header doesn't list anything this RFC obsoletes or updates 🧚
Status of This Memo ✨
ok so this part is the legal-ish stuff, but it matters 🙈 this memo gives information to the Internet community. it does not specify an Internet standard of any kind. distribution of this memo is unlimited 💖
Copyright Notice 🌈
Copyright (C) The Internet Society (2004).
IESG Note 💀
this is the big caveat, so read it carefully 👀
this RFC documents the NetFlow services export protocol Version 9 as it was when it was submitted to the IETF as a basis for further work in the IPFIX WG 🫶
this RFC itself is not a candidate for any level of Internet Standard. the IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that it has not had complete IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. the RFC Editor chose to publish this document at its discretion 🔥
Abstract ✨
this doc specifies the data export format for version 9 of Cisco Systems' NetFlow services. it's for implementations running on the network elements and/or the matching collector programs 🎀
the version 9 export format uses templates to give access to observations of IP packet flows in a flexible and extensible way. a template defines a collection of fields, along with descriptions of their structure and semantics 💅
Table of Contents 🎀
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology Summary Table . . . . . . . . . . . . . . . 6
3. NetFlow High-Level Picture on the Exporter. . . . . . . . . . 6
3.1. The NetFlow Process on the Exporter . . . . . . . . . . 6
3.2. Flow Expiration . . . . . . . . . . . . . . . . . . . . 7
3.3. Transport Protocol. . . . . . . . . . . . . . . . . . . 7
4. Packet Layout . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Export Packet Format. . . . . . . . . . . . . . . . . . . . . 9
5.1. Header Format . . . . . . . . . . . . . . . . . . . . . 9
5.2. Template FlowSet Format . . . . . . . . . . . . . . . . 11
5.3. Data FlowSet Format . . . . . . . . . . . . . . . . . . 13
6. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Options Template FlowSet Format . . . . . . . . . . . . 14
6.2. Options Data Record Format. . . . . . . . . . . . . . . 16
7. Template Management . . . . . . . . . . . . . . . . . . . . . 17
8. Field Type Definitions. . . . . . . . . . . . . . . . . . . . 18
9. The Collector Side. . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10.1. Disclosure of Flow Information Data . . . . . . . . . . 26
10.2. Forgery of Flow Records or Template Records . . . . . . 26
10.3. Attacks on the NetFlow Collector. . . . . . . . . . . . 27
11. Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Packet Header Example . . . . . . . . . . . . . . . . . 28
11.2. Template FlowSet Example. . . . . . . . . . . . . . . . 28
11.3. Data FlowSet Example. . . . . . . . . . . . . . . . . . 29
11.4. Options Template FlowSet Example. . . . . . . . . . . . 30
11.5. Data FlowSet with Options Data Records Example. . . . . 30
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References. . . . . . . . . . . . . . . . . . 31
12.2. Informative References. . . . . . . . . . . . . . . . . 31
13. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
15. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 32
16. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 331. Introduction 🌸
Cisco Systems' NetFlow services give network admins access to IP flow information from their data networks 👑 network elements (routers and switches) gather flow data and export it to collectors. the collected data provides fine-grained metering for highly flexible and detailed resource usage accounting 📊
a flow is defined as a unidirectional sequence of packets with some common properties that pass through a network device. these collected flows get exported to an external device, the NetFlow collector. network flows are super granular 🔍 for example, flow records include details like IP addresses, packet and byte counts, timestamps, Type of Service (ToS), application ports, input and output interfaces, etc.
exported NetFlow data gets used for a bunch of things: enterprise accounting and departmental chargebacks, ISP billing, data warehousing, network monitoring, capacity planning, application monitoring and profiling, user monitoring and profiling, security analysis, and data mining for marketing purposes 🛍️
this document specifies NetFlow version 9. it describes the implementation specs from both the network element and NetFlow collector points of view. these specs should help deployment of NetFlow version 9 across different platforms and different vendors by limiting interoperability risks 🫶 the NetFlow export format version 9 uses templates to give access to observations of IP packet flows in a flexible and extensible manner ✨
a template defines a collection of fields, with corresponding descriptions of structure and semantics.
the template-based approach has these advantages, and they're honestly iconic 😭
- New fields can be added to NetFlow flow records without changing the structure of the export record format. With previous NetFlow versions, adding a new field to the flow record implied a new version of the export protocol format and a new version of the NetFlow collector that supported parsing the new export protocol format. 💅
- Templates that are sent to the NetFlow collector contain the structural information about the exported flow record fields. Therefore, if the NetFlow collector does not understand the semantics of new fields, it can still interpret the flow record. 🧚
- Because the template mechanism is flexible, it allows the export of only the required fields from the flows to the NetFlow collector. This helps reduce the exported flow data volume and provides possible memory savings for the exporter and NetFlow collector. Sending only the required information can also reduce network load. 🍓
the IETF IPFIX Working Group (IP Flow Information eXport) is developing a new protocol based on version 9 of Cisco Systems' NetFlow services. some enhancements in different domains (congestion aware transport protocol, built-in security, etc... ) have been incorporated in this new IPFIX protocol. refer to the IPFIX Working Group documents for more details 📚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. ⭐
2. Terminology 🦋
various terms used in this document are described in this section 🧠 note that the terminology summary table in Section 2.1 gives a quick overview of the relationships between some of the different terms defined.
Observation Point an Observation Point is a location in the network where IP packets can be observed, for example one or a set of interfaces on a network device like a router. every Observation Point is associated with an Observation Domain. 👀
Observation Domain the set of Observation Points that is the largest aggregatable set of flow information at the network device with NetFlow services enabled is termed an Observation Domain. for example, a router line card composed of several interfaces, with each interface being an Observation Point. 🔥
IP Flow or Flow an IP Flow, also called a Flow, is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. all packets that belong to a particular Flow have a set of common properties derived from the data contained in the packet and from the packet treatment at the Observation Point. 🌊
Flow Record a Flow Record provides information about an IP Flow observed at an Observation Point. in this document, the Flow Data Records are also referred to as NetFlow services data and NetFlow data. 💜
Exporter a device (for example, a router) with NetFlow services enabled. the Exporter monitors packets entering an Observation Point and creates Flows from these packets. the information from these Flows is exported in the form of Flow Records to the NetFlow Collector. 🛰️
NetFlow Collector the NetFlow Collector receives Flow Records from one or more Exporters. it processes the received Export Packet(s), that is, it parses and stores the Flow Record information. Flow Records can optionally be aggregated before being stored on the hard disk. the NetFlow Collector is also referred to as the Collector in this document. 🗄️
Export Packet an Export Packet is a packet originating at the Exporter that carries the Flow Records of this Exporter and whose destination is the NetFlow Collector. 📦
Packet Header the Packet Header is the first part of an Export Packet. it provides basic info about the packet, such as the NetFlow version, the number of records contained within the packet, and sequence numbering. 🎀
Template Record a Template Record defines the structure and interpretation of fields in a Flow Data Record. 🧩
Flow Data Record a Flow Data Record is a data record that contains values of the Flow parameters corresponding to a Template Record. 📝
Options Template Record an Options Template Record defines the structure and interpretation of fields in an Options Data Record, including defining the scope within which the Options Data Record is relevant. 🔭
Options Data Record the data record that contains values and scope information of the Flow measurement parameters, corresponding to an Options Template Record. 📊
FlowSet FlowSet is a generic term for a collection of Flow Records that have a similar structure. in an Export Packet, one or more FlowSets follow the Packet Header. there are three different types of FlowSets: Template FlowSet, Options Template FlowSet, and Data FlowSet. 🌈
Template FlowSet a Template FlowSet is one or more Template Records that have been grouped together in an Export Packet. 🧁
Options Template FlowSet an Options Template FlowSet is one or more Options Template Records that have been grouped together in an Export Packet. 🍭
Data FlowSet a Data FlowSet is one or more records, of the same type, that are grouped together in an Export Packet. each record is either a Flow Data Record or an Options Data Record previously defined by a Template Record or an Options Template Record. 💖
2.1. Terminology Summary Table ✨
+------------------+---------------------------------------------+
| | Contents |
| +--------------------+------------------------+
| FlowSet | Template Record | Data Record |
+------------------+--------------------+------------------------+
| | | Flow Data Record(s) |
| Data FlowSet | / | or |
| | | Options Data Record(s) |
+------------------+--------------------+------------------------+
| Template FlowSet | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| FlowSet | Record(s) | |
+------------------+--------------------+------------------------+okay so a Data FlowSet is made of Options Data Record(s) or Flow Data Record(s) 💖. There's no Template Record in there. A Template Record defines the Flow Data Record, and an Options Template Record defines the Options Data Record 🧚.
A Template FlowSet is made of Template Record(s) 🎀. No Flow or Options Data Record is included 💅.
An Options Template FlowSet is made of Options Template Record(s) 🦋. Again, no Flow or Options Data Record is included, so it's really just template vibes 🌸.
3. NetFlow High-Level Picture on the Exporter 🌈
3.1. The NetFlow Process on the Exporter
The NetFlow process on the Exporter is responsible for making Flows out of the observed IP packets ✨. The details of how that works are beyond the scope of this document, so we're not going there today 🙈.
3.2. Flow Expiration
okay so a Flow counts as inactive if no packets belonging to it have been seen at the Observation Point for a given timeout 💤. If any packet shows up within that timeout, the flow is considered an active flow 🔥. A Flow can get exported under these conditions:
- If the Exporter can detect the end of a Flow. For example, if the FIN or RST bit is detected in a TCP [RFC793] connection, the Flow Record gets exported 🎀.
- If the Flow has been inactive for a certain period of time. This inactivity timeout SHOULD be configurable at the Exporter, with a minimum value of 0 for an immediate expiration 💅.
- For long-lasting Flows, the Exporter SHOULD export the Flow Records on a regular basis 🧚. This timeout SHOULD be configurable at the Exporter too 💖.
- If the Exporter experiences internal constraints, a Flow MAY be forced to expire prematurely 😭. Examples are counters wrapping or low memory 💀.
3.3. Transport Protocol
To get efficient processing at the Exporter while it handles high volumes of Export Packets, the NetFlow Export Packets are encapsulated into UDP [RFC768] datagrams for export to the NetFlow Collector 🚀. But here's the tea: NetFlow version 9 was designed to be transport protocol independent 👑. So it can also operate over congestion-aware protocols such as SCTP [RFC2960] 🫶.
Note that the Exporter can export to multiple Collectors, using independent transport protocols ✨.
UDP [RFC768] is a non congestion-aware protocol, so when you deploy NetFlow version 9 in a congestion-sensitive environment, make the connection between Exporter and NetFlow Collector through a dedicated link 🛤️. This makes sure any burstiness in the NetFlow traffic only affects that dedicated link 🦋. When the NetFlow Collector can not be placed within a one-hop distance from the Exporter, or when the export path from the Exporter to the NetFlow Collector can not be used exclusively for the NetFlow Export Packets, the export path should be designed so that it can always sustain the maximum burstiness of NetFlow traffic from the Exporter 😤. Also, congestion can happen on the Exporter if the export path speed is too low 💅.
4. Packet Layout 🍓
An Export Packet is a Packet Header followed by one or more FlowSets 💜. The FlowSets can be any of the three possible types: Template, Data, or Options Template 🧚.
+--------+-------------------------------------------+
| | +----------+ +---------+ +----------+ |
| Packet | | Template | | Data | | Options | |
| Header | | FlowSet | | FlowSet | | Template | ... |
| | | | | | | FlowSet | |
| | +----------+ +---------+ +----------+ |
+--------+-------------------------------------------+
Export PacketA FlowSet ID tells you which type of FlowSet you're looking at 👀. FlowSet IDs lower than 256 are reserved for special FlowSets, like the Template FlowSet (ID 0) and the Options Template FlowSet (ID 1) 🎀. Data FlowSets have a FlowSet ID greater than 255 💖.
The format of the Template, Data, and Options Template FlowSets gets covered later in this document 🌸. The Exporter MUST code all binary integers of the Packet Header and the different FlowSets in network byte order (also known as the big-endian byte ordering) 🔥. No skipping this one, bestie 🙅.
Here are some examples of export packets 🦋:
- An Export Packet consisting of interleaved Template, Data, and Options Template FlowSets. Example: a newly created Template is exported as soon as possible 🚀. So if there's already an Export Packet with a Data FlowSet being prepared for export, the Template and Option FlowSets are also interleaved with this information, subject to availability of space 🧩.
Export Packet:
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
| Packet | | Template | | Data | | Options | | Data | |
| Header | | FlowSet | | FlowSet | ... | Template | | FlowSet | |
| | | | | | | FlowSet | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+- An Export Packet consisting entirely of Data FlowSets. Example: after the appropriate Template Records have been defined and sent to the NetFlow Collector device, most Export Packets are just Data FlowSets 💅.
Export Packet:
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
| Packet | | Data | ... | Data | ... | Data | |
| Header | | FlowSet | ... | FlowSet | ... | FlowSet | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+- An Export Packet consisting entirely of Template and Options Template FlowSets. Example: the Exporter MAY transmit a packet containing Template and Options Template FlowSets periodically 🧚. That helps make sure the NetFlow Collector has the correct Template Records and Options Template Records when the matching Flow Data records show up 🫶.
Export Packet:
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
| Packet | | Template | | Template | | Options | |
| Header | | FlowSet | ... | FlowSet | ... | Template | |
| | | | | | | FlowSet | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+5. Export Packet Format 💎
5.1. Header Format
The Packet Header format is specified like this 📐:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Packet Header Field Descriptions 📝
Version The version of the Flow Record format exported in this packet 🌟. The value of this field is 9 for the current version 💖.
Count The total number of records in the Export Packet 🔢. It's the sum of Options FlowSet records, Template FlowSet records, and Data FlowSet records 🧮.
sysUpTime Time in milliseconds since this device was first booted ⏰.
UNIX Secs Time in seconds since 0000 UTC 1970, at which the Export Packet leaves the Exporter 🕛.
Sequence Number This is an incremental sequence counter of all Export Packets sent from the current Observation Domain by the Exporter 🔁. This value MUST be cumulative, and SHOULD be used by the Collector to identify whether any Export Packets have been missed 🕵️♀️. Main character energy for counting packets 👑.
Source ID A 32-bit value that identifies the Exporter Observation Domain 🆔. NetFlow Collectors SHOULD use the combination of the source IP address and the Source ID field to separate different export streams coming from the same Exporter 🌈. Iykyk, it's how you keep the streams from mixing up 💜.
5.2. Template FlowSet Format 🎀
okay so templates are literally one of the essential pieces of NetFlow, no cap 💅 They make the Flow Record format super flexible because the NetFlow Collector can process Flow Records without necessarily knowing what all the data inside means. Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type N | Field Length N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type M | Field Length M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID K | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Template FlowSet Field Descriptions 🧚
FlowSet ID FlowSet ID value of 0 is reserved for the Template FlowSet.
Length This is the total length of this FlowSet. Because an individual Template FlowSet MAY contain multiple Template Records, the Length value MUST be used to determine the position of the next FlowSet record, which could be any type of FlowSet. Length is the sum of the lengths of the FlowSet ID, the Length itself, and all Template Records within this FlowSet.
Template ID Each of the newly generated Template Records gets a unique Template ID. This uniqueness is local to the Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template FlowSets, Options FlowSets, and other reserved FlowSets yet to be created. Template IDs of Data FlowSets are numbered from 256 to 65535.
Field Count This is the number of fields in this Template Record. Because a Template FlowSet usually contains multiple Template Records, this field lets the Collector figure out where the current Template Record ends and the next one starts.
Field Type A numeric value that represents the type of the field. Refer to the "Field Type Definitions" section.
Field Length The length of the corresponding Field Type, in bytes. Refer to the "Field Type Definitions" section.
5.3. Data FlowSet Format 🦋
the Data FlowSet looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data FlowSet Field Descriptions 💜
FlowSet ID = Template ID Each Data FlowSet is tied to a FlowSet ID. That FlowSet ID maps to a (previously generated) Template ID. The Collector MUST use the FlowSet ID to find the matching Template Record and decode the Flow Records from the FlowSet.
Length This is the length of this FlowSet. Length is the sum of the lengths of the FlowSet ID, Length itself, all Flow Records within this FlowSet, and the padding bytes, if any.
Record N - Field Value M The rest of the Data FlowSet is a collection of Flow Data Record(s), each holding a set of field values. The Type and Length of the fields were already defined in the Template Record referenced by the FlowSet ID or Template ID.
Padding The Exporter SHOULD insert some padding bytes so the subsequent FlowSet starts at a 4-byte aligned boundary. It's important to note that the Length field includes the padding bytes. Padding SHOULD be using zeros.
Interpretation of the Data FlowSet format can only happen if the Template FlowSet corresponding to the Template ID is available at the Collector. 🙈
6. Options ✨
6.1. Options Template FlowSet Format 🌈
The Options Template Record (and its corresponding Options Data Record) is used to supply information about the NetFlow process configuration or NetFlow process specific data, rather than supplying information about IP Flows. 🍓
For example, the Options Template FlowSet can report the sample rate of a specific interface, if sampling is supported, along with the sampling method used.
The Options Template FlowSet format looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Option Scope Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Scope 1 Field Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Option 1 Field Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Options Template FlowSet Field Definitions 🧁
FlowSet ID = 1 A FlowSet ID value of 1 is reserved for the Options Template.
Length This is the total length of this FlowSet. Each Options Template FlowSet MAY contain multiple Options Template Records. So the Length value MUST be used to determine the position of the next FlowSet record, which could be either a Template FlowSet or Data FlowSet.
Length is the sum of the lengths of the FlowSet ID, the Length itself, and all Options Template Records within this FlowSet Template ID.
Template ID This is the Template ID of this Options Template. This value is greater than 255.
Option Scope Length The length in bytes of any Scope field definition contained in the Options Template Record. (The use of "Scope" is described below.)
Option Length The length (in bytes) of any options field definitions contained in this Options Template Record.
Scope 1 Field Type This is the relevant portion of the Exporter/NetFlow process that the Options Template Record refers to. Currently defined values are:
1 System
2 Interface
3 Line Card
4 Cache
5 TemplateFor example, the NetFlow process can be implemented on a per-interface basis. So if the Options Template Record were reporting on how the NetFlow process is configured, the Scope for the report would be 2 (interface). The associated interface ID would then be carried in the associated Options Data FlowSet. The Scope can be limited further by listing multiple scopes that all must match at the same time. Note that the Scope fields always precede the Option fields. 🫶
Scope 1 Field Length The length (in bytes) of the Scope field, as it would appear in an Options Data Record.
Option 1 Field Type A numeric value that represents the type of field that would appear in the Options Template Record. Refer to the Field Type Definitions section.
Option 1 Field Length The length (in bytes) of the Option field.
Padding The Exporter SHOULD insert some padding bytes so the subsequent FlowSet starts at a 4-byte aligned boundary. It's important to note that the Length field includes the padding bytes. Padding SHOULD be using zeros. 💖
6.2. Options Data Record Format ✨
okay so the Options Data Records ride along inside Data FlowSets, but they don't tag along with every single Flow Data Record 🦋 They get sent on a regular schedule, and you get to configure how often. Check the "Templates Management" section for the details 💅
Here's what the Data FlowSet carrying Options Data Records looks like 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Scope 1 Value |Record 1 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 1 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Scope 1 Value |Record 2 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 2 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Scope 1 Value |Record 3 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 3 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Options Data Records of the Data FlowSet Field Descriptions 💜
FlowSet ID = Template ID A FlowSet ID sits in front of each group of Options Data Records inside a Data FlowSet 🌸 It maps back to a Template ID that was generated earlier for this Options Template Record. The Collector MUST use that FlowSet ID to figure out the type and length of whatever field values come after it, so it's basically the decoder's cheat sheet 🧚
Length This is the length of the FlowSet ✨ It adds up the FlowSet ID, the Length field itself, every Options Data Record in the FlowSet, and any padding bytes, if there are any 🍓
Record N - Option Field M Value The rest of the Data FlowSet is a pile of records, and each one holds a set of scope and field values 🌈 The type and length of those fields were already defined in the Options Template Record that the FlowSet ID (aka Template ID) points to. Main character energy: the template is the plan, the data is the follow-through 👑
Padding The Exporter SHOULD add some padding bytes so the next FlowSet starts on a 4-byte aligned boundary 🫶 Heads up, the Length field counts those padding bytes too. Padding SHOULD be zeros ❤️🔥
Lowkey important: you can only decode this Data FlowSet if the Options Template FlowSet for that Template ID is already sitting at the Collector 🙈 No template, no decoding, periodt 💀
7. Template Management 🎀
Flow Data records that match a Template Record MAY show up in the same Export Packet, in later ones, or both 🦋 The Template Record doesn't have to ride along in every Export Packet 💅 So the NetFlow Collector MUST store the Template Record, so it can still read the Flow Data Records that arrive in later data packets. That's the whole vibe 💖
If a Collector is getting Export Packets from several Observation Domains coming from the same Exporter, it MUST know that Template IDs aren't guaranteed to be unique across those domains 😭 Same ID, different domain, different template. Keep track of that 🔥
Template IDs have to stay constant for the entire life of the NetFlow process on the Exporter ✨ If the Exporter or the NetFlow process restarts for any reason, all the Template information gets wiped and fresh Template IDs get made 🌸 So Template IDs aren't guaranteed to stay the same across a restart. Plan around it 🫶
A brand-new Template record gets an unused Template ID from the Exporter 🧚 If the template configuration changes, the old Template ID gets abandoned, and it SHOULD NOT be reused until the NetFlow process or the Exporter restarts 🙈 If a Collector gets a new definition for a Template ID it already knows, it MUST throw out the old definition and use the new one. No clinging to the past 👑
If a configured Template Record gets deleted on the Exporter and then set up again with exactly the same parameters, the same Template ID could be reused 💜
The Exporter sends the Template FlowSet and the Options Template FlowSet under these conditions:
- After a NetFlow process restarts, the Exporter MUST NOT send any Data FlowSet without first sending the matching Template FlowSet and the required Options Template FlowSet, either in an earlier packet or in the same Export Packet 💀 It MAY send the Template FlowSet and Options Template FlowSet ahead of time, with no Data FlowSets at all, so the Collector already has the right Template Record before the first Flow or Options Data Record shows up 🎀
- When the configuration changes, the Exporter SHOULD send the new template definitions at an accelerated rate 🔥 It MAY send the changed Template Record(s) and Options Template Record(s) ahead of time, with no data, so the Collector has the right template info before the first data arrives 🌈
- On a regular basis, the Exporter MUST send all the Template Records and Options Template Records to refresh the Collector 🦋 Template IDs only have a limited lifetime at the Collector, so they MUST be refreshed periodically ✨ There are two ways to make sure Templates get refreshed at the Collector:
- Every N number of Export Packets.
- On a time basis, so every N number of minutes. Both options MUST be configurable by the user on the Exporter 💖 When one of these expiry conditions is met, the Exporter MUST send the Template FlowSet and Options Template 🫶
- If the clock configuration changes on the Exporter, the Exporter SHOULD send the template definitions at an accelerated rate ⭐
8. Field Type Definitions 🌸
This table lays out all the field type definitions an Exporter MAY support 💅 The fields are a mix of Packet Header fields, lookup results (like autonomous system numbers or subnet masks), and properties of the packet, like its length 🧚
Field Type Value Length Description
(bytes)
Incoming counter with
length N x 8 bits for the
IN_BYTES 1 N number of bytes associated
with an IP Flow. By default
N is 4
Incoming counter with
length N x 8 bits for the
IN_PKTS 2 N number of packets
associated with an IP Flow.
By default N is 4
FLOWS 3 N Number of Flows
that were aggregated;
by default N is 4
PROTOCOL 4 1 IP protocol byte
Type of service byte
TOS 5 1 setting when entering
the incoming interface
TCP flags; cumulative of
TCP_FLAGS 6 1 all the TCP flags seen in
this Flow
TCP/UDP source port number
L4_SRC_PORT 7 2 (for example, FTP, Telnet,
or equivalent)
IPV4_SRC_ADDR 8 4 IPv4 source address
The number of contiguous
bits in the source subnet
SRC_MASK 9 1 mask (i.e., the mask in
slash notation)
Input interface index.
INPUT_SNMP 10 N By default N is 2, but
higher values can be used
TCP/UDP destination port
L4_DST_PORT 11 2 number (for example, FTP,
Telnet, or equivalent)
IPV4_DST_ADDR 12 4 IPv4 destination address
The number of contiguous
bits in the destination
DST_MASK 13 1 subnet mask (i.e., the mask
in slash notation)
Output interface index.
OUTPUT_SNMP 14 N By default N is 2, but
higher values can be used
IPV4_NEXT_HOP 15 4 IPv4 address of the next-
hop router
Source BGP autonomous
SRC_AS 16 N system number where N could
be 2 or 4. By default N is
2
Destination BGP autonomous
DST_AS 17 N system number where N could
be 2 or 4. By default N is
2
BGP_IPV4_NEXT_HOP 18 4 Next-hop router's IP
address in the BGP domain
IP multicast outgoing
packet counter with length
MUL_DST_PKTS 19 N N x 8 bits for packets
associated with the IP
Flow. By default N is 4
IP multicast outgoing
Octet (byte) counter with
length N x 8 bits for the
MUL_DST_BYTES 20 N number of bytes associated
with the IP Flow. By
default N is 4
sysUptime in msec at which
LAST_SWITCHED 21 4 the last packet of this
Flow was switched
sysUptime in msec at which
FIRST_SWITCHED 22 4 the first packet of this
Flow was switched
Outgoing counter with
length N x 8 bits for the
OUT_BYTES 23 N number of bytes associated
with an IP Flow. By
default N is 4 Outgoing counter with
length N x 8 bits for the
OUT_PKTS 24 N number of packets
associated with an IP Flow.
By default N is 4
IPV6_SRC_ADDR 27 16 IPv6 source address
IPV6_DST_ADDR 28 16 IPv6 destination address
IPV6_SRC_MASK 29 1 Length of the IPv6 source
mask in contiguous bits
Length of the IPv6
IPV6_DST_MASK 30 1 destination mask in
contiguous bits
IPV6_FLOW_LABEL 31 3 IPv6 flow label as per
RFC 2460 definition
Internet Control Message
ICMP_TYPE 32 2 Protocol (ICMP) packet
type; reported as
ICMP Type * 256 + ICMP code
MUL_IGMP_TYPE 33 1 Internet Group Management
Protocol (IGMP) packet type
When using sampled NetFlow,
the rate at which packets
SAMPLING_INTERVAL 34 4 are sampled; for example, a
value of 100 indicates that
one of every hundred
packets is sampled
For sampled NetFlow
platform-wide:
SAMPLING_ALGORITHM 35 1 0x01 deterministic sampling
0x02 random sampling
Use in connection with
SAMPLING_INTERVAL
Timeout value (in seconds)
FLOW_ACTIVE_TIMEOUT 36 2 for active flow entries
in the NetFlow cache
Timeout value (in seconds)
FLOW_INACTIVE_TIMEOUT 37 2 for inactive Flow entries
in the NetFlow cache
Type of Flow switching
ENGINE_TYPE 38 1 engine (route processor,
linecard, etc...)
ENGINE_ID 39 1 ID number of the Flow
switching engine
Counter with length
N x 8 bits for the number
TOTAL_BYTES_EXP 40 N of bytes exported by the
Observation Domain. By
default N is 4
Counter with length
N x 8 bits for the number
TOTAL_PKTS_EXP 41 N of packets exported by the
Observation Domain. By
default N is 4
Counter with length
N x 8 bits for the number
TOTAL_FLOWS_EXP 42 N of Flows exported by the
Observation Domain. By
default N is 4
MPLS_TOP_LABEL_TYPE 46 1 MPLS Top Label Type:
0x00 UNKNOWN
0x01 TE-MIDPT
0x02 ATOM
0x03 VPN
0x04 BGP
0x05 LDP
Forwarding Equivalent Class
MPLS_TOP_LABEL_IP_ADDR 47 4 corresponding to the MPLS
Top Label
FLOW_SAMPLER_ID 48 1 Identifier shown
in "show flow-sampler"
The type of algorithm used
for sampling data:
FLOW_SAMPLER_MODE 49 1 0x02 random sampling
Use in connection with
FLOW_SAMPLER_MODE
Packet interval at which to
FLOW_SAMPLER_RANDOM_INTERVAL 50 4 sample. Use in connection
with FLOW_SAMPLER_MODE
Type of Service byte
DST_TOS 55 1 setting when exiting
outgoing interface
SRC_MAC 56 6 Source MAC Address
DST_MAC 57 6 Destination MAC Address
Virtual LAN identifier
SRC_VLAN 58 2 associated with ingress
interface
Virtual LAN identifier
DST_VLAN 59 2 associated with egress
interface
Internet Protocol Version
Set to 4 for IPv4, set to 6
IP_PROTOCOL_VERSION 60 1 for IPv6. If not present in
the template, then version
4 is assumed
Flow direction:
DIRECTION 61 1 0 - ingress flow
1 - egress flow
IPV6_NEXT_HOP 62 16 IPv6 address of the
next-hop router
BGP_IPV6_NEXT_HOP 63 16 Next-hop router in the BGP
domain
Bit-encoded field
IPV6_OPTION_HEADERS 64 4 identifying IPv6 option
headers found in the flow
MPLS_LABEL_1 70 3 MPLS label at position 1 in
the stack
MPLS_LABEL_2 71 3 MPLS label at position 2 in
the stack
MPLS_LABEL_3 72 3 MPLS label at position 3 in
the stack
MPLS_LABEL_4 73 3 MPLS label at position 4 in
the stack
MPLS_LABEL_5 74 3 MPLS label at position 5 in
the stack
MPLS_LABEL_6 75 3 MPLS label at position 6 in
the stack
MPLS_LABEL_7 76 3 MPLS label at position 7 in
the stack
MPLS_LABEL_8 77 3 MPLS label at position 8 in
the stack
MPLS_LABEL_9 78 3 MPLS label at position 9 in
the stack
MPLS_LABEL_10 79 3 MPLS label at position 10
in the stackokay so the table is done 💅 The value field is a numeric identifier for the field type, and these value fields are reserved for proprietary field types: 25, 26, 43 to 45, 51 to 54, and 65 to 69. 🔒 Hands off those numbers, bestie!
When extensibility is required, new field types get added to the list 🧚. The new field types have to be updated on the Exporter and Collector, but the NetFlow export format stays unchanged, which is so iconic ✨. If you want the latest list, go check http://www.cisco.com for the newly updated stuff 🌸.
Lowkey genius alert: some field sizes are fixed by definition, like PROTOCOL or IPV4_SRC_ADDR 🎀. Other fields are variant types, and that's giving memory efficiency at the collector and less network bandwidth between the Exporter and the Collector 🦋. For example, with IN_BYTES, an access router might be fine with a 32 bit counter (N = 4), but a core router would need a 64 bit counter (N = 8) 👑. Main character energy for sizing!
All counters and counter-like objects are unsigned integers of size N * 8 bits 🔥.
9. The Collector Side ✨
okay so the Collector gets Template Records from the Exporter, usually before it gets Flow Data Records (or Options Data Records) 🧚. Once the templates are there, the Flow Data Records (or Options Data Records) can be decoded and stored locally on the devices 💖. But if the Template Records haven't shown up yet when the data arrives, the Collector SHOULD store those Flow Data Records (or Options Data Records) and decode them after the Template Records come in 🫶. Honestly that's such a smart fallback.
Also, a Collector device MUST NOT assume that the Data FlowSet and its associated Template FlowSet (or Options Template FlowSet) are exported in the same Export Packet 😭. Bestie, don't get caught slipping on that one 💀.
The Collector MUST NOT assume that one and only one Template FlowSet is in an Export Packet 🙈. It could be more, it could be fewer, so keep your eyes open 👀.
A template's life at the Collector is limited to a fixed refresh timeout ⏳. Templates that aren't refreshed by the Exporter within that timeout get expired at the Collector 🍓. And the Collector MUST NOT attempt to decode Flow or Options Data Records with an expired Template 🚫. At any given time, the Collector SHOULD maintain the following for all the current Template Records and Options Template Records: Exporter, Observation Domain, Template ID, Template Definition, and Last Received 🌈.
Quick reminder that the Observation Domain is identified by the Source ID field from the Export Packet 🦋.
If the Exporter has a clock configuration change, the Collector SHOULD discard all Template Records and Options Template Records associated with that Exporter 💜. That way it can learn the new set of fields again: Exporter, Observation Domain, Template ID, Template Definition, and Last Received 🧹.
Template IDs are unique per Exporter and per Observation Domain 🔑. And if the Collector gets a new Template Record (like after an Exporter restart), it MUST immediately override the existing Template Record 💅. No hesitation, no cap.
Finally, the Collector MUST accept padding in the Data FlowSet and Options Template FlowSet 🫧. That covers Flow Data Records, Options Data Records, and Template Records alike. For the terminology summary table, see Section 2.1 📚 ✨
10. Security Considerations 🔐
okay bestie, security time 😭🔐 so the NetFlow version 9 protocol was designed assuming the Exporter and Collector would stay inside a single private network. but then people started sending Flow Records over the public Internet, and that's where it gets messy. an attacker might capture, modify or insert Export Packets, so there's a risk that IP Flow information gets captured or forged, or that attacks get aimed right at the NetFlow Collector. yikes 💀
The designers of NetFlow Version 9 didn't add any confidentiality, integrity or authentication requirements to the protocol. why? because that would've lowered the efficiency of the implementation, and back then everyone figured most deployments would keep the Flow Records in private networks, with the Collector(s) and Exporter(s) sitting right next to each other 🙈
IPFIX (IP Flow Information eXport) picked NetFlow version 9 as its base protocol, and it addresses the security considerations talked about in this section. check the security section of the IPFIX requirement draft [RFC3917] for more deets 🦋
10.1. Disclosure of Flow Information Data 👀
Okay, so NetFlow Version 9 Export Packets aren't encrypted. That means if someone observes Flow Records, they can learn about the active flows in the network, the communication endpoints and the traffic patterns. that's a lot of info 😬 It can be used to spy on user behavior, and also to plan and hide future attacks.
How much an attacker can learn depends on the Flow definition. For example, a Flow Record with the source and destination IP addresses might reveal privacy-sensitive stuff about what an end user is doing, whilst a Flow Record that only has the source and destination IP network is way less revealing 🫣
10.2. Forgery of Flow Records or Template Records 🎭
If Flow Records get used in accounting and/or security apps, there may be a strong incentive to forge exported Flow Records. like, someone might want to defraud the service provider, or stop an attack from being detected 🕵️♀️ This can happen either by altering the Flow Records on the path between the Observer and the Collector, or by injecting forged Flow Records that pretend to come from the Exporter.
An attacker could also forge Templates and/or Options Templates to try to confuse the NetFlow Collector, leaving it unable to decode the Export Packets. not it 🙅♀️
10.3. Attacks on the NetFlow Collector 💥
Denial of service attacks on the NetFlow Collector can eat up so many resources on the machine that the Collector can't capture or decode some NetFlow Export Packets. The NetFlow Version 9 protocol doesn't explicitly address these hazards, although the normal methods used to protect a server from a DoS attack will help mitigate the problem 🛡️
11. Examples 🧁
okay now the fun part 🎀 let's look at an example Export Packet made up of a Template FlowSet, a Data FlowSet (with three Flow Data Records), an Options Template FlowSet, and another Data FlowSet (with two Options Data Records). it's giving organized ✨
Export Packet:
+--------+---------------------------------------------. . .
| | +--------------+ +-----------------------+
| Packet | | Template | | Data |
| Header | | FlowSet | | FlowSet | . . .
| | | (1 Template) | | (3 Flow Data Records) |
| | +--------------+ +-----------------------+
+--------+---------------------------------------------. . .
. . .+-------------------------------------------------+
+------------------+ +--------------------------+ |
| Options | | Data | |
. . .| Template FlowSet | | FlowSet | |
| (1 Template) | | (2 Options Data Records) | |
+------------------+ +--------------------------+ |
. . .--------------------------------------------------+11.1. Packet Header Example 📦
The Packet Header is made up of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 9 | Count = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+11.2. Template FlowSet Example 🧩
we wanna report these Field Types:
- The source IP address (IPv4), so the length is 4
- The destination IP address (IPv4), so the length is 4
- The next-hop IP address (IPv4), so the length is 4
- The number of bytes of the Flow
- The number of packets of the Flow
So the Template FlowSet looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 0 | Length = 28 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_SRC_ADDR = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_DST_ADDR = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_NEXT_HOP = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_PKTS = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+11.3. Data FlowSet Example 📊
In this example we report these three Flow Records:
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Bytes
| | | Number | Number
---------------------------------------------------------------
198.168.1.12 | 10.5.12.254 | 192.168.1.1 | 5009 | 5344385
192.168.1.27 | 10.5.12.23 | 192.168.1.1 | 748 | 388934
192.168.1.56 | 10.5.12.65 | 192.168.1.1 | 5 | 6534 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 198.168.1.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note that padding was not necessary in this example. ✨
11.4. Options Template FlowSet Example ⚙️
Per line card (the Exporter is made up of two line cards), we wanna report these Field Types:
- Total number of Export Packets
- Total number of exported Flows
The format of the Options Template FlowSet goes like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 1 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Option Scope Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length = 8 | Scope 1 Field Type = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 2 | TOTAL_EXP_PKTS_SENT = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | TOTAL_FLOWS_EXP = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+11.5. Data FlowSet with Options Data Records Example ✨
okay so this one is giving data records with options 💖 we're literally reporting two records here, bestie, one for each line card:
Line Card ID | Export Packet| Export Flow
------------------------------------------
Line Card 1 | 345 | 10201
Line Card 2 | 690 | 20402and this is what the Data FlowSet looks like 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 257 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10201 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+12. References 📚
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
13. Authors ✍️
this doc was jointly written by Vamsidhar Valluri, Martin Djernaes, Ganesh Sadasivan, and Benoit Claise. the squad 🫶
14. Acknowledgments 🙏
big thank you to Pritam Shah, Paul Kohler, Dmitri Bouianovski, and Stewart Bryant for their valuable technical feedback. you know who you are 💜
15. Authors' Addresses 🏢
Benoit Claise (Editor) Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
Ganesh Sadasivan Cisco Systems, Inc. 3750 Cisco Way San Jose, CA 95134 USA
Phone: +1 408 527-0251 EMail: gsadasiv@cisco.com
Vamsi Valluri Cisco Systems, Inc. 510 McCarthy Blvd. San Jose, CA 95035 USA
Phone: +1 408 525-1835 EMail: vvalluri@cisco.com
Martin Djernaes Cisco Systems, Inc. 510 McCarthy Blvd. San Jose, CA 95035 USA
Phone: +1 408 853-1676 EMail: djernaes@cisco.com
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2004).
this doc is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors keep all their rights 🦋
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💜
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't say it has made any independent effort to identify any such rights. info on the ISOC's procedures for rights in ISOC Documents can be found in BCP 78 and BCP 79.
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. please address the information to the IETF at ietf-ipr@ietf.org 🌈
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society 💅
📦 where this page comes from
- ietf: rfc3954 2004-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms