If memory serves me right, Peter Phaal wrote:
> Support for the extended_switch structure is not mandatory in the sFlow
> standard, but most vendors do export the structure.
> All sFlow implementations that I am aware of export the sampled_header
> when they sample packets. The sampled_header is the preferred structure
> and the standard only permits sampled_ethernet, sampled_ipv4,
> sampled_ipv6 structures if the switch hardware is incapable of supplying
> the packet header.
> Most NetFlow collectors are also capable of collecting sFlow records (at
> a minimum decoding the NetFlow 5 equivalent fields from the sampled
> packet header).
Many thanks for the helpful reply!
I'm thinking about this from the standpoint of a service provider's
routers. In my mind, the router already did the packet decoding
(because it had to do this for routing decisions), and it'd just be
convenient to shove the cooked data into sample records in addition to
the packet header to avoid making the collector re-do the packet decode.
The mental picture I had was that an L3 router would be able to export
sampled_header, sampled_ethernet, and sampled_ipv4/sampled_ipv6...based
on the text in the bottom half of p. 33 of the sFlow version 5 standard.
Perhaps I misinterpreted your intent there?
> You should check with your switch vendor to see what other extended flow
> records they support (e.g. extended_router, extended_gateway,
> extended_mpls, etc). If you are using link aggregation, then you should
> ask about support for the LAG extension, http://sflow.org/sflow_lag.txt
> FYI a catalog is sFlow structures is maintained on
> sFlow.org, http://sflow.org/developers/structures.php
> You might want to take a look at
> sflowtool, https://github.com/sflow/sflowtool
. It can decode all the
> sFlow records types as well as the sampled_header. It also can convert
> sFlow into NetFlow versions 5 and 9. sflowtool can also pass the packet
> headers in pcap format to tools like wireshark and tcpdump:
Many thanks for the pointers! Some of these were new to me, so much
> It's important to understand the architectural differences between sFlow
> and NetFlow. One way to think about sFlow is as a disaggregation of
> NetFlow, implementing the packet sampling on the device and shifting the
> flow cache to external software, e.g.:
Got it (I've worked on NetFlow collectors before).
I looked through sflowtool. From a casual read of the code it looks
like if it's configured to emit NetFlow records, it generates one
NetFlow record for every sFlow packet sample, in other words it's not
doing any of the flow cache functionality that a NetFlow exporter would
normally do. So as with the sFlow architecture in general, it's
accepting the cost of a higher data rate between the exporter and the
collector in favor of exporting more detail on individual packet samples
(not aggregated in time) and potentially simpler logic on the collection
device. Is that correct?