Open source Netflow analysis for monitoring AS-to-AS traffic
Peter Phaal
peter.phaal at gmail.com
Fri Mar 29 20:08:17 UTC 2024
The sFlow frame_length field isn't intended to be vague. If you are seeing
non-conforming sFlow implementations, please raise the issue with the
vendor so they can fix the issue.
Verifying that the frame_length and stripped fields are correctly
implemented is one of the tests performed by the sFlow Test tool and
running the tool can be helpful in persuading a vendor that they are out of
compliance:
https://blog.sflow.com/2015/11/sflow-test.html
The following language is included in the sFlow Version 5 spec,
https://sflow.org/sflow_version_5.txt.
/* Raw Packet Header */
/* opaque = flow_data; enterprise = 0; format = 1 */
struct sampled_header {
header_protocol protocol; /* Format of sampled header */
unsigned int frame_length; /* Original length of packet before
sampling.
Note: For a layer 2 header_protocol,
length is total number of octets
of data received on the network
(excluding framing bits but
including FCS octets).
Hardware limitations may
prevent an exact reporting
of the underlying frame length,
but an agent should attempt to
be as accurate as possible. Any
octets added to the frame_length
to compensate for encapsulations
removed by the underlying
hardware
must also be added to the
stripped
count. */
v1.00 sFlow.org [Page 35]
FINAL sFlow Version 5 July 2004
unsigned int stripped; /* The number of octets removed from
the packet before extracting the
header<> octets. Trailing
encapsulation
data corresponding to any leading
encapsulations that were stripped must
also be stripped. Trailing
encapsulation
data for the outermost protocol layer
included in the sampled header must be
stripped.
In the case of a non-encapsulated
802.3
packet stripped >= 4 since VLAN tag
information might have been stripped
off
in addition to the FCS.
Outer encapsulations that are
ambiguous,
or not one of the standard
header_protocol
must be stripped. */
opaque header<>; /* Header bytes */
}
On Fri, Mar 29, 2024 at 12:46 PM Steven Bakker <steven.bakker at ams-ix.net>
wrote:
> To top it off, both the sFlow and IPFIX specs are sufficiently vague about
> the meaning of the "frame size", so vendors can implement whatever they
> want (include/exclude padding, include/exclude FCS). This implies that you
> shouldn't trust these fields.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240329/4b62959e/attachment.html>
More information about the NANOG
mailing list