Source ID and Observation Domain ID fields meaning & configuration details

1. Source ID in NetFlow Version 9 Header

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.

Figure 1 – NetFlow v9 Record Format

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.

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

2. Observation Domain ID in IPFIX 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

3. Configuration

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;
}

Conclusion

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.