Disclaimer, this has turned into a long post / rant... proceed with caution...
This is a general plea to SW and to the community at large for some reason and logic as it relates to NTA.
We've actually owned NTA for a couple years now, and only with the recent changes in NTA 3.9 have we actually been able to use it at all.
But it's still got some pain points that I think really need to be addressed. I doubt I'm alone here.
We have a lot of non-Cisco routers/switches/etc. Many of our devices do not allow setting the NetFlow/sFlow source interface as in Cisco devices. Yes, this isn't rocket surgery, but the vendors don't seem to think it's important enough to warrant adding the feature, so it is what it is. Because of this, for 2 years NTA was pretty much useless to us, since we manage our routers by a loopback IP and they would send sFlow data from the egress interface IP, NTA would summarily and happily throw away all the sFlow data it was receiving. That was very helpful.
NTA 3.9 made big strides with the "Allow matching nodes by another IP Address" feature. Now NTA is smart enough to realize that my router might have 10, or 100 IPs and understand that they all belong to the same device, and that device is a managed node within NPM. Hooray for that. The bigger question is, really, "why should it even matter?" But, more on that later in the post.
The not-so-awesome part? -- edge interfaces.
Let's say I have a data center switch with 500 interfaces on it. I don't really want to make all 500 of those interfaces "managed" in NPM, because if you multiply those 500 interfaces across, oh.. a few dozen switches, suddenly your NPM server is polling 15,000 elements instead of 1,000 or so. Does that mean that I don't care about traffic statistics across the interfaces that aren't managed in NPM? Of course I do! I want to know if Server A is blasting traffic at Server B within my data center, and for what reason. Since both of those servers hang off of edge ports on my DC switch, I don't necessarily want to monitor those interfaces in NPM, but I don't want NTA to throw away the sFlow stats for all those flows either, just because they're coming from "unmanaged interfaces."
Here's an example:
NetFlow Receiver Service [LEELA] is receiving NetFlow data from an unmanaged interface on cs-104-dc.network.local. The NetFlow data will be discarded. Use the "Edit this device" link or Orion node management to manage interface 'GigabitEthernet16/21' and process its NetFlow data.
Multiply that by a few hundred interfaces per switch, and a few dozen switches, and suddenly you start to wonder why you're paying so much for the NTA add-in module when, and I want to emphasize this, many (most? all?) other NetFlow/sFlow/etc. collectors/analyzers out there just accept the data they receive and analyze it / report on it / etc.
Another case -- consider a large network or campus with 700+ edge switches, and let's just say they're all 48 port switches. If I manage my 700 switches, and the important interfaces on them (uplinks, critical links, etc.) I might have around 2,000 or so elements to poll with NPM. Why don't I manage all the edge interfaces in NPM? Well, first of all, I don't care if edge interfaces go up/down, or change speeds, etc. That happens all the time. But I do care, however, if two, or a group of users are blasting traffic at each other (and for what reason). If they are serviced by the same switch, traffic doesn't cross the uplink interfaces and thus isn't reported in the sFlow for that interface. Since I don't want to have 700 switches x 48 ports = 33,600 elements in NPM because I don't have the finances of an oil conglomerate to pay for all the physical servers and SW licensing to actually handle that kind of load, I would still love to be able to see the sFlow reports across my edge interfaces.
I truly don't understand why SW continues to be so draconian with NTA.
It would seem to me that it adds a non-trivial amount of overhead to processing every single *Flow packet that comes in to check:
1. Did this come from a managed node (primary IP?)
2. Did this come from a managed node (secondary / additional IP?)
3. Did this come from a managed interface on a managed node?
There are dozens of NetFlow / sFlow / whateverFlow analyzers out there, some paid, some free. I've not run into a single one other than NTA that throws away packets based on unmanaged nodes, or unmanaged interfaces. They take the data you send to them, analyze it, and report on it. Period.
The draw to NTA is that it integrates into Orion. Great, except when such strict rules are enforced as to make it less useful to you than having a standalone tool that doesn't impose these silly restrictions.
The NTA/NPM integration/correlation could still bring great value, except do it at the presentation layer (logically) rather than the data gathering layer. Let NTA just accept and process the *Flow packets. Get rid of the strict rules about managed nodes, managed interfaces, etc. Without doing all those checks for every *Flow packet, the servers could likely scale to a higher load since they're doing a lot less work for each packet, too! Bonus points for that. It could clean up the code base for NTA, too. Simple is good, remember that from our programming 101 days? Why over-complicate something when it just doesn't need to be? When the data is pulled to be presented in reports, or in Orion, then it could be correlated with NPM nodes. Flows coming to/from NPM managed interfaces? Great, present that information with the relevant interface info, links, etc. gathered by NPM. Flows going between managed devices? Great, enhance the report / display with additional information as a benefit of NPM knowing about those nodes. Flows coming from UNmanaged interfaces or nodes? No biggie, just display the flow data without the enhanced data that would have come from linking nodes/interfaces to managed elements in NPM. Having a node or an interface managed through NPM should be an enhancement to how NTA displays data, not a prerequisite!
This has caused me to question the recurring licensing costs for NTA. If it can't/won't be allowed to stretch its legs and give me useful information in my environment, then what value is it bringing me? I might just have to switch back to one of the free or significantly-less-expensive solutions out there which happily accepts data from any of my sources and gives me lots of useful reports and information.
Am I alone on this? I'd love to hear some others' experiences and how you all feel about these issues. I'd love to see SW do something in the spirit of making things a whole lot better for the customers here.