Flows exported from a router are encapsulated in a UDP datagram.  Each
{engine_type,engine_id} pair generate a unique sequence number.  The
sequence number is the total flows generated by the linecard.  There are
no cryptographic checksums and no retransmissions for lost packets.
The sequence number is 32 bits, engine_type and engine_id are both 8
bits.  This leads to 65536 unique 32 bit sequence numbers.

Flow-tools will log out of sequence flow export packets.  It will not
reject out of sequence, or attempt to filter duplicate exports.  Logging
is done via syslog for flow-capture and stderr for flow-receive.
Additionally each flow file will record the number of lost flows and
corrupt packets received during the capture period.

Loss of flow exports is usually a result of resource exhaustion on the
router, link to the flow collector, or the flow collector itself.  "show
ip flow export" on the router will list some sources of lost flows.  Check
output drops on the interface directly connected to the flow collector.
On 7500's the interface command "transmit-buffers backing-store"
can reduce output drops.  Use netstat -s on the flow collector to display
UDP packets dropped due to full socket buffers.  This is usually an indication
of an overworked server.

The sequence numbers change fast enough on a busy router that an attacker
would probably need to snoop the path between the exporter and the router to
successfully inject packets for a valid engine.  Without the attacker
causing the real exports from the router to be dropped flow-tools would
detect the duplicate sequence number and log an error.  Unfortunately there
is nothing preventing an attacker from using an {engine_type,engine_id} pair
that is not in use by the router to inject their own flows.  There is
currently no way to know which {engine_type,engine_id} pairs the
router will use.

To defend against an attacker injecting bogus flow exports the path
between the router and flow collector must prevent source IP address
spoofing, either with access lists or unicast RPF checks.  Flow-capture
requires the source IP of the exporter to be defined and will count any
packets received from a different IP in the pkts_corrupt counter.
flow-receive does not require the exporter to be defined for debugging
purposes, although after the first flow is received all further flows
must use the same source IP.  Configure 'ip flow-export source loopback0'
and set a loopback0 address on the router to ensure the same IP address
is always used when exporting flows.

Another option the attacker has is to disable or disrupt the flow
collection server.  This could be done by packet flooding the server
or the path to it, resulting in lost flow exports.  Ideally the flow
collector would be directly connected to the router on a dedicated 
interface with strict access lists only permitting the flow exports
and administrative traffic.