Receiving Sflow/Netflow data from a different source IP than SNMP/management IP

Do you have the option to tell NPM and NTA that the Nexus 9K switches' IP address is a different one that you originally managed them with?  Is it that simple--just change the IP address that NPM uses to manage them, to match the address they're using to send NetFlow data to NPM and NTA?

I don't have that option due to security policy. SNMP has to be polled in an in-band management VRF. But it appears that the Sflow traffic won't route from that VRF to the collector in a separate VRF even though there is inter-VRF routing to support it. So, our policy will allow me to send the flow data from the same VRF as the collector, and that works except for the fact that Solarwinds doesn't realize that the interface in the collector VRF is already managed.

Well, then you're in a pickle.  Perhaps others will know how to accomplish this.

How about we set the problem on its ear?

1. Define the limitations of Orion and ACI
2. Craft a proposal that accommodates them and accomplishes the monitoring you need based on your products' capabilities and limitations
3. Use the above to show where the security policy breaks your monitoring solution (Monitoring is a basic part of a secure network!)
4. Submit a proposal to your Security department to exempt your monitoring system and your network hardware from the security policy

ACI and NTA and NPM aren't the issue; it's the security policy that is the root cause of the problem.

Fair enough. I'll do that. Was hoping there was a technical solution, but policy change/exception may work too. Thanks!

may be you can add both IP's.. Not sure you can give a try

greg.grimes I know this is a very late response but one of our customers experienced a similar issue yesterday whereby the sFlow was being sent via a different IP but they wanted it on the management IP.

The solution was actually very simple. in the sFlow config you need to add source {IP_Address} to the end of the sflow collector-ip {ip} vrf {vrf}.

As an example the line would be sflow collector-ip 10.0.0.1 vrf default source 10.44.55.66.

Dax Attwood

Prosperon - UK SolarWinds Partners

Installation | Consultancy | Training | Licenses

While this is some good advice, there are some platforms that won't allow SFlow/Netflow over the management VRF.

I need to resolve the same issue. Policy and ACLs will not allow SNMP over the data plane just the out of band management, but still require the sending of netflow data to a collector.

Any other ideas?

No "useful/positive" ideas.  It seems you may be stuck with:

• Creating a new Node in NPM/NCM/NTA based on the IP address of the interface from which you want to send Netflow data
• Work with the vendor to learn a new way to NAT / mask the actual source address so it looks like it's coming from the management address you want
• Change the address you're managing the device from so it's using the IP address that is sending Netflow data
• (I hate this one) Place a NAT device between the Netflow IP address interface and the internal network.  Ugh--I can't believe I even wrote that!  Don't use it!

I created a separate VRF and assigned the VLAN we use as the source to this VRF

In the destination under the solarwinds exporter link it to the VRF

     destination A.B.C.D vrf NetFlow

Use the VLAN in this VRF as the source

Yeah. Oddly, I've just run into this too with the Cisco ASR routers. They have a management port that is completely out of band from the rest of the device. SNMP, syslog and ssh work, but that mgmt interface will NOTpass netflow data. So, I have to send the Netflow to a collector from one of the outside interfaces. Solarwinds doesn't like this as the management interface that it recognizes and the Netflow source interface are not the same. As someone said earlier, it should be easy as it's just a different interface in the same box, but I can't find a way to accomplish this. Any more ideas?