cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

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

Due to our VRF design and SFLOW limitations on the Cisco Nexus 9000 switches, I need to send Sflow datagrams to NTA from a different source address than the managment address NPM uses to poll the switch. NTA sees the traffic, but lists the source as "unknown" since the IP address is different. Any ideas?

Tags (3)
0 Kudos
18 Replies
Level 9

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

facebook_icon.jpglinkedin.pngblogger.pngtwitter-icon.jpg 

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?

0 Kudos

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?

It sounds like you might need to have a little conference call between your management team, your security group, your network analysts, and TAC.  The router's OOB management port is truly out of band, designed to be plugged into an OOB or ILO network that gives you the ability to control the router when all other avenues are compromised or have failed.

0 Kudos

I understand the oob piece for this interface, so how do we get around NPM and NTA seeing the IP of the netflow interface as a whole new router? The IP shows up in the Other IPs section of the node, but NTA still reports traffic from an interface other than the management interface as an unknown device.

0 Kudos

pastedImage_0.png

If this doesn't work, open a support case with SW, or with Cisco, or change the IP address that SW uses to monitor the node.

You'll probably find things work more smoothly when the reporting source address of the node is also the IP address that Solarwinds uses to manage the node.

0 Kudos

That might take a Cisco TAC case or Solarwinds Support case to answer accurately.  I see a few different responses to that question:

  • Maybe SW cannot do what you want--manage a node with one IP address and receive network management information from the same node on a different interface/address, while still appearing to be the same node.  In that case, you might need to live with two nodes using the same name and different IP addresses.  And I'm not certain SW supports that.
  • Maybe you can change the IP address NPM uses to monitor the node, so it uses the same IP address/interface for remote access into the node, and node-based management traffic it sends to Solarwinds.
  • I suspect the recommendation will be to reconfigure either of two items:
    • Change the IP address NPM uses to manage the node, so it uses the same IP address that the node uses to send info to NPM.
    • Change the IP address/interface the node uses to send info to NPM so it's the same as the IP address NPM uses to manage/monitor the node.
0 Kudos

Our plan is to use Gigamon, tapped or inline or even try raw port mirroring then convert it to Netflow.  I am just gathering ideas for best implementation.  Or start another conversation.

0 Kudos

Admittedly I mostly skimmed the above and may have missed if someone else has suggested it, but you may want to check this setting in your NTA settings:

Enable flow monitoring from unmanaged interfaces - SolarWinds Worldwide, LLC. Help and Support

Make sure the checkbox is checked and NPM should be able to build the relationship for you.

0 Kudos

Yes this should do the trick according to the NTA documentation, but I have this issue with ASR9K's and I have tried this NTA option but it does absolutely nothing.  This is not a Cisco issue.  It is absolutely best security practice to allow management protocols only on out of band interfaces. 

0 Kudos

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

That's exactly what I ended up doing too. Created a different Management VRF than the one on the box, assigned a port to it, IP address, gateway, and then the necessary flow commands with the VRF appended.

0 Kudos

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!
0 Kudos
Level 11

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

0 Kudos

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.

0 Kudos

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!