sampling_direction aggregation breaks sFlow accounting about pmacct

[pawmal]

I've tested with Aritsta EOS, sampling configured ingress+egress on peering ports, prints 'i' and 'e' as expected, thank you.

[paololucente]

Hi Pawel ( @pawmal ),

Thanks for reporting this. I verified the issue occurring still in master code and fixed it with the commit referenced above. Interestingly, sFlow Flow Samples do not have a direct way to detect the sampling direction so the field does not really apply to sfacctd and it will print always u, unknown.

Paolo

[pawmal]

It is a bit confusing, as "pretag.map.example" provides "direction" matcher.

While it uses IPFIX (61) direction field, it is allowed to be used by sfacctd as well, where it has value derived from "source_id".
Therefore I assumed aggregate by sampling_direction for sFlow will expose same 0 or 1 value, as pretag.map refers to.

in sFlow v2/v4/v5 this returns a positive match if: 1) source_id equals to input interface and this 'direction' key is set to '0' or 2) source_id equals to output interface and this 'direction' key is set to '1'.

Even more confusing, it is unspecified how "source_id" is filled for sFlow. :)

[paololucente]

Hi Pawel,

Thanks for insisting on this. I effectively had to refresh my memory and re-look at code. To your points:

1. I have aligned behavior of sampling_direction primitive to direction key in pre_tag_map. So, effectively, sampling direction is now supported on sFlow;

2. sFlow and source_id: this is how it is traditionally (we'll come back on the traditionally part later) populated, and i have added a comment in both sections of the code: "In the standard sFlow data model, every measurement comes from a particular datasource defined by agent IP address, ds_class and ds_index, and written as agent>ds_class:ds_index. For example the interface counters for interface 17 on switch 10.1.2.3 come from datasource 10.1.2.3>0:17".

So what now happens in both points of the code is that, say, input interface of a flow sample is 17 and ds_index (the last number of source id) is 17 then it is inferred that sampling direction is ingress. Similarly if 17 is output interface of a flow sample and that matches the ds_index, it is inferred that sampling direction is egress. Hope this explains & makes sense.

This all said, coming back on the traditionally part, the whole scheme here holds up to the moment in which things are encoded in the source ID as expected.

Paolo

[pawmal]

Thanks, this clarifies how it works. :)
My understanding is there are 3 values possible: in (0), out(1) and unknown(u).

[paololucente]

3 values, exactly right! ingress (i), egress (e), unknown (u).