Hey ,

In OpenNMS I do the following:

1. Create two minions per site.

   1. minion-location-autodiscovery

      1. This minion is responsible for discovering and polling a dynamic inventory of everything that is actually at the site. This reflects the real state of the network.

         1. I am able to get a list of nodes that are actually present--and I’m able to disable alerting on only those devices if I want to.

      2. The nodes discovered here are automatically sent to a CMDB where I can control their metadata external to OpenNMS.

   2. minion-location-core

      1. This minion is responsible for polling devices we want monitored and alerts for.

      2. There’s a fringe benefit where on the nodes page I can choose the location I want to view--and exclude all of those autodiscovery nodes so its easier to see the list of nodes principally concerned.

      3. The requisitions that this minion is responsible for polling are automated via scripts that consult a CMDB.

So--I’m not manually provisioning anything.

I need to be able to autodiscover my network while not alarming on 4,000 nodes I may or may not care about.

I am pretty green/new to this, and frankly network monitoring in general. Maybe this is a bad approach.

Do you think this is a bad approach? How might you differ?

Matt

Just curious, If one didn’t want an IP interface managed, why would one manually provision it in the first place? I'm trying to not be critical, but I do wonder if I’m reading this correctly.

As an aside, when I look at this, I really wonder why we have more than two actions on the IP Interface policy: Managed and Unmanaged. The others should be left to be adjusted by the SNMP interface policy.

Your impression is a reasonable one, just not how it works now.

A little history might be useful… The policies that filter “managed-ness” were implemented in response to devices that create either a bunch of superfluous interfaces, or transient interfaces. IIRC the feature was essentially implemented to solve the issue of, “well obviously we want to manage things we put in the requisition, but we don’t care to manage the 14,000 virtual interfaces created on this massive router.” Another big target of this was the 169.* addresses created for multicast.

In hindsight of course it should have occurred to us it might be useful to use them to modify defined interfaces as well, but I think because of where the feature came from no one thought to make it work that way at the time.

You’re awesome. Thanks for the reply.

This card--and my thread on the forums--are good to be closed. I think it’s right to view this as more of a feature request than a bug, given how the interface policies function.

Thanks again,

Matt

The category count displayed on the requisition are the manually defined categories included in the requisition. Policy applies categories aren’t included in that count as they are added to the database after the requisition file has been processed.