Multiple NetFlow sensors per Device.

hello,

you should be able to have several netflow sensors per device without any issues.

Can you describe the problem in more detail?

Are the Netflow sensors set up the same way? Are you using filters or did you define your own channels?

What device are you monitoring?

Using a Sonicwall NSA 2400 on the latest firmware.

It ended up being something else, I loaded up the Netflow tester and found that it was receiving packets from the day before. I restarted the sonicwall to clear out all the backlog, I think all the backlog started after changing a netflow setting, so it had nothing to do with the multiple monitors.

Although I think I have another problem, below is my channel configuration. Some channels don't seem to work, the SMB-NetBT channel doesn't log as much throughput as I am expecting.

The other ones "Sydney-HTTP" for example works perfectly, but a file copy should yield results in the "Sydney-SMB-NetBT" channel, but it's about 10% of the throughput I am seeing in the file copy process. It's over a private MPLS link so they're no write-caching happening.

Here's my channel configuration:

1. 801:Sydney-SMB-NetBT (Protocol[TCP] or Protocol[UDP]) and (SourcePort[445] or DestinationPort[445] or SourcePort[137-139] or DestinationPort[137-139]) and (DestinationIP[10.20.1.0/24] or SourceIP[10.20.1.0/24])

1. 802:Narrabri-SMB-NetBT (Protocol[TCP] or Protocol[UDP]) and (SourcePort[445] or DestinationPort[445] or SourcePort[137-139] or DestinationPort[137-139]) and (DestinationIP[192.168.6.0/23] or SourceIP[192.168.6.0/23])

1. 803:Sydney-HTTP Protocol[TCP] and (SourcePort[80] or DestinationPort[80]) and (DestinationIP[10.20.1.0/24] or SourceIP[10.20.1.0/24])

1. 804:Narrabri-HTTP Protocol[TCP] and (SourcePort[80] or DestinationPort[80]) and (DestinationIP[192.168.6.0/23] or SourceIP[192.168.6.0/23])

1. 805:Narrabri-Outlook (Protocol[TCP] or Protocol[UDP]) and (SourcePort[56001-56005] or DestinationPort[56001-56005]) and (DestinationIP[192.168.6.0/23] or SourceIP[192.168.6.0/23])

1. 806:Gunnedah-Outlook (Protocol[TCP] or Protocol[UDP]) and (SourcePort[56001-56005] or DestinationPort[56001-56005]) and (DestinationIP[10.20.40.0/24] or SourceIP[10.20.40.0/24])

1. 807:Gunnedah-HTTP Protocol[TCP] and (SourcePort[80] or DestinationPort[80]) and (DestinationIP[10.20.40.0/24] or SourceIP[10.20.40.0/24])

1. 808:Gunnedah-SMB-NetBT (Protocol[TCP] or Protocol[UDP]) and (SourcePort[445] or DestinationPort[445] or SourcePort[137-139] or DestinationPort[137-139]) and (DestinationIP[10.20.40.0/24] or SourceIP[10.20.40.0/24])

1. 1001:HTTP Protocol[TCP] and (SourcePort[80] or DestinationPort[80] or SourcePort[8080] or DestinationPort[8080])

1. 1023:HTTPS Protocol[TCP] and (SourcePort[443] or DestinationPort[443])

1. 1024:FTP (Control) Protocol[TCP] and (DestinationPort[20-21] OR SourcePort[20-21])

1. 1006:IMAP (Protocol[TCP] or Protocol[UDP]) and ( DestinationPort[143] or SourcePort[143] or DestinationPort[220] or SourcePort[220] or DestinationPort[993] or SourcePort[993] )

1. 1008:POP3 Protocol[TCP] and (SourcePort[110] or DestinationPort[110] or SourcePort[995] or DestinationPort[995])

1. 1011:SMTP Protocol[TCP] and (SourcePort[25] or DestinationPort[25])

1. 1007:IRC Protocol[TCP] and (SourcePort[6667] or DestinationPort[6667])

1. 1025:AIM Protocol[TCP] and (SourcePort[5190] or DestinationPort[5190])

1. 1009:RDP Protocol[TCP] and (SourcePort[3389] or DestinationPort[3389])

1. 1014:SSH Protocol[TCP] and (SourcePort[22] or DestinationPort[22])

1. 1016:Telnet Protocol[TCP] and (SourcePort[23] or DestinationPort[23])

1. 1017:VNC Protocol[TCP] and (SourcePort[5800] or DestinationPort[5800] or SourcePort[5900] or DestinationPort[5900])

1. 1003:DHCP Protocol[UDP] and ((SourcePort[68] and DestinationPort[67]) or (SourcePort[67] and DestinationPort[68]) )

1. 1004:DNS (Protocol[TCP] or Protocol[UDP]) and (SourcePort[53] or DestinationPort[53])

1. 1005:Ident Protocol[TCP] and (SourcePort[113] or DestinationPort[113])

1. 1018:ICMP Protocol[ICMP]

1. 1012:SNMP Protocol[TCP] and (SourcePort[161-162] or DestinationPort[161-162])

1. 3008:NetBIOS ((Protocol[TCP] OR Protocol[UDP]) AND (DestinationPort[137-139] OR SourcePort[137-139]))

1. 1021:OtherUDP Protocol[UDP]

1. 1022:OtherTCP Protocol[TCP]

Hello,

how much traffic is going trough the "Sydney-SMB-NetBT" channel?

Well I did a manual file copy (just using Windows explorer, right click drag > copy here). And file copy was doing 1.05MB/sec (it's a 10mbps connection so theoretical max of 1.25MB/sec) but NetFlow basically showed nothing (netflow should indicate around the 10,000kbps mark).

I can't see it being collected in any of the others, I'll test it again later.

The channel looks right to me? UDP+TCP and ports 137,138,139 and 445 should basically cover CIFS and SMB and therefore track and log data.

I just tested it again. Doing a 4GB file copy going between 855KB/sec to 1.05MB/sec or 1.10MB/sec and what I've noticed is that the second I started this copy the "live data" flat-lined at 0. But the Toplists Top Protocols and Top Connections is seemingly accurate, in fact extremely accurate showing 470MB copied on the Sydney-SMB-NetBT channel.

Therefore the system IS working, but using my method of testing/checking using the "live data" graph just wasn't working.

Any ideas as to why this might not be updating? The moment I started this copy it is actually flat-lining on 0. It's almost as if it's unplugged.

okay so I checked back and I have no idea what is happening with the logging now. All day it worked perfectly and then the moment I start this large file transfer test it stops working correctly.

I checked back 2 Hours 45 minutes later, and it looks like the file copy is finished.

Here's the results:

• Toplists works perfectly all data shown is accurate (sizes etc)
• 2 Day view seems to have "flat-lined" since 5PM (2 hours 45 mins ago)
• Live View seems to have changed back to wrong information.

The live view shows that between 6:50PM and 7:35PM around 25kbps (6:50Pm is the oldest time the live view is currently showing), now this is impossible because it's showing in the top lists that it's transferring 800MB for each 15 minute interval.

So if you do the math you can see how it's impossible to transfer 800MB within 15 minutes at only 25kbps.

The top lists are correct, the live view and other graphs are wrong.

Any ideas?

Just tested again, 4GB file copy going 1.14MB/sec but the live view data is showing 25kbps and top lists is showing correct data values. Something is definitely wrong.

Some Information to help understanding the results.

The graphs and the toplists handle the timing Information in the flows a little differently.

The router sends the flow information when the flow is finished (or after the active flow timeout). The flow contains the informtion about size, start and end time.

For toplists the complete flow is reported for the "current" toplist regardless of the timing information. So you see the volume of the file transfer (which is normally a single flow) concentrated in one toplist.

For graphs the flow is evenly distributed over the reported flow time. For this PRTG needs to know the correct active flow timeout value. The graph is delayed for this timeframe since flows with a start date going back the flow timeout could still show up.

For this reason you can see data in the toplists which will only show up later in the live view.

Regardless of how the flow is distributed, the total volume in the tables should always contain all the data transfered (you need to wait the active flow timeout time to see all data). Best dont look at speeds but volumes.

Some devices dont report the correct timing information in the flows which could cause further confusion.

If you have set a wrong active flow timeout you should get todo entries about lost flow data.

You can activate the raw logging in the netflow sensor to see the timing information of the flows and which channel they are accounted to.