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

Struggling with Automatic Network Discovery filtering

I feel like I'm missing something regarding the filtering options for automatic network discovery. Under "Monitoring Settings" within one of my discoveries I have it set to "Automatically monitor based on my defined monitoring settings". Within "Define Monitoring Settings" I want to make it so that things like removable media, Windows Scheduled Tasks, and some interface descriptions simply don't show up in the results. To this end I've tried numerous different things within the interface settings, where it currently looks like the image below:

However, regardless of these settings (or any others I've tried) I *always* get those interfaces, Compact Disks, Floppy Disks, and Windows Scheduled Tasks. For example:

What am I missing?

Find more posts tagged with

Accepted answers

rschroeder

I ran into a similar situation with Cisco's "Controlled" and "Uncontrolled" interfaces being discovered and automatically set to monitor until I started playing around with the Monitor Filtering Options. I suspected the Interface Description might NOT be what I expected, so I built a filter that tested NOT monitoring the port based on the idea that NPM might be discovering it as an Interface Type, an Interface Name, and Interface Description, or an Interface Alias.

Whatever it was thinking, my shotgun approach stopped these interfaces from automatically being monitored. Here's what the filter looks like:

I haven't used the process of elimination to discover which option is the one that's effective, but you can try each of them one at a time, filtering for something that's showing up in your Monitoring / Discovery to see what these unwanted interfaces are actually being found by the Discovery tool.

Just ensure you're actually searching out something that's present in the interface's name. If not, your filter will not be useful.

Other options to consider (and this may not be appropriate in your environment) include tests by unchecking things that MIGHT be getting those unwanted items discovered:

Mount Points
Network Discs
Other

Be certain you're actually using your Monitor filter to NOT discover some THING, some PART of the discovered item. For example, if you filter out "WAN Miniport" (using my shotgun approach above), do you still get the WAN Miniports automatically added to monitoring? If you actually choose to filter out what's being discovered, it should NOT be monitored, even if you don't have the check's in the boxes by those items. (It's a guess--maybe it'll help you if NPM is not treating your search terms the way you expect, not actually finding them as an Interface Description, but as some other item like an Alias or Name or Type)

All comments

rschroeder

Whatever it was thinking, my shotgun approach stopped these interfaces from automatically being monitored. Here's what the filter looks like:

Just ensure you're actually searching out something that's present in the interface's name. If not, your filter will not be useful.

Other options to consider (and this may not be appropriate in your environment) include tests by unchecking things that MIGHT be getting those unwanted items discovered:

Mount Points
Network Discs
Other

ouberlord

Even after changing it to how you showed, I'm still getting no change and it's still showing those interfaces in the results. For example, here is the criteria I just ran (and as an edit here, I also added "Interface Alias" to this list):

Here is (some of) the results:

I feel like either I continue to misunderstand that the filtering settings are supposed to be doing, or our installation is horribly broken somewhere.

rschroeder

I agree with you; it should not be adding those resources. I recommend opening a support case with Solarwinds to get to the bottom of it.

Well, that or RTFM . . .

jhandberg

I didn't do this exercise for servers, but I did it for Cisco network devices. I found that what Cisco calls the "interface description" is "Interface Alias" in SolarWinds. I found controlled/uncontrolled to be filtered in what Solarwinds is calling "Interface Description". Unrouted as in unrouted vlans were also in :interface description'. Interface Type in SolarWinds is like Digital Signal Level, Serial, or Ethernet. I was trying to identify these variations for both filtering as in this question and macros for the Alert email body. I found that if I could work on an alert action and go through all the available interface fields for a specific node, I could figure out what they were for both alerts and filtering in discovery.

Another thing I did was use Internal Interface Name for an email subject line rather than Interface Name so I could get G0/0/0 rather than GigabitEthernet0/0/0. This helped where there is a space constraint on the subject line, but our people wanted that information without opening the email.

ouberlord

This is pretty spot on. I did find that if I utilize all four fields, I can still use the regular expression method I originally intended.

That said, results always show up regardless of this filter within the discovery results. However, I found that when I go to actually import them they are not selected. This problem as such boiled down more to what I expected out of the UI versus what it actually does than toward any technical problem.

However, it works as I intend now that I know that, so I'm happy!