On 3 March 2016 at 22:40, Daniel Rohan <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
