Version 1 flow-export packets contain a flow header followed by a
number of flow entries. The number of flow entries in the packet is
in the count field in the flow header.
Unlike version 5 flow-export, version 1 does not have sequence number information, AS numbers of netmask lengths. It is hence largely irrelevant in a network service provider environment.
Version 5 flow-export packets contain a flow header followed by a
number of flow entries. The number of flow entries in the packet is
in the count field in the flow header.
Unlike version 1 flow-export, version 5 flow-export has AS numbers and netmask lengths for the source and destination.
NOTE: version 8 flow-export is only available in IOS 12.0(2)S and 12.0(3)T images.
Version 8 flow-export packets contain aggregate information. These packets are significantly different in content than packets from other versions of flow-export; they only contain particular information, and are missing the granularity of other versions of flow-export. The intended benefit is for high-bandwidth situations in a provider environment where the most interesting information is to be used for capacity planning and highly granular information is not desired. Version 8 flow-export is more amenable to use in high-speed infrastructure where other versions of flow-export may be too process and bandwidth intensive to enable.
When using version 8 flow-export, you must configure aggregation caches on the router. A reference document is available at:
Each version 8 flow-export packet contains data from a single
aggregation cache on the router. There is a field in the version 8
flow-export header (agg_method) that indicates the aggregation
cache from which the data was sent. In combination with the
agg_version), this determines the layout of the data entries in
the packet. Currently cflowd can make effective use of the
protocol/port aggregation cache and the prefix cache, since they contain
data needed to build the protocol table, port matrix, net matrix and AS
matrix. cflowd can also use the AS aggregation cache, but this is
generally not recommended because it makes it difficult to resolve 0
entries in the source and destination AS fields. You should also not
configure export for both the AS cache and the prefix cache, since
cflowd will use both types of data to populate the same tables, hence
you'll wind up with data whose counters will be roughly twice as high as
the actual traffic. I may add some heuristics for this in the future,
but none are implemented in the current cflowd release. Hnece my
recommendation is to configure flow-export for the prefix cache and the
protocol/port cache and don't configure flow-export for any of the other
caches (AS, source prefix or destination prefix).
NOTE: since there is no interface information present in the protocol/port data, cflowd will place all protocol/port flow entries under interface 0. In MIB-II, ifIndex can't have a value of 0, so this entry is easy for programs to recognize as not belonging to a particular interface.
NOTE: currently cflowd can recognize the source prefix flow data but has no tables in which to store it. Hence the data is not used by cflowd in the current release.
NOTE: currently cflowd can recognize the destination prefix flow data but has no tables in which to store it. Hence the data is not used by cflowd in the current release.