6 Replies Latest reply on Sep 24, 2018 10:52 AM by ouberlord

    Struggling with Automatic Network Discovery filtering

    ouberlord

      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:

       

      I've also tried setting the drop down to "does not match regular expression" with a value of "ISATAP|Miniport|Teredo|Lightweight|Async|Software Loopback|Multiplexor|Kernal|sit0|Null|Backplane|Extended", which did not work.  Further within the "Define Monitoring Settings" my volumes and applications settings look like this:

       

      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?

        • Re: Struggling with Automatic Network Discovery filtering
          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)

          1 of 1 people found this helpful
            • Re: Struggling with Automatic Network Discovery filtering
              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.

                • Re: Struggling with Automatic Network Discovery filtering
                  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 . . .

                    • Re: Struggling with Automatic Network Discovery filtering
                      John Handberg

                      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.

                  • Re: Struggling with Automatic Network Discovery filtering
                    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!