cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

NPM Discovery Interface Filter for WAN Miniport

NPM Discovery Interface Filter for WAN Miniport

When you reboot a 2008 Server the WAN Miniport interfaces get recreated and therefore Discovery picks them up as new interfaces again.  As with a regular patching cycle servers often require reboots so it would be nice to be able to filter out the WAN Miniport drivers at a discovery level.

2012-08-27_WAN_Miniport.png

28 Comments
Level 7

Hi, I am new to this product, but I am noticing the same issue. I have not been able to find a solution to this problem. There has been talk of some sort of update/fix that may or may not be rolled out at some point... correct me if I am wrong here, but the in the screen shot above, it looks like the sonar is "finding" these WAN Miniports as a new device, when you select the WAN miniports and tell the system to ignore... all is good until you reboot the server. Then sonar will scan the network and see the hardware as a newly found item again... like the ignore list gets purged after some time. (I assume by design.) So, that’s my understanding of this… I was wondering what would be the result if you disable the "WAN Miniport (monitoring)" on the poller server hardware? In my network we are not using the WAN miniports so we have no need to monitor them, if I disable the WAN miniports from the server hardware to stop the system from even being able to communicate…. Has anyone ever tried this? What was the result?

I am more having an issue of how to ignore all of those interfaces in the first place. When I have 300 windows servers, going through and manually checking each interface is not very appealing.

Level 7

yeah me too, everyday thousands of servers reboot and every time the NPM 'finds' them as new interfaces, I have not found a good solution for this problem yet, but I am still looking for something that will work. I disabled the IPv6 on the monitoring server thinking that it would make a difference, but there was no change. the only other thing I was going to try but have not had a chance to complete was to setup a GPO to disable all WAN Mini ports on the servers. In my environment we have no need for the wan mini ports…

Level 11

I would love to have a filter list of interfaces to be ignored when adding a new device or scanning an existing one.  The Null0 interface on Cisco devices has always been the one that has bothered us.  Since we have started monitoring more servers in our environment this is becoming a nuisance in the node lists since they all will appear as a green dot with a gray status indicator.

Level 9

this would save a LOT of time, please make it happen.

Level 7

An SWQL filter for results would be great.  It's way more than just WAN Miniport - I'd love to be able to filter like %Loopback%, %RAS%, %ISATAP% %Tunneling% %Scheduler% %Filter% interfaces where Vendor='Windows'

Going through these daily is painful.  Would also like to filter removable volumes in the same results.

Level 16

Its so time consuming that I stopped using the discovery.

But knowing Solarwinds, they will have something better soon...

Hi folks,

we are working on this feature and one of the improvements we would like to add are VLANs per interface. We would need you to download our small diagnostics utility - http://thwack.solarwinds.com/servlet/JiveServlet/downloadBody/170583-102-1-7323/VLANsInventory.zip-  and run it on your environment so we can understand how much time the discovery process takes on your side.

Output of the test is a simple text file which you may send to my email address: michal.hrncirik at solarwinds.com

thanks for your help!

Michal

Level 12

Hi Michal,

For us its not the discovery time that takes additional time but more having the server flag up new interfaces that its discovered post a reboot.  Normally we would need to go through and select each WAN Miniport and add it to the ignore list.  Typically there is at least 6 per server on a reboot.

I'm also with brookslaw on a changeable filter(s) would be very useful for other devices, possibly like filter rules (top down) with a default rule of show in discovery.

Rule # - SWQL - Action

Rule 1 - Vendor=Windows and InterfaceName like %MINIPort% - Ignore

Rule 2 - Vendor=Windows and InterfaceName like %Intel% - Discover

Rule 3 - Vendor=Cisco and InterfaceName = Null0 - Ignore

etc

What do you think?

Hi Peter,

your condition with these three rules above is something that our new interface discovery mechanism should handle.

The VLAN stuff is not directly related to WAN miniports but it's something that useful for the other users - for example Rule: import all interfaces in VLAN 100 - 104. Unfortunately VLAN discovery itself takes a lot of time and we would like to keep our discovery process fast as much as possible so that's the reason why I would like to get a data from real environments.