I find a need to send a copy of Netflow data, which my routers & L3 switches send to Orion, to other applications at other IP addresses.
Can Solarwinds Orion / NTA / NPM do this?
If so, where is it configured, how is it accomplished?
To answer your question - No Orion NTA cannot be configured to forward Netflow packets to another receiver.
The correct configuration is that proposed using a dedicated Netflow forwarder/replicator solution. We have deployed this for customers where devices only supported single export destinations, where multiple were required. Your choice as to the impact of either of these methods; reconfigure devices to send to multiple Netflow receivers or to a single Netflow forwarder.
Let us know which direction you go and how you get on, it would be useful for others to learn
Solarwinds is just a receiver of UDP traffic on the port your devices are sending the data to.
Why don't you just have the devices send the Flows directly to your other applications? thats if they can read them
Are your apps you're looking to send to able to accept Netflow or were you thinking of moving raw data?
I think my Catalyst have a limit on how many destinations that you can send Netflow data to. I have mine configured for at least 2 destinations but the Nexus NX-OS limits to only one destination.
Here is a guide to an application that should do what you want
How-to configure a free NetFlow forwarder or NetFlow duplicator - Brad Reese
You can use an F5 to forward to a pool as well, that way you can have whatever pool members you want listening, with one destination in the config of your devices
Curious as to how often you would use a tool like this. Is this just for testing or do you plan on leaving in place for an extended period of time? Do you see this as being a value add feature for NTA?
I could do that. But modifying 800 routers to send duplicate copies of the Netflow to a second source seems a waste of bandwidth and resources.
I'd prefer to take the information already sent to NPM's pollers and forward a copy to the third-party tool that wants to analyze that data.
But thanks for the thought--it was my first one, too.
How often? All it takes is once, and the labor & duplicated network traffic & resources are wasted.
The project involves a new Cisco security analysis tool; if we buy into it, the duplicated Netflow traffic would be a permanent solution. It doesn't matter whether it's built to send to multiple destinations from every router, or forwarded from Orion to the Cisco tool.
Imagine Cisco ISE, which uses discovered device profiles to built custom ACL's and push them out on a per-port basis to every switch port. Nightmare, right? Discovering the actual udp/tcp ports & destinations required to make every device on the network work normally, then deny all traffic that doesn't comply with those rules.
Cisco's latest tool learns the communications required for a successful network experience of every device, then interfaces with ISE and custom-builds the appropriate ACL for every port--AND automatically applies it to the right port.
The tool does this via information gleaned from Netflow data. My hope is to avoid having to manually configure all my L3 interfaces to point at a second (or future third, fourth, etc.) Netflow destination. If Orion can forward Netflow data just as it does syslog entries (I send all my devices' syslog to Orion, Orion forwards it all to Splunk), then I save labor & network bandwidth.
So what's the verdict? Can Orion forward Netflow data, similar to the way it does syslog, to a third party analysis tool?
Well, we DO have multiple F5's . . . But none are in the Netflow / Solarwinds solution. Therefore they're out of this particular picture, since I want to simplify the network forwarding of Netflow traffic to a third-party solution.
Configuring VIPs and RIPs and pools and Health Checks and iRules on the one side, and then duplicating existing Netflow configurations on the routers on the other side . . .
That ends up being more work than I can justify--or want.
But thanks for the idea. It hadn't occurred to me, but that's probably because Netflow isn't already going to / through F5's. If my NPM pollers were all behind F5's, you might be onto something. But we're not there, yet. SW isn't mission-critical, and won't be until I can tear down the silo walls and get the SA's, DBA's, Telephony, Apps, & Storage folks using Orion. A goal. More likely a pipe dream.
I would use something like plixer: Free NetFlow Forwarder or NetFlow Duplicator - Plixer.com
Basically, it receives the UDP flow frames (NetFlow, IPFIX, sFlow, NetStream, jFlow, cflowd, etc.), changes the destination IP address while preserving the original source IP address and forwards the datagrams onto one or more destinations. It is a very useful utility for testing multiple collectors. It also helps customers get around the problem when the switch or router doesn’t forward NetFlow to more than one destination. The Flow Replicator is awesome for addressing this issue.
Now I wish NTA had more support for nbar and flexible netflow: Cisco NetFlow Replicator Released - Plixer.com
I'm not sure but I thought there was talk about this for NTA?
No matter what solution you choose, you're going to have to put something in front of Solarwinds, for the optimum solution at least(F5, Plixer, Linux)...if you have it at the same layer, you'd have to change your nodes anyway to add the new receiver, and then you'd be duplicating traffic to each application that wanted it...1, 2, x times depending on how many apps wanted it.
True... no matter what you're going to have to update some things... it's not an easy fix.
ecklerwr1 - NTA does support the collection of NBAR & Flexible Netflow. Is there something missing from the collection of those flow technologies you'd like us to add? Specific fields maybe?
I probably am a version behind... that's probably why I'm not familiar with this yet.
We use something called Samplicator. It's open source and runs on Linux.
Configuration is quite simple and we currently have three instances set up that handle ~400 routers each. Basically each device sends NetFlow data (it can be Syslog or SNMP Traps as well) to Samplicator, which in turn sends it to NTA and other sources as well (I don't believe the number is limited).
Check out your Cisco security tool. If it is the one I'm thinking of it already includes a flow replicator.
rschroeder is this supposed to be a cisco NAC? You should only have to span the interface that the flows come back to Orion on. Have all flows be on their own vlan and then only span that VLAN to destination 2, provided they're in the same location? Just an idea. That's if you need live flows.
To summarize what everyone is getting into here, either a: you have enough bandwidth that duplicating flow traffic is no big deal if done intelligently, or b: you don't have enough bandwidth that duplicating flow traffic is a big deal and therefore a bad idea. It's ultimately down to your control of the network to identify whether you can make it happen.
This would be true even if you were handling netflows via things other than solarwinds/had another monitoring solution.
Yes, this is part of a Cisco NAC solution. I hadn't thought of doing a SPAN on the ports going to Orion. I come from the days when Cisco advised that monitor sessions were OK for temporary use, but not to be left in place long-term. The bigger and newer hardware isn't nearly so limiting, though.
Please say more about this. I'm not getting the hint.
Yeah, if you can control whether you span or not then just span it locally and call it done
I should advise you separately to be extremely cautious with a NAC, they can break things much easier than secure things properly. Especially if they're relying on flows if they aren't also inspecting the sources of the traffic.
Truly, I've seen ISE shut down flows. But on the other hand, we're getting control of flows & devices now, where we had no idea of many of them prior to ISE.
The challenges I've seen with its implementation:
Several folks have recommended Samplicator / Plixer. Thanks for the input.
Step one of a NAC is: don't rely on MACs for security, because it isn't a good way to rely on security at all. You're never going to control every device/control which vendors are being used and new stuff changes constantly. Only exception to device/vendor is usually in high security gov't/military, not much elsewhere.
You're better off setting up VLAN segmentation and also basing your policies on subnets instead, because site a is going to use subnets abcd because that's what'll be defined. You're also heading into YOU NEED SIEM land, which Jfrazier or ecklerwr1 can probably tell you all about (plus the humor of that SIEM 100% requires it's own team).
Also, remember that if you're using real time change notification with NCM (which you should be NAC or not), the NAC is going to have your solarwinds servers checking configs rapidly/commonly, so you'll have to be cautious with server resources and what triggers you put on real time change notification.
Whenever possible it's always smarter to set up proper ACL's on the switches and routers for the long term than it is to hope that an auto-ACL from the NAC is going to fix an access issue. There are lots of simple things here, such as limitations of # of MAC's on a single port with a reasonable timeout period.
TLDR: do not play with a NAC at all unless you at least 50-80% understand what your network hardware is already capable of. Do not rely on the NAC for what your hardware is already built to do.
Examples: time of day ACL's on the switches/routers (don't do it in the NAC, because a NAC can and will fail).
I set up Forescout (NAC) on my current job by hand and if you don't know what you're doing you're going to break 100 times as much stuff as you'll provide any layer of perceived security (which won't likely be real).
yeah NTA enabled NBAR2 and will even warn you constantly now. Like "HEY FIX YOUR STUFF FOR NBAR2" (on every device capable of it that's receiving flows). Difficulty: remember to actually tell your devices to export flows in netflowV9 or later, obviously
Has anyone actually used Plixer Flow Replicator. If so, does it support forwarding flows to a fqdn instead of an IP? We are in the process of implementing HA using Virtual Hostnames.
Read the earlier comments in this thread and then reach out to those Thwack members who recommended Plixer. Let me know if you get it, and how you like it, please?
Also, search Thwack for "Plixer". You'll come up with the other resources that may be able to answer more of your questions through personal experience.
I ran into this same problem when we also bought into RiverBed. Our solution was to send the flows to RiverBed and then have the RB appliances forward to Orion. SW should consider same options.
