This article highlights the importance of the Source ID and Observation Domain ID fields when several metering processes are running on the exporter observation domain. The existence of Source ID in NetFlow v9 and Observation Domain ID in IPFIX allows these protocols to handle situations where a single flow exporter can be split into multiple Observation Domains and perform independent reporting on them using a single source IP address.
In this section, we identify the Source ID field in the NetFlow v9 packet header and explain how the Source ID value is generated by Cisco devices.
The NetFlow Version 9 record format consists of a packet header followed by at least one or more template or data FlowSets (Figure 1). A template FlowSet provides a description of the fields that will be present in future data FlowSets.
Table 1 summarizes the meaning of the fields located in the NetFlow v9 packet header. Notice the Source ID which is in the last position inside the header.
| NetFlow v9 Packet Header |
| Template FlowSet |
| Data FlowSet |
| Data FlowSet |
| Template FlowSet |
| Data FlowSet |
| Data FlowSet |
| Data FlowSet |
Figure 1 – NetFlow v9 Record Format
| Bytes | Content | Description |
| 0-1 | Version | NetFlow version number, for version 9 it is 0x0009 |
| 2-3 | Count | Number of flow sets exported in this packet, both template and data (1-30) |
| 4-7 | SysUptime | Current time in seconds since the export device booted |
| 8-11 | Unix timestamp | The current count of seconds since January 1, 1970, UTC |
| 12-15 | Flow sequence | Sequence counter of all export packets sent by the export device. This is a change from the Version 5 and Version 8 headers, where this number represented total flows |
| 16-19 | Source ID | A 32-bit value, that is used to guarantee uniqueness for all flows exported from a particular device. The format of this field is vendor-specific |
Table 1 – NetFlow v9 Packet Header Format
The captured NetFlow v9 header is shown in Figure 2. It is marked with a black box and is 20 Bytes long. The header starts with the first two bytes (0x0009), which specify a flow version. The last four bytes of the header (0x00000100) are the Source identifiers bytes.
| NOTE: Notice the bytes highlighted in blue which start with the value 0x0009 (flow version) and end with the value 0x00 02 00 08 (Figure 2). These are the bytes of the entire NetFlow v9 record inside the Ethernet frame. The length of the record is 80 bytes (20 bytes of packet header plus 60 bytes of the Template FlowSet). |
Figure 2 – Captured NetFlow v9 Packet Header
In our case, the Source ID inside the captured NetFlow v9 packet header is 256 or 0x00000100 in hexadecimal format. Collector devices should use the combination of the source IP address plus the Source ID field to associate an incoming NetFlow export packet with a unique instance of NetFlow on a particular device.
In Cisco’s implementation, the first two bytes are reserved for future expansion, and will always be zero (Figure 3). Byte 3 provides uniqueness with respect to the routing engine on the exporting device. Byte 4 provides uniqueness with respect to the particular line card or Versatile Interface Processor on the exporting device.
Figure 3 – Source ID with Decimal Value 256 in NetFlow 9 Packet Header
Similar to Source ID in the NetFlow v9 header, IANA defines a 32-bit identifier of the Observation Domain – observationDomainId for IPFIX messages. The identifier is located in the IPFIX header and is locally unique to the exporting process of the templates. The export process uses the Observation Domain ID to uniquely identify the collection process in which the flows were metered.
Figure 4 shows a scenario where the IPFX exporter is partitioned into two Observation domains. They are two nProbe instances running on Debian Linux; each captures packets on a single interface (dmz0, lan0). In this case, both exports use the same source IP address 10.0.0.2, which is not sufficient to distinguish between them. Therefore, the IPFIX device must be able to generate a unique Observation Domain Id for each metering process in order to perform independent reporting using a single source IP address.
Figure 4 – Exporter Running Two nProbe Instances
Figure 5 shows captured IPFIX messages with Observation Domain Ids 87 and 81 inside the header.
Figure 5 – Observation Domain Ids 87 and 81 in IPFIX Messages
Noction Flow Analyzer (NFA) correctly recognizes the Observation Domain Ids in received IPFIX messages and reports on them with the same source IP address 10.0.0.2 (Management→ Inventory section) (Figure 6). The Exporter ID (aka Observation Domain ID) filtering and grouping options are present in NFA’s Data Explorer section to allow for even more granular flow analysis.
Figure 6 – IPFIX Exporters Reported in NFA Inventory
Some vendors allow the Observation Domain Id to be configured for NetFlow v9 and IPFIX. For example, starting with Junos OS Release 14.1, you can configure the observation domain ID on your Juniper devices, which causes the first 8 bits of the field to be configured.
To specify the Observation Domain Id for IPFIX flows:
[edit services flow-monitoring version-ipfix]
template template-name {
observation-domain-id domain-id;
}
To specify the source ID for version 9 flows:
[edit services flow-monitoring version9]
template template-name {
source-id source-id;
}
If the observation domain is not unique, the collector cannot uniquely identify an IPFIX or NetFlow v9 Exporting Process. Juniper recommends configuring Observation Domain ID so, that it is unique for each IPFIX flow. However, if this option is not available, the observation domain ID is predefined and is set to a fixed value that is derived from the combination of an FPC slot, sampling protocol, PFE Instance, and the lookup chip (LU) Instance fields.