This behavior comes from the sFlow version 5 spec at
https://sflow.org/sflow_version_5.txt  :

   The following values should be used for fields that are
   unknown (unless otherwise indicated in the structure
   definitions).
      - Unknown integer value. Use a value of 0 to indicate that
        a value is unknown.
      - Unknown counter. Use the maximum counter value to indicate
        that the counter is not available. Within any given sFlow
        session a particular counter must be always available, or
        always unavailable. An available counter may temporarily
        have the max value just before it rolls to zero. This is
        permitted.
      - Unknown string. Use the zero length empty string. */

So a constant value of 0xFFFFFFFF appearing in these counter fields means
"counter not available".    Does this answer your question?

I suppose it's a separate question to ask if maybe those discard counters
could be filled in now.  Definitely worth a look. The sFlow spec now allows
for the agent to send the headers of dropped packets too (rate limited,
 not sampled) so we may find that the OVS sFlow agent can be improved to do
rather more than just export the counter:
https://blog.sflow.com/2020/07/using-sflow-to-monitor-dropped-packets.html

Neil



On Sun, Mar 31, 2024 at 8:32 PM 李兴鑫 via discuss <ovs-discuss@openvswitch.org>
wrote:

>    Hi. Nearly, I found the values both of IfOutDiscards and IfInDiscards
> are 2^31-1 in our environment. The SFlow returned a record is filled its
> all bits with 1. I checked the relevant code, the implementation of SFlow
> in OVS ignored the error from netdev_get_stats (see
> https://github.com/openvswitch/ovs/blob/c6538b443984e10c266d7e75e797ef2f1b722d61/ofproto/ofproto-dpif-sflow.c#L351),
> caused some bad values are reported. But in RFC2233, A SFlow implement
> 'MUST NOT' instantiates an object with an incorrect value(see
> https://www.rfc-editor.org/rfc/rfc2233.txt#:~:text=specific%20MIB.%0A%0A3.1.18.-,All%20Values%20Must%20be%20Known,-There%20are%20a
>  ).
>
>   So, I think we had better return an error here, but not ignore it.
> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to