[j-nsp] flow collisions?

[Saku Ytti]

On 3 March 2016 at 22:40, Daniel Rohan <drohan at gmail.com> wrote:

Hey,

> Flow insert Policer Drops, AS Lookup Error, RR Lookup Error, Flow
> Collision Error, Flow Insert Error are all incrementing.
>
> I can kind of infer what these mean if I think of a flow export table
> that fills up with flow data and then is sent off in a record to the
> collector (ie, policer makes sure the table capacity is never
> overrun), but am completely clueless about flow collisions, insert
> errors RR Lookup Errors (what's a route reflector got to do with
> exporting IPFIX?) and whether or not my assumptions about the table

Stabbing in the dark, I don't think any of this is documented in any
customer visible docs.

RR certainly isn't route reflector, I'm guessing it's route record.

Flow Collision is likely something that is normal, and may be
dynamically handled by various means, probably will cause more
exhaustive/expensive search for correct record.
This is same problem as in any hash solution, like maybe ethernet DMAC
lookup or such. Your keys is your flow keys, source ip, destination
ip, source port, destination port, interfaces etc. You need to update
packet and byte counter for record having these keys every time you
process a packet (or within sampling rate). Exhaustive search for
potentially million or many million flows is expensive. You can make
it cheaper, by using small hashes which point to a hash bucket of
fixed size store, where you then might do cheap exhaustive search.
Any specifics are highly implementation specifics, but personally I
wouldn't worry about it. Intuitively if you've processed 5789149275620
packets and you've got 1296095760 collisions that's only 0.2%, so
99.8% times you've updated the counters with cheap lookup. But to know
if this is lot or not, we'd need to know performance when there is no
collision and performance when there is collision.

-- 
  ++ytti