sampling_direction aggregation breaks sFlow accounting

[Paweł Małachowski]

Description
Using "sampling_direction" causes:

• for "print" plugin, prints 0 bytes per flow
• for "memory" plugin, no flows are reported by pmacct -s -p x.fifo command

Version

• "print" observed with 1.7.6 and 1.7.7 from Debian bullseye and bookworm packages
• "memory" observed with 1.7.2 from Debian buster packages

Config

sfacctd.conf

plugins: print
print_refresh_time: 1
daemonize: false
sfacctd_ip: 0.0.0.0
sfacctd_port: 6343
aggregate: src_host, dst_host, sampling_direction, peer_src_ip, in_iface, out_iface
plugin_exit_any: true

sfacctd.conf excerpt for memory:

aggregate[mem]: tag, tag2, proto, vlan, cos, tos, peer_src_ip, in_iface, out_iface, src_as, dst_as, sampling_direction

[Paolo Lucente]

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

[Paweł Małachowski]

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. :)

[Paolo Lucente]

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

[Paweł Małachowski]

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

[Paolo Lucente]

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

[Paweł Małachowski]

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