Nagios Support Forum

If you wish to have 1000 different sources of netflow data, then yes it would require 1k ports at this time. It is absolutely a viable feature request and very potential upgrade to change this, however it is not in the works at the moment.

Edit: I just spoke with the devs, this is absolutely possible, but as previously stated is not presently enabled. If you would like to submit a feature request on tracker.nagios.com so that you can follow it, and then post a link back here, I will also create an internal request for it and link the two to move things along faster.

Did this get submitted as a feature request? We are facing the same problem. We have over 600 network devices and it would be too time consuming to add each one individually as well as tracking unique ports to listen on.

Thanks,
Greg

Yes it has been submitted, at this point in time I do not believe it has been changed as of yet. You could certainly use some iptables prerouting rules to filter which IP something is coming from, and alter the incoming port internally to the NNA server. This is definitely not the cleanest way to handle it, and it can be a bit tricky, but I do have working notes for it if you are interested.

Is there an update on this? Has this feature been implemented yet?

You can just setup a single source (port) and put anything in the IP address field. It is not necessary to setup a new source/port for every device.

Then, you can send all of your netfow data to the same source. The only downfall to this is that you won't have a logical grouping by router/switch, but you can use views to split the data up.

Many organization break up their sources by region or department and have a handful of sources for their entire infrastructure.

Hi,

We are experimenting with NNA as well and are also disappointed at this way of configuring switches.

Putting everything in one source is the only suggested workaround I find viable, but then you don't know anymore which switch saw which traffic. That is not acceptable either. And no, you can't reconstruct this using views. Certain subnets might be associated with certain switches in a simple network, but in a network with hundreds of active VLANs spread over hundreds of switches in a many-to-many relationship that just isn't going to cut it. (which reminds me of another thing missing in this product: VLAN awereness)

I really like the integration with Nagios, don't get me wrong there (click server, see what traffic to and from that server was detected in sFlow data, really handy and simple for the server guys). But you guys really need to have a look at competing sFlow products and look at all the stuff they can get out of the same sFlow data! (I want to list some that really blew me away, but don't know if you guys have an anti-advertising policy)

Is there a feature request being worked on to allow sending all sFlow data from all switches to one port? Is there a feature request for VLAN awereness? This is really necessary for us to really start using NNA with all our switches and network equipment.

Michiel

There is no feature request for VLANs, however you can right now send all netflow traffic to one port. The problem is that if you send 10 routers to 1 source in network analyzer there is no way to know which of those 10 routers actually sent the data. Now I'm by no means a netflow guru and don't know everything about netflow but I am not sure how you'd be able to determine the source of the flow without capturing where it came from in nfcapd, which is what we use to collect netflow data.

Hi,

Sflow sends the Agent IP. That should be uniquely configured or equal to the switch management IP.

Netflow probably has something similar.

Looking at the various versions of netflow (And keeping in mind that v5 and v9 are popular) it looks like those fields can contain the send IP. Whether they will form all sources depends on the sender, but yes it should be possible from my understanding. Also not a netflow expert, mind you.

I can put this in as a feature request if you would like.

Hi tmcdonald,

That would be great!