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

Network Sonar Discovery - Purpose of Interface Discovery

Can someone enlighten me as to the purpose of changed interfaces showing up in the discovery screen?  There doesn't seem to be anyway to take care of changed / newly discovered interfaces other than to ignore them.  If I select them and import, they get ignored because the node is already in the database.  If I have to ignore them every time, why not just automatically add them to the ignore list?  And if we are just going to ignore them, why "discover" them in the first place.  This is creating about 45 minutes of work a week just selecting and ignoring changed and discovered interfaces.


Thanks for any help on this.

47 Replies
Level 8

Same issue still going in 2017! Using a recent version (12.0.1)

This is really a bad indication of how solarwinds handle their customers feedback.. Please explain how the auto-discovery is "designed" to work and what's your work around if it was not planned/designed properly. I simply need to know what to expect.

Don't fret jouhary, you are not alone....

This problem is one that makes me physically ill that people have no concept of what we need. SCOM does it so well, SolarWinds still does not automate object management.

Discovery settings changing after running config wizard?

0 Kudos
Level 8

Has anyone seen some feedback on a resolution for this issue? I'm seeing the same kind of stuff. We're running NPM 12.0.1 (so pretty recent) and the autodiscovery process seems pretty unworkable. I've set up a number of autodiscovery jobs that each discover a different type of device in our environment. I end up each day with a 'scheduled discovery results' table full of a couple of hundred 'changed' nodes (although there have been no changes). I've set the discovery process up to auto add new nodes using a REGEX filter on the Interface names so that only a specific sub-set of interfaces should be getting discovered, but alas, autodiscovery is picking up *ALL* of the interfaces on all of the devices (new or existing) and telling me that there are new interfaces to add. The new interfaces are ones that autodiscovery should have been ignoring because of the filter configuration. None of the autodiscovery seems to be getting automatically imported or updated. The note in the autodiscovery setup "Select this option to choose what to monitor upfront in Define Monitoring Settings. You have less control over what is included or excluded, but your monitored devices are selected in a single wizard. Devices are automatically imported and monitoring is set up according to your settings when you complete the Network Sonar Wizard." seems to be pretty self-explanatory to me, but nothing seems to be happening automatically at all.

I have a job open with support (#1129081) but the guy on the other end doesn't seem all that interested in helping me out. Its been 5 days with no reply since I last asked a question in the ticket.

Really looking for a good explanation of how the autodiscovery process works so I can figure if I'm beating my head against a wall for no good reason or not, and then hopefully a way forward to get the discovery process working in a way that is useful to me.

0 Kudos
Level 8

Ouch...  I've been running SW in my environment for quite some time and the environment keeps growing larger. I had written off Network Sonar many years ago for some earlier versions of the same unwieldy  issues discussed here...  Unfortunately, I need a working discovery process as we have come to find that the "word of mouth" import method also leaves a lot to be desired as new servers, VMs, Volumes and such are not consistently passed to me to be added. This has lead to some embarrassing episodes where we were caught with our SW pants down when critical un-monitored volumes have run out of space unexpectedly. "Why weren't they being monitored?" is the dreaded "next question" and my answer is "But, but.. nobody told me they added new volumes!!". That answer does not go over very well.. 

So, I am now looking at Network Sonar Discovery to save the day. After all, it has been 5 years since I last tried it, right?

Yeah, not so much....   I have just spent two days on and off ticking off extraneous volumes and interfaces to add to the ignore lists so I wont need to do this again on the next discovery. Then I go to import some new "surprise" volumes on existing nodes. However, none of these new volumes import and kick back a vague message "Import Status: not processed".. As I start to look around thwack for this issue, I see this thread about the discovery and ignore-list issues, which basically tell me I've just wasted my time, and will be wasting the same time over and over again after each discovery..

this is not the discovery solution I was looking for...

0 Kudos
Level 8

I'm in the same boat.  Nightly rediscovering the same devices, over and over.  Try to import them, nope, they are already in the db, not going to remove them from the list of discovered node to

This doesn't seem to be a very productive way to have regular discoveries to find and import actual changes to the network.  The work flow, as it is, doesn't seem to make any sense to me.

0 Kudos
Level 7

I am on the front end of a new job that uses this software.

Reading through this thread, I am not optimistic about the comprehension of the support staff.

I am totally new to this product, yet it seems obvious to everyone EXCEPT Solarwinds that we are asking to NOT wade through 're-discovered' things, and we want a way to make a list that allows the unwanted 're-discovered things' from re-appearing on the list.

Level 8

Bumping this thread.  This is my pain

Well, this issue was opened in Dec 11, and we're fast approaching Dec 13, I'm running NPM 10.5, and I still get this exact issue.

Even on devices with "snmp ifmib ifindex persist", we still see occasional changes to interfaces, particularly relating to VMware interfaces. Very frustrating having to ignore these over and over.

I wouldn't mind if I could say to Orion - "go ahead, import these changes you've found, I'm fine with that". But no. When I try that, I get "node already exists, skipped", and I'm dumped back at the discovery screen with all these magically changed interfaces waiting to be imported/ignored.

I wouldn't even mind if I could "select all" on the interfaces to ignore them. But no. I have to tick each one individually, tediously.

0 Kudos
Level 13

For example:

I have 5227 nodes in my ignore database

I am monitoring 2498 nodes with 4487 interfaces.

0 Kudos
Level 12

you need to stop continuously ignoring these as they pop up.  All you are doing is filling the ignore table with more crap that will never purge.

learn how many are normally there for the windows devices and just pass over them.

The problem stems from windows servers coming up from reboot with new interfaces that dont get assigned to the similarly named one that went down.  having it give you new interfaces is a good thing for instances where you add a module to a switch that wasnt full then you can import all the new interfaces.  only devices that seem to be causing issues with this is the windows devices that change the uuid of the interface when it reboots each and every time.

I hadn't thought about that, but that makes sense.  Of course the DB is going to be filling up with obsolete interfaces.

But I'm afraid your solution is not practical.  If I understand you, you're telling me I need to memorize those node/interfaces that are repeating and just don't process them in the Scheduled Discover results.  If I did that, but the end of a week, I'd have a growing list of over 100 "discovered" changed interfaces, and this would grow exponentially:

  • 100's of Windows servers in the environment, with dozens rebooted weekly.
  • Interfaces on HP (Colubris) MSMs change daily - sometimes a dozen interfaces change in a week, and I have around 100 MSMs in the environment.

SolarWinds staff: this is going to get critical if I start running out of database room. 

0 Kudos
Level 13


The discover is seeing these devices as new, as it's actually rediscovering the same subnet/IP Range/etc.  The reason these are marked as new is because to the discovery they are new.  The discovery isn't checking against the database for nodes during the discovery process.  It only checks against the database when the import is attempted.  At that point it will state the node already exists in the database and move on.  The only way is to keep these nodes from being detected or rediscovered as new each time at the moment is to add then into the ignore list.  This will prevent the discovery from finding them again.  Please note, the discovery isn't intuitive when it finds devices so it things all devices are when it runs as they are responding to it. and start reading on page 42.

0 Kudos

 Please note, the discovery isn't intuitive when it finds devices so it things all devices are when it runs as they are responding to it.

The discovery isn't checking against the database for nodes during the discovery process.  It only checks against the database when the import is attempted.  

This is what needs to change!  The discovery needs to be more intuitive and compare each discovered node against the database on nodename and ip address. I would like to see an option to compare using the node short name or FQDN.

On the front-end add a step to be able to select discovery filter criteria (vendor types, machine types, interface types, volume types, etc.) plus a checkbox to drop duplicates.  On the back-end, after all nodes have been discovered, match against the database on nodename and ip address and drop the matches from the discovered nodes then filter the remaining nodes by the additional user discovery criteria that was provided on the front-end before presenting the final import result.  The final result should be able to be saved for later import. 

I also would like to see the ability to run concurrent discoveries across multiple polling engines.

That's the way I'd like to see discovery work.


Oh, I almost forgot, I would like to see discovery resolve a node discovered with multiple ip addresses to the Loopback address (if one is discovered).  This would be another discovery filter option (checkbox) on the front-end.

A feature I saw someone post using perl was to only add interfaces with more than one MAC address in the bridge table...  Giving you the uplink interfaces.  Great option.  Exactly what we want to track.  Another option would be to add any interface with a description.  Usually important interfaces.

Great idea.


0 Kudos

I'm sure that's mostly true, but after you try to import these newly discovered interfaces, and it checks the database and says "nope, already in there', it still keeps the newly discovered interfaces as waiting to be processed.  As far as I know, at this point, you have two options:  (1) keep them in the waiting-to-be-processed state in perpetuity, or (2) select them all and ignore them.


So far SolarWinds has asked me to run a number of scripts and provide them with the result.  That's fair when trying to resolve a bug that's unique to my system.  And to be fair - I have had time in the past week or so to do this.  


But my question was: *what was the design - how does SW expect this process to run*? 


This has been pointed out a number of times on this discussion.  I've yet to hear anyone try to address this.  Here's my experience with this process:


(1) New switches and servers are discovered during a nightly scan.  

(2) The nodes are checked off in the newly -discovered page, and imported into the database.  Then I configure the attributes so they show up in the right managed nodes containers.

(3) I also list the resources on these and leave checked only the interfaces I want to manage.  (a) For switches, these are only interfaces that have uplinks/downlinks to other switches, routers, or firewalls, or critical nodes;  (b) For servers, we use Microsoft SCOM for most server management and alerting, so I uncheck all interfaces.

(4) During the next nights run, for all of the nodes which I imported the previous day, all interfaces which I unchecked (don't wish to monitor) are then *REDISCOVERED* as if they were new.  I can't processes these by just checking the node - I will just get a message indicating the node is already in the database during the import process and the interfaces will still remain waiting to be processed individually.  So I have to go through and check each "newly discovered" interface individually and then set them to be ignored.  

Imagine doing this on a 144 port distribution switch with 1 uplink and 6 downstream switches.

For servers it is even worse.  All physical and logical interfaces on the server are "rediscovered" and must be checked and ignored the following day.  To make maters worse: If the server is rebooted and the interface index changes on the interface - they are all rediscovered again and I have to repeat this process... every time the server is rebooted.


This *can't* be the way this was designed.  Surely SW engineers are involved in this kind of maintenance process and have a way around this, or this issue would be resolved by now.  Can someone from SW please get Josh or some other engineer to discuss this?

0 Kudos

Orion will re-discover interfaces basses on the interface index . If you have added Interfaces in ignore list and the interface Index changed on the NODE  it will rediscover as NEW interface . 

You need to make your devices to keep "Interface index persistent" 

0 Kudos


I appreciate you sticking with this. This was certainly not intentionally designed to be such a pain for our users. It's clear we could have done a better job of getting feedback when the re-discovery process was built. To that end, if you would like to jump on a Go To Meeting with myself and some of our developers, we would like to go through this with you step by step so we can work on a fix that makes your life easier (at least where this bit is concerned). Yes, we can re-produce this internally and make it work the way we think it should work, but the goal is to make it work for customers and your feedback is certainly appreciated. I will email you off of thwack to arrange this.

Regarding a better filtering of interfaces and nodes on discovery. That is a well know request (filter by description matching, interface type, etc. ). We won't be able to get this fixed in the release we are actively working on, but it's a high priority to get added soon.

Thank you,


0 Kudos

Is there any time frame for a change to discovery which will address these problems? I've spent about an hour during each of the past two weeks just clicking individual interfaces and then ignoring them.  Just to reiterate:

  • A lot of the problems stem from changes to interfaces with non-persistent interface indexes
    • This seems, in my environment, to be relevant to mostly servers, where indexes change after a reboot (and for Windows boxes, that's at least weekly); it also applies to some Colubris (Procurve) wireless management modules (WSMs/MSMs) where the indexes appear to change dynamically with the connection/disconnection of clients.
  • If, after a node is discovered, we could indicate (say, through a check-box) that we don't care about interface changes (but we do care about other changes SNMP might discover).
    • I wouldn't mind doing this on a per-node basis at time of initial discovery / integration

Something Solarwinds developers may not get with respect to the way EMS/NMS systems work in large network environments: 

  • Activities are broken into the following categories (may be different groups)
    • Project / Implementation
      • This would include intitial discovery over a new network segment, etc.
      • The costs associated with this would be considered part of a large capital project
    • Operations / Maintenance
      • This is just plain overhead.  Management is going to be interested in keeping these costs (including head count) very low; it's part of the selling point of a NMS/EMS that capital investment in something like Solarwinds will reduce ongoing overhead costs (doing more with less people)
      • Of course any system needs ongoing maintenance.  But having to devote 10-15 minutes every day to needless interface cleanup of servers reduces the perceived effectiveness of the investment in the product.
      • If this perceived needless overhead is associated with, say, servers, its going to reduce the ability to justify using this product for anything other than simple network up/down monitoring.  That puts you in a class with What's Up Gold.

So if setting the "ignore" check box during initial discovery is available, it becomes an implementation activity, not a maintenance/overhead activity.


Can someone please let me know when a resolution for this is planned?  I'm spending 4-6 hours *per week* just telling NPM to ignore the same interfaces over and over.  I finally convinced my server crew to turn on SNMP on servers, and now I'm paying the penalty for it.

0 Kudos