softflowd only sending netflow data in large intervals

[jwalcheuronet]

I have a softflowd running on a pretty busy linux router like this (sending netflow data to a central collector)
softflowd -i 4 bond0.4 -v 9 -m 500000 -n 10.25.3.18:2055 -N

The statistics do make sense (see below). However only very periodically (every couple of minutes) it does send a couple of netflow messages. The behaviour from other probes I have used seems to be that it´s constantly sending netflow messages.

Am I misunderstanding something? Is it related to this option
-s sampling_rate Specify periodical sampling rate (denominator)

But what does that option actually do?

softflowd[410386]: Accumulated statistics since 2022-11-17T09:29:40 UTC:
Number of active flows: 144606
Packets processed: 151952619
Fragments: 32680
Ignored packets: 2782 (2782 non-IP, 0 too short)
Flows expired: 1171459 (0 forced)
Flows exported: 1171459 (2327022 records) in 73622 packets (0 failures)
Packets received by libpcap: 151980220
Packets dropped by libpcap: 24550
Packets dropped by interface: 0

Expired flow statistics: minimum average maximum
Flow bytes: 28 35582 4286655911
Flow packets: 1 50 6080016
Duration: 0.00s 31.11s 3785.06s

Expired flow reasons:
tcp = 2607 tcp.rst = 341240 tcp.fin = 738363
udp = 87002 icmp = 2241 general = 0
maxlife = 0
over 2 GiB = 6
maxflows = 0
flushed = 0

Per-protocol statistics: Octets Packets Avg Life Max Life
Unknown (1): 1863810 13082 213.78s 3537.51s
Unknown (6): 30785999831 43741769 26.91s 3785.06s
Unknown (17): 2501641443 3714935 78.58s 3468.16s
Unknown (47): 8393006074 11106768 1546.80s 1564.91s

[systemcrash]

Hmm - while my experience with this software is still limited, I can summarize my findings as such:

running the software on switches, the flow data comes in rapidly, and I've noticed that start and end times are effectively simultaneous, which means the switch is not actually monitoring flows, but packets. Switches try to be efficient, and doing stateful monitoring requires more memory and resources.

Whereas the software when run on a router (which generally has more resources and memory available) actually tracks flows, and only when (long running) flows are torn down, do they get reported.

Sampling rate is just how many packets are actually sampled per X that traverse. 1 per 10 is 10. So you only see 1/10th of the flows, but your resource requirements are lower.

[robinp]

@jwalcheuronet look at the default timeouts (for example at https://manpages.debian.org/testing/softflowd/softflowd.8.en.html#Timeouts).

They are all pretty large by default, you can inspect them with softflowctl timeouts. You can set these with -t <kind>=<value> to softflowctl.

Also, you can do tests with one-off forcing of flows using softflowctl expire-all. Hope this sets you (or posterior people with similar problem) on track.