Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Netflow dropping managed IP packets

I'm getting the following error from Netflow:

NetFlow Receiver Service [NETMN_SRV] is receiving a NetFlow data stream from an unmanaged device (192.168.254.9). The NetFlow data stream from 192.168.254.9 will be discarded. Please use the Orion System Manager to add this IP Address in order to process this NetFlow data stream.

This is a managed router in Orion so I don't know why this is occuring.

Has anyone else had this problem?

Brad Swihart
Sr. Systems Engineer
Trigon EPC

Find more posts tagged with

Accepted answers

All comments

savell

Brad,

Is this IP address an interface on the device, or the management address (i.e. loopback).
Check that you hace configured the device to send the Netflow data from the management address (e.g. ip flow-export source Loopback0).

Sav.

Trigon

Thanks Sav, I'll give it a try and let you know the results.

Brad Swihart
Sr. Systems Engineer
Trigon EPC

billh

I get this too on Cisco routers that I only want netflow from on the serial interfaces. I don't want netflow packets from the ethernet interface.

I also get this on a device that has an interface that's disabled, like my Packeteer appliances. I guess there is no way to 'unmanage' just an interface even though it's unchecked in the list of resources.

Trigon

Hey Sav,

Can you give me some more details on using the loopback? I can't find anything on the Solarwinds site about it.

Here is my issue:

Router 1 was defined in Orion System Manager using the fa0/0 (172.16.1.1). It discovers all the interfaces of the router, including S0/0 (192.168.1.1) which is the interface I want to analyze. I setup Router 1 S0/0 for flow-export (version 5) to my NMS on port 9090. Netflow works fine on the router and I can see the stats. However, Netflow Traffic Analyzer (NTA) receives the Netflow packets but discards them as a non-managed packet.

So, I deleted Router 1 in Orion System Manager and then added it back using the S0/0 ip (192.168.1.1) to discover. System Manager found the router and all the interfaces (just like when I used the fa0/0 ip). After a while, NTA started accepting the packets and I can view the details.

I'm not sure if this is how Netflow Analyzer should work but I can't find very much technical detail on the SolarWinds site.

Your loopback solution may help me as well as others so if you can elaborate a bit more it would be great. I want to add more routers to NTA and need a best practice for my ops team to follow.

Brad Swihart
Sr. Systems Engineer
Trigon EPC

billh

Brad, that is the same issue I have...I had to follow the same steps as you to get the netflow packets and to remedy the warnings in Orion.

savell

Gidday Brad,

Sorry, I assumed that you were already using loopback addresses in you configs.
Netflow receiver must be able to correlate the managed device in Orion with the incoming Netflow data.
To do this, it uses the IP address that was used to manage the device.
As you found, if the addresses do not match, then you have a collection issue.
You could have equally used the command ip flow-export source fa0/0 rather than re-adding the device into Orion using the serial interface.

We prefer using loopback addresses.
Consider these to be virtual interfaces.
With a loopback address on a device, you can ensure that all packets originating from the router use the loopback address.

A number of commands are useful to do this once you start using loopbacks:
ip flow-export source
ip tacacs source-interface
ip tftp source-interface
ntp server xx.xx.xx.xx source
logging source-interface
snmp-server trap-source

Loopbacks then make it very easy to (for example) construct filters to protect management interfaces, map loopback addresses to router names, and to enable telnet to loopback addresses (routers usually have multiple external paths and many interfaces).

Sav.