Flows exported from a router are encapsulated in a UDP datagram.  Each{engine_type,engine_id} pair generate a unique sequence number.  Thesequence number is the total flows generated by the linecard.  There areno cryptographic checksums and no retransmissions for lost packets.The sequence number is 32 bits, engine_type and engine_id are both 8bits.  This leads to 65536 unique 32 bit sequence numbers.Flow-tools will log out of sequence flow export packets.  It will notreject out of sequence, or attempt to filter duplicate exports.  Loggingis done via syslog for flow-capture and stderr for flow-receive.Additionally each flow file will record the number of lost flows andcorrupt packets received during the capture period.Loss of flow exports is usually a result of resource exhaustion on therouter, link to the flow collector, or the flow collector itself.  "showip flow export" on the router will list some sources of lost flows.  Checkoutput 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 displayUDP packets dropped due to full socket buffers.  This is usually an indicationof an overworked server.The sequence numbers change fast enough on a busy router that an attackerwould probably need to snoop the path between the exporter and the router tosuccessfully inject packets for a valid engine.  Without the attackercausing the real exports from the router to be dropped flow-tools woulddetect the duplicate sequence number and log an error.  Unfortunately thereis nothing preventing an attacker from using an {engine_type,engine_id} pairthat is not in use by the router to inject their own flows.  There iscurrently no way to know which {engine_type,engine_id} pairs therouter will use.To defend against an attacker injecting bogus flow exports the pathbetween the router and flow collector must prevent source IP addressspoofing, either with access lists or unicast RPF checks.  Flow-capturerequires the source IP of the exporter to be defined and will count anypackets received from a different IP in the pkts_corrupt counter.flow-receive does not require the exporter to be defined for debuggingpurposes, although after the first flow is received all further flowsmust use the same source IP.  Configure 'ip flow-export source loopback0'and set a loopback0 address on the router to ensure the same IP addressis always used when exporting flows.Another option the attacker has is to disable or disrupt the flowcollection server.  This could be done by packet flooding the serveror the path to it, resulting in lost flow exports.  Ideally the flowcollector would be directly connected to the router on a dedicated interface with strict access lists only permitting the flow exportsand administrative traffic.