<!doctype linuxdoc system>

<article>

<title>
cflowd configuration
</title>
<author>Daniel W. McRobb
<date>Original: Oct 1998   Last Modified: August 30, 1999

<abstract>
This is the <tt>cflowd</tt> system configuration guide for @DOC_VERSION@.
</abstract>

<toc>
<lof>

<sect>Overview
<p>

<sect1>Data flow
<p>

It is useful to understand the flow of data in the <tt>cflowd</tt>
system before configuration.  <bf>Figure 1</bf> is a diagram showing a
high-level view of the flow of data in the cflowd system.

<figure loc="ht">
<eps file="./dataflow1.ps" height="6in">
<img src="./dataflow1.gif">
<caption>
<label id="figure1">
<#if output="html">
Figure 1: cflowd data flow
</#if>
<#if output="ps|dvi|latex2e|latex">
cflowd data flow
</#if>
</caption>
</figure>

Each Cisco router sends flow-export packets (version 1, version 5 or
version 8) to a host running <tt>cflowdmux</tt> and <tt>cflowd</tt>.
<tt>cflowd</tt> creates tabular data from the data in the flow-export
packets.  <tt>cflowd</tt> also serves the tabular data to
<tt>cfdcollect</tt>.  <tt>cfdcollect</tt> will contact each configured
instance of <tt>cflowd</tt> at regular intervals (configurable) to
retrieve tabular data, and will store the data in ARTS files.

A typical configuration inside a provider network would have several
workstations in the network running <tt>cflowd</tt>, each located in 
close proximity to the routers from which they're receiving flow-export
data.  A single instance of <tt>cfdcollect</tt> would be run on a 
centrally located server with plenty of disk space.

It should be noted that <tt>cflowd</tt> does not receive flow-export
packets directly.  A program called <tt>cflowdmux</tt> is responsible
for handling UDP packets from the Cisco routers, and will put the
packets in shared memory buffers which can be read by <tt>cflowd</tt>.
In addition, <tt>cflowd</tt> acts a server to local table clients like
<tt>cfdases</tt>, as well as acting as the server for
<tt>cfdcollect</tt>.  A more detailed diagram showing the data flow in
the system is seen in <bf>Figure 2</bf>.

<figure loc="ht">
<eps file="./dataflow2.ps" height="5in">
<img src="./dataflow2.gif">
<caption>
<label id="figure2">
<#if output="html">
Figure 2: cflowd data flow detail
</#if>
<#if output="ps|dvi|latex2e|latex">
cflowd data flow detail
</#if>
</caption>
</figure>

<sect>cflowd configuration
<p>

<tt>cflowd</tt>, <tt>cflowdmux</tt> and the local utilities 
(<tt>cfdases</tt>, <tt>cfdnets</tt>, et. al.) all read configuration
information from <tt>cflowd.conf</tt>.  In a standard installation,
<tt>cflowd.conf</tt> will be located in the <tt>/usr/local/arts/etc/</tt>
directory.

<tt>cflowd.conf</tt> contains three types of stanzas: an OPTIONS 
stanza specifying system-wide configuration values, CISCOEXPORTER stanzas
specifying configuration values for each Cisco from which we're collecting
data, and COLLECTOR stanzas specifying hosts from which we permit
<tt>cfdcollect</tt> connections.

<sect1>OPTIONS stanza
<p>

The OPTIONS stanza in <tt>cflowd.conf</tt> is used to set system-wide
configuration values for <tt>cflowd</tt>, <tt>cflowdmux</tt> and local
clients.  There should be a single OPTIONS stanza in <tt>cflowd.conf</tt>,
and it should be the first stanza.  Following are descriptions of each
of the settings in an OPTIONS stanza.

<sect2>LOGFACILITY <em>(optional)</em>
<p>

The LOGFACILITY setting is used to set the syslog facility that will
be used by <tt>cflowd</tt> and <tt>cflowdmux</tt> for logging.  If 
unspecified, <tt>local6</tt> will be used.

<sect2>TCPCOLLECTPORT <em>(optional)</em>
<p>

The TCPCOLLECTPORT setting is used to set the TCP port on which cflowd
will listen for connections from <tt>cfdcollect</tt>.  Connections
to this port are used for downloading tabular data from <tt>cflowd</tt>
and cause the tabular data in <tt>cflowd</tt> to be cleared after 
transmission.  Only hosts with a COLLECTOR stanza are permitted to
connect to this port and retrieve data.  Normally, a single 
<tt>cfdcollect</tt> will be running on a COLLECTOR host and be the only
program to connect to the TCPCOLLECTPORT.

If TCPCOLLECTPORT is unspecified, a default value of <tt>2056</tt> will
be used.

<sect2>PKTBUFSIZE <em>(optional)</em>
<p>

<tt>cflowdmux</tt> uses a 1 megabyte packet buffer by default, split
into 2 toggle buffers in a single shared memory segment.  Using the
PKTBUFSIZE setting, you may change the default size of the packet buffer
shared memory segment.  This option is typically used to increase the
size of the packet buffer.

<sect2>TABLESOCKFILE
<p>

The TABLESOCKFILE setting specifies the path to the named stream socket
on which <tt>cflowd</tt> will listen for local table client connections.
<tt>cflowd</tt> will accept connections from table clients on this socket.
Typical table clients are <tt>cfdases</tt>, <tt>cfdnets</tt>, et. al.

<sect2>FLOWDIR
<p>

Specifies the directory in which raw flow files should be stored.  This
is used when <tt>flows</tt> is specified in a CISCOEXPORTER stanza.

<sect2>FLOWFILELEN <em>(optional)</em>
<p>

Specifies the length of raw flow files.  <tt>cflowd</tt> will roll over
a raw flow file when it reaches this length.  <tt>cflowd</tt> will not
truncate a raw flow in a flow file, so it typically writes to some length
just below the FLOWFILELEN.  If unspecified, a default value of
<tt>1048576</tt> (1 megabyte) will be used.

<sect2>NUMFLOWFILES <em>(optional)</em>
<p>

Specifies the number of raw flow files to be user per router.  This
determines how many raw flow files will be kept by <tt>cflowd</tt> per
router.  If unspecified, a default value of <tt>10</tt> will be used.

<sect2>MINLOGMISSED <em>(optional)</em>
<p>

Specifies the threshold at which <tt>cflowd</tt> will syslog a message
about missed flows.  <tt>cflowd</tt> only does this when contacted by
<tt>cfdcollect</tt>.  If this value is unspecified, a default value of
300 will be used.

<sect2>Example
<p>

Below is an example OPTIONS stanza.  We've specified <tt>local6</tt> as
the LOGFACILITY, so <tt>cflowd</tt> and <tt>cflowdmux</tt> will syslog
using this facility.  We've specified a TCPCOLLECTPORT of 2056, so
<tt>cflowd</tt> will listen for connections from <tt>cfdcollect</tt> on
TCP port 2056.  <tt>cflowdmux</tt> will listen for raw flow client
connections on the named stream socket
<tt>/usr/local/arts/etc/cflowdmux.socket</tt> as specified with
RAWFLOWSOCKFILE.  <tt>cflowd</tt> will listen for connections from table
clients on the named stream socket
<tt>/usr/local/arts/etc/cflowdtable.socket</tt> as specified with
TABLESOCKFILE.  <tt>cflowd</tt> will store raw flow files in the
<tt>/usr/local/arts/data/cflowd</tt> directory if <tt>flows</tt> are
specified in the COLLECT portion of a CISCOEXPORTER stanza.  As
specified by FLOWFILELEN, <tt>cflowd</tt> will roll over a raw flow file
when it reaches <tt>1000000</tt> bytes.  <tt>10</tt> flow files will be
kept per router, as specified with NUMFLOWFILES.  As specified by
MINLOGMISSED, <tt>cflowd</tt> will syslog a message about missed flows
when there are more than <tt>300</tt> flows missed between queries from
<tt>cfdcollect</tt>.

<p>

<verb>
OPTIONS {
  LOGFACILITY:          local6
  TCPCOLLECTPORT:       2056  
  TABLESOCKFILE:        /usr/local/arts/etc/cflowdtable.socket
  FLOWDIR:              /usr/local/arts/data/cflowd
  FLOWFILELEN:          1000000
  NUMFLOWFILES:         10
  MINLOGMISSED:         300
}
</verb>

<sect1>CISCOEXPORTER stanza
<p>

The CISCOEXPORTER stanza is used to specify configuration values for a
single Cisco router.  There may be more than one CISCOEXPORTER stanza in
<tt>cflowd.conf</tt>, with each corresponding to a Cisco router from
which we would like to collect data.

<sect2>HOST
<p>

The HOST setting is used to specify the IP address of the Cisco.

<sect2>ADDRESSES
<p>

The ADDRESSES setting is used to specify the IP addresses of interfaces
on the Cisco router.  It's possible for flow-export packets to originate
from more than one interface on a Cisco router; the ADDRESSES setting
lets us specify multiple source addresses from which we'll accept
flow-export data for a single Cisco router.

<sect2>CFDATAPORT
<p>

The CFDATAPORT setting is used to specify the UDP port on which
<tt>cflowdmux</tt> should listen for flow-export packets from the Cisco
router.  This should match whatever you've configured as the flow-export
destination port on the Cisco router.

<sect2>LOCALAS <em>(optional)</em>
<p>

The LOCALAS setting is used to specify the local AS of the Cisco router.
This value is used when trying to fix 0 values in the source and
destination AS fields in flows from version 5 flow-export and in the
prefix aggregation flows in version 8 flow-export.  If LOCALAS is
unspecified, <tt>cflowd</tt> will not try to fix 0 values in the source
and destination AS fields.

<sect2>SNMPCOMM <em>(optional but recommended)</em>
<p>

SNMPCOMM is used to specify the SNMP (v1) community name to be used when
retrieving interface descriptions and IP addresses from the router
(ifDescr and ipAdEntIfIndex).  It should be enclosed in single quotes.
Currently we can't handle a community name that contains a single quote,
but this will be fixed soon.

<sect2>COLLECT
<p>

The COLLECT setting is used to specify the types of data that should 
be collected from the flow-export data for the Cisco router.  There
are several types of data which can be collected:

<itemize>
  <item> <tt>asmatrix</tt> - AS matrix (packets and bytes from source
    ASes to destination ASes)
  <item> <tt>netmatrix</tt> - net matrix (packets and bytes from source
    networks to destination networks)
  <item> <tt>portmatrix</tt> - port matrix (packets and bytes from 
    source ports to destination ports)
  <item> <tt>ifmatrix</tt> - interface matrix (packets and bytes from 
    input interfaces to output interfaces, by ifIndex)
  <item> <tt>protocol</tt> - protocol table (packets and bytes per
    IP protocol)
  <item> <tt>nexthop</tt> - IP nexthop table (packets and bytes per
    IP nexthop)
  <item> <tt>tos</tt> - TOS table (packets and bytes per IP TOS)
  <item> <tt>flows</tt> - raw flow data
</itemize>

<sect2>Example
<p>

An example CISCOEXPORTER is shown below.  It is for a router with an IP
address of 204.212.46.1 (the HOST) that is configured to flow-export to
port 2055 (the CFDATAPORT) on the host running <tt>cflowd</tt>.  We
specified two addresses for the Cisco router: 204.212.46.1 and
204.212.45.14.  These correspond to the IP addresses of different
interfaces on the Cisco router.  We specified a LOCALAS of 195,
corresponding to the local AS of the Cisco router.  We used COLLECT
to list the types of data which <tt>cflowd</tt> will collect for the
Cisco router using the flow-export data from the router.

<verb>

CISCOEXPORTER {
  HOST:         204.212.46.1            #  IP address of Cisco sending data.
  ADDRESSES:    { 204.212.46.1,         #  Addresses of interfaces on Cisco
                  204.212.45.14 }       #    sending data.
  CFDATAPORT:   2055                    #  Port on which to listen for data.
  SNMPCOMM:	'public'
  LOCALAS:      195                     #  Local AS of Cisco sending data.
  COLLECT:      { protocol, ifmatrix, portmatrix, netmatrix, 
                  nexthop, asmatrix, tos, flows }
}

</verb>

<sect1>COLLECTOR stanza
<p>

The COLLECTOR stanza is used to hold configuration values for a host
running <tt>cfdcollect</tt>.  In a standard configuration, there will
only be one or two of these, since a single <tt>cfdcollect</tt> host
is normally used to collect data from all instances of <tt>cflowd</tt>.
However, there may be more than one entry (for example, you may have
a hot backup host on which you will run <tt>cfdcollect</tt> when the
primary <tt>cfdcollect</tt> host is down).

<sect2>HOST
<p>

The HOST setting is used to specify the IP address of the host
running <tt>cfdcollect</tt>.

<sect2>ADDRESSES
<p>

The ADDRESSES setting is used to specify the IP addresses of the host
running <tt>cfdcollect</tt>.  <tt>cflowd</tt> will permit connections
from <tt>cfdcollect</tt> originating from any of the IP addresses in
the list.

<sect2>AUTH
<p>

Currently unused.

<sect2>Example
<p>

Below is an example COLLECTOR stanza.  This says that we will allow
connections from <tt>cfdcollect</tt> that come from 195.83.243.2 or
195.83.241.9, and we will assume that connections from either of
these addresses are from the same host.

<verb>

COLLECTOR {                             
  HOST:         195.83.243.2    # IP address of host running cfdcollect
  ADDRESSES:    { 195.83.243.2, 195.83.241.9 }  # other addresses of host
  AUTH:         none
}

</verb>

<sect>starting cflowd
<p>

<sect1>starting cflowdmux
<p>

<tt>cflowdmux</tt> should be started before <tt>cflowd</tt>.  It can be
started with no arguments, in which case it will use a compiled-in
default as the configuration file name (typically
<tt>/usr/local/arts/etc/cflowd.conf</tt>).  It will also accept an 
explicit configuration file name as the first argument.  Examples:

<verb>
  % cflowdmux
</verb>

would start <tt>cflowdmux</tt> using the compiled-in default 
configuration file.

<verb>
  % cflowdmux /etc/cflowd.conf
</verb>

would start <tt>cflowdmux</tt> using <tt>/etc/cflowd.conf</tt> as
the configuration file.

<sect1>starting cflowd
<p>

After starting <tt>cflowdmux</tt>, you should start <tt>cflowd</tt>.
Like <tt>cflowdmux</tt>, <tt>cflowd</tt> will use a compiled-in default
configuration file (typically <tt>/usr/local/arts/etc/cflowd.conf</tt>)
if given no arguments.  It will also accept an
explicit configuration file name as the first argument.  Examples:

<verb>
  % cflowd
</verb>

would start <tt>cflowd</tt> using the compiled-in default
configuration file.

<verb>
  % cflowd /etc/cflowd.conf
</verb>

would start <tt>cflowd</tt> using <tt>/etc/cflowd.conf</tt> as
the configuration file.

<sect>cflowd logging
<p>

<tt>cflowdmux</tt> and <tt>cflowd</tt> use <em>syslog(3)</em> to record
errors and runtime status information.  As a convention, each syslog
message starts with a capitalized letter in brackets indicating the
priority of the message:

<tabular ca=lll>
  <em>code</em> <colsep> <em>priority</em> <colsep> <em>description</em> <rowsep>
  <tt>[A]</tt>  <colsep> <tt>LOG_ALERT</tt> <colsep> fatal errors <rowsep>
  <tt>[C]</tt>  <colsep> <tt>LOG_CRIT</tt> <colsep> errors that need attention <rowsep>
  <tt>[E]</tt>  <colsep> <tt>LOG_ERR</tt> <colsep> error conditions <rowsep>
  <tt>[I]</tt>  <colsep> <tt>LOG_INFO</tt> <colsep> informational messages <rowsep>
</tabular>

<sect>cflowd debugging
<p>

There are a number of things to examine when trying to find a problem with
<tt>cflowdmux</tt> or <tt>cflowd</tt>.  

The first is the syslog messages.  In general, error messages will
indicate a problem (and should always be included in requests for 
assistance, whether directed at the author or the mailing list).

The second is the socket status.  On most UNIX systems, the output of
<tt>netstat -an</tt> will show you open sockets.  You should look for
open sockets on UDP ports for each unique CFDATAPORT in
<tt>cflowd.conf</tt>.  If you do not find an open socket for one of the
CFDATAPORT ports, there is a serious problem (and you should report it
to the author).  If you see a large receive queue value (on those
systems that report the queue length) for prolonged periods on any of
the CFDATAPORT ports, there is a serious problem (which should be
reported to the author).  Again using <tt>netstat -an</tt>, you should
look for an open TCP port in the LISTEN state for the TCPCOLLECTPORT
specified in the OPTIONS stanza of <tt>cflowd.conf</tt>.  The lack of
a socket in this state will prevent <tt>cfdcollect</tt> from working,
and is a serious problem which should be reported to the author.

A third source of information is the status of the shared memory segment
and the semaphore set.  These can be seen with <tt>ipcs -a</tt> on most
UNIX systems.  You should see a shared memory segment owned by the user
running <tt>cflowdmux</tt>, and at least 2 processes should be attached
(<tt>cflowdmux</tt> and <tt>cflowd</tt>).  The shared memory segment
should be approximately 2 megabytes in length.  You should also see a
semaphore set owned by the user running <tt>cflowdmux</tt>.  The size of
the semaphore set should be 2.

A final handy source of information is the output of <em>lsof(8)</em> if
you have it on your system.  In particular, the output of <tt>lsof -p
PID</tt> where PID is the process ID of <tt>cflowdmux</tt> or
<tt>cflowd</tt>.

<sect>cfdcollect configuration
<p>

<tt>cfdcollect</tt> uses a simple configuration file, typically named
<tt>cfdcollect.conf</tt> and located in the <tt>/usr/local/arts/etc/</tt>
directory.  <tt>cfdcollect.conf</tt> should contain two types of stanzas: 
a single 'system' stanza specifying system-wide values for 
<tt>cfdcollect</tt>, and one or more 'cflowd' stanzas (one for each instance
of <tt>cflowd</tt>).

<sect1>system stanza
<p>

The system stanza is used to set system-wide values for <tt>cfdcollect</tt>.
There should be only one of these in <tt>cfdcollect.conf</tt>, and it
should be the first stanza.  Following are descriptions of each of
the variables in the system stanza.

<sect2>logFacility
<p>

Sets the syslog facility to be used for logging by <tt>cfdcollect</tt>.

<sect2>dataDirectory
<p>

Sets the top-level directory in which to store ARTS data for each
router.  cfdcollect actually writes into subdirectories under
dataDirectory for each router, with the subdirectories named by the IP
address of each router (corresponding to the HOST setting for routers in
<tt>cflowd.conf</tt>).  For example, if you set <tt>dataDirectory</tt>
to <tt>/usr/local/arts/cflowd/data</tt>, the data for router
204.212.46.1 would wind up in the 
<tt>/usr/local/arts/cflowd/data/204.212.46.1</tt> directory.

<sect2>filePrefix
<p>

Sets the file prefix to be used when writing ARTS data to files.
<tt>cfdcollect</tt> uses filenames of the form
<em>filePrefix.YYYYMMDD</em> to store ARTS data.  Ther normal
<tt>filePrefix</tt> setting is 'arts'.  Continuing with the example from
the last section, data for router 204.212.46.1 for September 23, 1998
would wind up in
<tt>/usr/local/arts/cflowd/data/204.212.46.1/arts.19980923</tt>

<sect2>pidFile
<p>

Specifies the full path to the file in which <tt>cfdcollect</tt> should
store its process ID.

<sect2>Example
<p>

An example system stanza is shown below.  It tells <tt>cfdcollect</tt>
to syslog with the local6 facility, place data in the 
<tt>/usr/local/arts/data/cflowd</tt> directory, use 'arts' as the
file prefix when creating data files, and to store its process ID
in <tt>/usr/local/arts/etc/cfdcollect.pid</tt>.

<verb>
system {
  logFacility:          local6          #  Syslog to local6 facility.
  dataDirectory:        /usr/local/arts/data/cflowd
  filePrefix:           arts
  pidFile:              /usr/local/arts/etc/cfdcollect.pid
}
</verb>

<sect1>cflowd stanza
<p>

The cflowd stanza is used to set configuration variables for an instance
of <tt>cflowd</tt> from which we want <tt>cfdcollect</tt> to retrieve
data.  Following are the descriptions of each of the variables in the
cflowd stanza.

<sect2>host
<p>

The host running <tt>cflowd</tt>.  This may be a hostname or an IP 
address.

<sect2>tcpCollectPort
<p>

Sets the port to which to connect to on the host running 
<tt>cflowd</tt>.  This is the TCP port on which <tt>cflowd</tt>
is listening, corresponding to the TCPCOLLECTPORT setting in the OPTIONS
stanza of <tt>cflowd.conf</tt>.

<sect2>minPollInterval
<p>

Sets the minimum interval between connections to <tt>cflowd</tt>.  This
is not an exact interval timer, since <tt>cfdcollect</tt> processes all
<tt>cflowd</tt> instances with a single thread (serially).

<sect2>Example
<p>

Following is an example cflowd stanza.  It tells <tt>cfdcollect</tt>
to contact <tt>cflowd</tt> on foo.mydomain.net port 2056 every 300
seconds (5 minutes) to retrieve the tabular data from <tt>cflowd</tt>.

<verb>
cflowd {
  host:                 foo.mydomain.net
  tcpCollectPort:       2056
  minPollInterval:      300
}
</verb>

<sect>Network Service Provider NetFlow Configuration
<p>

In a network service provider environment, there are a number of 
considerations when configuring flow-switching and flow-export.
Focusing only on those relevant to data collection using 
<tt>cflowd</tt>, these are the critical issues:

<itemize>
  <item>The quantity of data.  In a large network, it's important
    to reduce (or eliminate) data duplication.  An optimal 
    configuration generates only the data you need.
  <item>The use of the data.  The granularity necessary for
    the typical use (capacity planning and traffic management) 
    must be available.
</itemize>

Data duplication has more than just performance and disk space
penalties; if the possiblity exists that you've recorded the same
traffic more than once in two different places, you often can't
aggregate the traffic data from those two different places in a
meaningful way without resorting to very granular duplication detection.

A typical network service provider wants source to destination traffic
information at the AS and network prefix level (the AS matrix and the
net matrix).  To obtain this information, they <bf>must</bf> use version
5 flow-export or use version 8 flow-export and configure the prefix
aggregation cache on the routers. 

A provider may optionally want the port matrix and the protocol table.
The necessary information is available in version 1, version 5 and
version 8 flow-export.  In the case of version 8, you need to configure
the protocol/port aggregation cache on the router(s).  In all cases, a
provider will want the information per input interface (not aggregated
across interfaces on a router) where available.

NetFlow data is input-based.  Flows are instantiated as traffic enters
the router, not as it exits.  When you configure flow-switching for an
interface on a Cisco router, flow data will be recorded for packets
received from the network by the interface (and not for packets received
from other interfaces on the router).  In other words, flow data is
recorded only in the receive direction per flow-switching interface.

Recording traffic data when the traffic first enters your network is
critical to security related activities (attack backtracking).  It's
also important for determining the offered load to your network; it
increases your data integrity (you get data on incoming traffic,
possibly above and beyond what your transit facilities will handle), and
it provides greater topological information (the source of your data is
closer to the source of the traffic for which the data was collected).

Another reason to collect data as it enters your network: in IOS images
using the prefix cache (not running any form of CEF), source netmask and
source AS lookups frequently return a cache miss and IOS will not resort
to a routing table lookup.  The result is frequent zero values in the
source AS and source netmask length fields in version 5 flow-export.
The prefix cache is populated by destinations, not sources; if traffic
to the source network is not seen frequently by the router, a prefix
cache entry will not exist for the source network.  Hence, asymmetric
paths aggravate the zero value problem.

Taking these constraints into account, an optimal configuration for a
network service provider usually looks something like <bf>Figure 3</bf>.
To avoid recording data more than once, enable flow-switching only on
interfaces at the edge of your network (external interfaces).  Since you'll
be collecting data as it enters the network, you'll also meet the other 
constraints.

<figure loc="hbp">
<eps file="./ispconfig1.ps" height="5in">
<img src="./ispconfig1.gif">
<caption>
<label id="figure3">
<#if output="html">
Figure 3: network service provider configuration
</#if>
<#if output="ps|dvi|latex2e|latex">
network service provider configuration
</#if>
</caption>
</figure>

<sect>More Information
<p>

Example configuration files are included in the cflowd package in the
<tt>etc/</tt> subsdirectory.  They're named <tt>cflowd.conf.example</tt>
and <tt>cfdcollect.conf.example</tt>.

<sect>Appendix A
<p>

<sect1>Version 1 flow-export
<p>

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 <tt>count</tt> 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.

<figure loc="htp">
<eps file="./v1FlowHeader.ps" height=2in>
<img src="./v1FlowHeader.gif">
<caption>
<label id="figure4">
<#if output="html">
Figure 4: version 1 flow-export flow header
</#if>
<#if output="ps|dvi|latex2e|latex">
version 1 flow-export flow header
</#if>
</caption>
</figure>

<figure loc="htp">
<eps file="./v1FlowEntry.ps" height=3.7in>
<img src="./v1FlowEntry.gif">
<caption>
<label id="figure5">
<#if output="html">
Figure 5: version 1 flow-export flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 1 flow-export flow entry
</#if>
</caption>
</figure>

<sect1>Version 5 flow-export
<p>

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 <tt>count</tt> 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.

<figure loc="htp">
<eps file="./v5FlowHeader.ps" height=2.45in>
<img src="./v5FlowHeader.gif">
<caption>
<label id="figure6">
<#if output="html">
Figure 6: version 5 flow-export flow header
</#if>
<#if output="ps|dvi|latex2e|latex">
version 5 flow-export flow header
</#if>
</caption>
</figure>

<figure loc="hbp">
<eps file="./v5FlowEntry.ps" height=3.75in>
<img src="./v5FlowEntry.gif">
<caption>
<label id="figure7">
<#if output="html">
Figure 7: version 5 flow-export flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 5 flow-export flow entry
</#if>
</caption>
</figure>

<sect1>Version 8 flow-export
<p>

<it>NOTE: version 8 flow-export is only available in IOS 12.0(2)S and
12.0(3)T images.</it>

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:

<#if output="ps|dvi|latex2e|latex">
<tt>ftp://ftp-eng.cisco.com/ftp/drowell/flow_agg.pdf</tt>
</#if>
<p>

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 (<tt>agg_method</tt>) that indicates the aggregation
cache from which the data was sent.  In combination with the
<tt>agg_version</tt>), 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).

<#if output="html">
<url url="ftp://ftp-eng.cisco.com/ftp/drowell/flow_agg.pdf">
</#if>

<figure loc="htp">
<eps file="./v8FlowHeader.ps" height=2.7in>
<img src="./v8FlowHeader.gif">
<caption>
<label id="figure8">
<#if output="html">
Figure 8: version 8 flow-export flow header
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export flow header
</#if>
</caption>
</figure>

<figure loc="htp">
<eps file="./v8FlowEntryAsAgg.ps" height=2.7in>
<img src="./v8FlowEntryAsAgg.gif">
<caption>
<label id="figure9">
<#if output="html">
Figure 9: version 8 flow-export AS aggregation flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export AS aggregation flow entry
</#if>
</caption>
</figure>

<figure loc="htp">
<eps file="./v8FlowEntryProtoPortAgg.ps" height=2.7in>
<img src="./v8FlowEntryProtoPortAgg.gif">
<caption>
<label id="figure10">
<#if output="html">
Figure 10: version 8 flow-export protocol/port aggregation flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export protocol/port aggregation flow entry
</#if>
</caption>
</figure>

<it>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.</it>

<figure loc="htp">
<eps file="./v8FlowEntryPrefixAgg.ps" height=3.4in>
<img src="./v8FlowEntryPrefixAgg.gif">
<caption>
<label id="figure11">
<#if output="html">
Figure 11: version 8 flow-export prefix aggregation flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export prefix aggregation flow entry
</#if>
</caption>
</figure>

<figure loc="htp">
<eps file="./v8FlowEntrySourcePrefixAgg.ps" height=3.0in>
<img src="./v8FlowEntrySourcePrefixAgg.gif">
<caption>
<label id="figure12">
<#if output="html">
Figure 12: version 8 flow-export source prefix aggregation flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export source prefix aggregation flow entry
</#if>
</caption>
</figure>

<it>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.</it>

<figure loc="htp">
<eps file="./v8FlowEntryDestinationPrefixAgg.ps" height=3.0in>
<img src="./v8FlowEntryDestinationPrefixAgg.gif">
<caption>
<label id="figure13">
<#if output="html">
Figure 13: version 8 flow-export destination prefix aggregation flow entry
</#if>
<#if output="ps|dvi|latex2e|latex">
version 8 flow-export destination prefix aggregation flow entry
</#if>
</caption>
</figure>

<it>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.</it>

</article>