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@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.