[c-nsp] Speaking of Netflow: how about a tcpreplay for netflow?

[Adam Powers]

Just a note, many flow collectors that are worth their weight will function
just fine with replayed data. When flows are received at the collector the
timestamp is checked or sanity. If it¹s too far behind or ahead the
collector¹s system timestamp is slammed into the flow timestamp to normalize
the export time. Since the StealthWatch NetFlow collector doesn¹t use
timestamps for deduplication this ³timestamp normalization² strategy doesn¹t
hurt a thing.


On 1/11/08 12:34 PM, "Joel M Snyder" <Joel.Snyder at opus1.com> wrote:

> 
> 
>>  > One option would be to use tcpreplay to replay packet captures which
>>  > would then traverse NetFlow exporters which would generate the NetFlow
>>  > in question, heh.
>>  >
>>  > ;>
>>  >
>>  > What's the application, if you don't mind sharing?  Most
> 
> The application is a training and testing environment (that's what we do, in
> addition to running a small Cisco-based ISP).  If I want to test, for example,
> the Lancope box (just as an example), then I have to have a nice, consistent,
> and completely repeatable set of Netflows that I can throw at it over and over
> and over again.  However, the timestamps have to be "right" because it might
> be
> correlating that data with some IDS feed or Nessus traffic that is also
> properly
> timestamped.  I've solved the IDS & Nessus problems pretty well.
> 
> The exporter idea is a great one, and I've thought of doing that, but it adds
> another piece of test gear to the mix and just makes things more complex.  And
> if we take this show on the road (which happens once in a while), it also adds
> to costs.  I've already got a big infrastructure for doing tcpreplay; I was
> hoping to just add a few more shell scripts to get netflow-replay going.
> 
> Another piece of the application is combining and speeding up data.  For
> example, I might have one particular kind of traffic that I'm creating today,
> and a different profile tomorrow, but then want to combine the Netflows for a
> larger test that shows different characteristics.  For example, you might have
> short packets/short flows, then long packets/long flows, and finally a "mix"
> of
> all of them.  So being able to merge and concatenate the files around makes
> life
> a lot easier.
> 
> I am sure that the Netflow analyzer guys out there must have some internal
> tool
> for doing this (although maybe they don't care about the timestamps the way I
> do), but no one is kicking it out to open source---at least as far as I can
> tell.
> 
> jms
> 
> 
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One       Phone: +1 520 324 0494
> jms at Opus1.COM                http://www.opus1.com/jms
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



-- 

Adam  Powers
Chief Technology Officer
Lancope, Inc.
c. 678.725.1028
f. 678.302.8744
e. adam at lancope.com