Rune,
The sflowtool utility turns sampled packet headers into NetFlow v5
records and forwards them immediately without aggregation, so you may
see multiple records from the same TCP connection. NetFlow collectors
always have to be prepared for this happening, so it's unlikely to
cause problems. What you end up with is essentially the same as the
"sampled-netflow" you can get from Cisco or Juniper routers.
For typical network traffic (mostly short flows) the majority of
samples are going to be from different L4 flows anyway, so adding an
extra aggregation step in sflowtool wouldn't make much difference.
In fact, this is why sFlow just sends the raw packet-header. Why
pull out 7 fields when you can have them all? If your collector
accepts sFlow directly then your analysis can include layer-2
information (such as MAC, VLAN) non-TCP/IP protocols (such as ARP,
Spanning-Tree, IPv6) and various other fields that can be remarkably
informative (such as IP-TTL, HTTP-URL).
Does this answer your question?
regards,
Neil
On May 26, 2008, at 8:57 AM, Rune V. Sjxen wrote:
> I am looking at converting sFlow samples to Netflow format using
> sflowtool.
> Is each sFlow flowsample converted to a Netflow conversation (flow
> sample)
> which as I understand is intended to depict a whole conversation or
> at least
> a count of all the packets between the 7-tuple which identifies the
> conversation. Does each sflow flowsample represent its own
> conversation ?
>
> What limitations are there (in regards to data mining/statistical
> analysis)
> when using data converted through sflowtool compared to original
> netflow
> samples ?
>
> --
> Rune V. Sjoen
> You always pass failure on the way to success
--- Neil Mckee neil.mckee@inmon.comReceived on Tue May 27 23:13:50 2008
This archive was generated by hypermail 2.1.8 : 05/27/08 PDT