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.

Find more posts tagged with

network_monitoring

network_management

Accepted answers

All comments

karltbraun

*bump*

Deltona

*bump*

systemstate

Can we get an answer on this from the SolarWinds staff? If it's a feature that we don't fully understand and aren't taking advantage of, I'd like to know. Otherwise I have to agree with kartbraun in that it's exceptionally annoying.

Thanks,

Systemstate

mavturner

Karl, I'm looking into this for you and will let you know something soon - sorry for the inconvenience.

Mav

tomas.mrkvicka

Hi Karl,

could you please open support ticket for your issue and paste number of ticket to this forum? For us it will be easiest way how to help you.

Thanks.

FormerMember

Tomas, there are others that would like to know the answer to Karl's question as well. Please post the response so we all know the answer to the mystery. Thanks.

smartd

Yes. This is a long standing complaint with Discovery. I want "found" nodes, not "changed" interfaces.
Found should be default. And you should be able to "Ignore" by device type, using the static and dynamic filtering features available in the new "groups" feature.

tomas.mrkvicka

We still don't know about any support ticket for this issue. If there is anybody who can reproduce this issue please feel free to open support ticket. After that we can start investigation directly at customer's side and then inform others in this forum about results.

Please don't forget enter ticket number into this forum in order we and other users know it is under investigation already.

Thanks

karltbraun

I will be opening a ticket on this this afternoon (WED-11-JAN) or tomorrow.

danielleh

Hi karltbraun--

Did you ever open a support ticket? If so, would you please post your ticket # and any progress you've made in the process?

Thanks!
DH

GoldTipu

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.

www.solarwinds.com/.../OrionAdministratorGuide.pdf and start reading on page 42.

karltbraun

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?

GoldTipu

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"

mavturner

Karl,

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,

Mav

FormerMember

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.

smartd

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.

karltbraun

Great idea.

-ktb

FormerMember

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.

karltbraun

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.

smartd

For example:

I have 5227 nodes in my ignore database

I am monitoring 2498 nodes with 4487 interfaces.

neil.broadley

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.

ttrudeau

Bumping this thread. This is my pain every.single.day.

deanmass

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.

routermonkey

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.

mmunford

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...

lkcameron

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.

jouhary

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.

orioncrack

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?