Hi Ivan and Peter,
while the idea of integrating a kind of sFlow/NetFlow probe has been
already considered (i remember some thoughts recently exchanged with
Sven Anderson about this), i'm somewhat not fully convinced. 

In a first instance it will take time as it's absolutely not trivial;
this has been correctly noted by Ivan and somewhat answers to the
question from Peter.

But my point is the following: out there we already have a range of
NetFlow probes, ie. softflowd, nprobe, fprobe to name a few; don't
actually know if exists any for sFlow (out of curiosity, Ivan, can
you confirm this ?). There is also choise for replicators, ie. UDP
samplicator, flow-fanout - which is part of flow-tools. 

I know that not every possible scenario is covered, but most common
ones should be adequately fitted by joining these tools, resulting
in a flexible and MODULAR architecture for capturing network data:


------ packets --------- [ netflow probe ] -
                                            |-----
------ NetFlow stream ----------------------      |
                                                  |
[ tool A ]------------\                           |
[ tool B ]--------------- [ replicator ] ---------
[ pmacct ]------------/

I would underline the modularity: the above scheme shows how you
can pick any of the modules (represented as []) and segregate it
as you like: from a all-in-one box, to each module placed onto a
different box, thus allowing to scale and tailor the capturing
enviroment to even the most busy scenarios.

Integrating either the probe or the replicator into any pmacct
daemon will be certainly useful but would also result in a not
proper approach, in my opinion. 

Comments, any thoughts ?

Cheers,
Paolo



_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists

Reply via email to