Nagios Support Forum

I observed something the other day which didn't make sense to me. I am collecting data from a pfSense firewall.

Here is a graph showing the top 5 talkers:
So the top two talkers are:
10.25.2.1 = DNS Server = 38% bytes
10.25.6.21 = vMA Server = 34% bytes

You can see my mouse hovering over a point where it says 7GB. Now I know these two servers are not generating 7GB of data.

So here's a report of that same time period for the top 5 talkers:
You can see the bytes:
10.25.2.1 = DNS Server = 7.13 MB
10.25.6.21 = vMA Server = 6.38 MB

So where's this mystery 7GB coming from and why isn't it in the top 5?

I know what that timeperiod reflects and I know the traffic is real but I don't know why the data is being collected. Let me explain.

I have a virtual Windows Home Server.
I also have a physical Intel NUC that has a USB3 drive connected and shared.
The Windows Home Server connects to this virtual USB3 drive on the NUC and it appears as a USB drive in the Windows Home Server.
The Windows Home Server uses this as it's backup drive.
What you are seeing in the graphs is the Sunday backup that happens from midnight to 9am.
HOWEVER the traffic between the two servers is in the SAME subnet.
The pfSense firewall is the default gateway for the network.


So my questions are:
Why is my source showing this traffic when it does not pass through the pfSense firewall?
Why is pfSense sending this in the flow data?
Even if pfSense is sending the data when it should not, why does the data exist but does not appear as a top 5 talker?

Is this netflow or sFlow?

Why is my source showing this traffic when it does not pass through the pfSense firewall?

Not sure, but read below...

Why is pfSense sending this in the flow data?

Not sure, read below...

Even if pfSense is sending the data when it should not, why does the data exist but does not appear as a top 5 talker?

The RRD bandwidth data is put in every 5 minutes when the raw flow data is saved. The nfdump query that it runs to get the data is actually aggregating by destination port... so you should try to match it up with that instead of srcip. Below is the nfdump query it runs when it generates a new set of data points for the RRD.

/usr/local/bin/nfdump -r /usr/local/nagiosna/var/MySource/flows/nfcapd.201502181145 -s dstport -n -N -o csv

So basically if it was a backup - then it would make sense that looking at the incoming bandwidth (via your top 5 talkers on source ip) would have nothing and your destination would have much much more.

jomann wrote:Is this netflow or sFlow?

It appears to be NetFlow, see screenshot:

jomann wrote:So basically if it was a backup - then it would make sense that looking at the incoming bandwidth (via your top 5 talkers on source ip) would have nothing and your destination would have much much more.

Good point. Here is the report for the same time period with grouping by "Destination IP":
Which shows 100% of the traffic is other ???
Also the second pie chart never appears, the spinning logo just shows.

jomann wrote:The nfdump query that it runs to get the data is actually aggregating by destination port... so you should try to match it up with that instead of srcip.

OK, So I've generated two more reports:

Source Port: Destination Port:
I'm not understanding what is going on here.

I finally got to the bottom of this.

Network Analyzer is running in a VM on an ESXi server.
The data this source is coming from, a virtual pfSense server, is also on this ESXi server.

The virtual switch these VMs are connected to has promiscuous mode set to Accept.

The result of this is basically turning the virtual switch into a hub, all VM's connected to that switch see all traffic from all devices. The pfSense firewall is sending that traffic in the flows and hence the extra data is collected.

Promiscuous mode was configured this way, as I was running virtual ESXi servers on top of the hardware ESXi server. The solution was to create a portgroup within the virtual switch that is specifically for the virtual ESXi servers, and that portgroup has promiscuous mode set to Accept. Then at the virtual switch level I configured promiscuous mode set to Reject.

Since I've made the change, the graphs no longer show this "mystery data". You can see this here, the past 2 days no longer show the peaks AND you can see the baseline data is smaller as well.