Project

General

Profile

Actions

Bug #14747

closed

softflowd sending same data with different snmp versions

Added by Marcelo Cury 8 months ago. Updated 8 months ago.

Status:
Needs Patch
Priority:
Low
Assignee:
-
Category:
softflowd
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
23.05.1
Affected Architecture:
4100

Description

My environment:

SG-4100 23.05.1, packages up to date and System patches applied.
sotflowd running on LAN, WIFI and MGMT interfaces only.
Graylog version 5.1.4 | mongodb 6.0.8 | elasticsearch 7.10.2 | Input NetFlow UDP

What I'm trying to do:

I'm sending Netflow data from pfSense (softflowd) to a Graylog server.
I'm using Graylog to sum the amount of data passed through an interface, to get a list of top Talkers in a determined time frame.

What I observed:

I noticed that the sum in Graylog is not matching the data because the same flow is sent sometimes twice, sometimes three times.
What differs from these sent flows from softflowd to Graylog are the nf_input_snmp, nf_snmp_output and nf_flow_packet_id fields.

Here are the three flows expanded in details:

one flow sent three times with diff snmp versions

I've been trying to see if there is a pattern here, and it seems that: (take the statement below with a grain of salt).
Intervlan traffic is sent three times, with all the snmp versions.
Traffic from LAN to WAN, or WIFI to WAN, or MGMT to WAN is sent twice, with SNMP versions 2 and 3 only.


Files

clipboard-202309041446-etky4.png (64.1 KB) clipboard-202309041446-etky4.png one flow sent three times with diff snmp versions Marcelo Cury, 09/04/2023 05:46 PM
Actions #1

Updated by Marcelo Cury 8 months ago

Actions #2

Updated by Marcelo Cury 8 months ago

It seems that the problem is related to VLAN interfaces.
I've been doing some tests and if you set softflowd to collect only from non VLAN interfaces, the problem doesn't happen.

These two interfaces are making softflowd to act in a weird way.
igc1.10
igc1.20

Actions #3

Updated by Jim Pingle 8 months ago

  • Status changed from New to Needs Patch

That looks like something specific to the behavior of the daemon which is out of our control (unless there is a CLI/config option to change the behavior, which there doesn't appear to be).

If they fix it upstream, we'll eventually get the fix naturally when it works its way into the ports tree.

Actions

Also available in: Atom PDF