Properly stopping unneccessary "down interface" messages in SMARTS;

Hi,

I work for a company using SMARTS for all of its proactive network management functions. We are using snmp to manage *almost* all of our devices, with just a few generic traps, running globally:

My issue is a high-level one, and I have provided two low-level instances of issues we are currently having with the current implementation.

The high level:  We need to ignore messages in SMARTS; those that don’t apply to what we want to proactively manage. I personally don’t have administrative rights to our SMARTS servers; but I am able to guide the team who does administer SMARTS; to move us forward. 

We have some ways of stopping traps we do not want to receive for certain device interfaces ,etc.. The easiest of course, is just shutting down an unwanted interface that is down/down. The other is adding a descriptor (such as NOT_MANAGED) to ignore those interfaces from being monitored, with a script on the backend of SMARTS, that looks for the descriptor, and then ignores it.  A third, and as of yet, unsuccessful method is trying a “no snmp trap link-status” on the individual interfaces that are giving us trouble, and not doing a global snmp trap for link status. That however, has proved ineffective in stopping smarts from detecting interface downs.

Example Instance 1:

I have run into some cisco devices that we are trying to remedy that have ”Virtual-Template" and "Virtual-Access" down interfaces, only visible within smarts (and I suppose SNMP) .  Now the device contains other Virtual-TokenRing, and Virtual-PPP interfaces; but nowhere within the config or show ip interfaces brief is there a specific virtual-template and virtual-access interface.  We have tried using the methods above (shutting down interface, trying to add a descriptor), however the interesting thing with a virtual-template interface is that it cannot be shutdown; therefore we cannot stop getting interface down messages sent from trap. The virtual-access interface cannot be configured at all; as it works hand in hand with the virtual-template interface.

Example Instance 2:

Some devices with subinterfaces don’t allow descriptors on the sub interfaces. We have some cisco voice gateways we manage, that have multiple subinterfaces. These interfaces cannot be shutdown, and will not allow any configuration on the subinterface, which stops us from being able to use a description to ignore the problem interfaces.

The situation obviously may require more information for someone to understand fully; which I am happy to provide on this forum,

Thanks

S