Verifying flow to biflow conversion

[Carter Bullard via Argus-info]

Hey Richard,
Thanks for the update. Ahhhhhhh, with 1 : 10 sampling you will not get much to stitch back together, maybe 1 : 5000 - 10000 flows are merge-able, since so many flows are very short lived.  For example DNS and HTTP single transactions are primarily under 10 packets, total, you’ll .  The big elephants do well, but if you have a big elephant network, you don’t really need to sample.

We are building out the commercial side of Argus this year, and are testing our 10, 40 and 100G argus appliances now, around the US, with target delivery for end end of the fall (northern hemisphere fall).  If you are interested, send me email directly.

Glad to hear that argus is helping out … Hope all is most excellent,
Carter
 

> On Jul 25, 2016, at 6:44 PM, Richard Rothwell via Argus-info <argus-info at lists.andrew.cmu.edu> wrote:
> 
> Hi Carter,
> 
> The problem with using the Argus daemon directly is that the AARNet traffic is carried on a big boy 100Gig network.
> A direct Argus tap on this network is not feasible.
> 
> In principle putting Argus probes on the 10Gig branches would work, but is probably not practical.
> We may prototype this approach later.
> 
> There are also indications that the ratio of source to destination traffic is too high,
> _  leading me to suspect that 1 in 10 router sampling prevents biflows from being constructed from flows in most cases.
> 
> Consequently, after some discussion, we have decided to turn off biflow collection while we check other things.
> Same Argus records will be collected, just zero values for the destination packets and bytes fields.
> In other words we will just use ra not rabins. 
> 
> AARNet requirements do not include GLORIAD’s “end-to-end performance” monitoring requirements, so that is not a consideration.
> 
> Regards
> 
> P.S. The missing router srcid issue mentioned previously, was solved by splitting off the Perl code handling the Argus client connection
> _ into a separate application. Then multiple instances of this new application are executed, one per router. This application supplies the router srcid via
> _ a configuration file. Then all of the resulting biflow traffic from all the routers is merged into a processing Perl application via ZeroMQ PUSH/PULL.
>