Idea Details

SNMP polling configuration improvement

Last activity 11-18-2019 08:55 AM
christianelgass's profile image
11-18-2015 03:39 AM

## What is the use case of the new feature?


We would like to avoid the huge amount of unnecessary polling requests with all our SNMP profiles from Performance Center, which would then reduce the network traffic and the confusion of our device administrators about the massive amount of error messages about failed SNMP requests in the device’s log.



## Describe the new feature in detail


The operators of Performance Center (IM 2.0) should have more control about how Performance Center reacts in case of polling problems. In our environment devices will rarely get a new SNMP profile assigned, so PC shouldn’t test out all existing SNMP profiles just because it couldn’t poll the device for two polling cycles. Instead it should stay with the assigned SNMP profile and keep trying to poll with this profile only.

We are aware that other users may like this automatism of trying out all profiles until the device can be successfully polled with one of them again. Therefor there should be a configurable setting that allows administrators/ operators to define if SNMP profiles can be automatically assigned after the specific number of failed polls or only manually.





## Describe how you envision this new feature being implemented.


We need a switch for



ON – allow Performance Center to look for the new/ correct SNMP profile after X failed poll attempts (X = number of failed SNMP requests -> should be configurable).



OFF – DON’T allow Performance Center to automatically change SNMP profiles. SNMP profiles can only be changed manually.





## What business problem will be solved by adding this new feature?


In our environment changes on devices are committed with soft-reboots causing the SNMP agent to stop responding for a few minutes.

The problem is, that after two failed SNMP requests of normal polling, Performance Center will try to resolve the polling problem by trying out all available SNMP profiles against the device, which stopped responding to polls. With many SNMP profiles and some SNMP retries per request and that for every SNMP profile, there are a lot of SNMP requests against the devices. And all these SNMP requests testing which SNMP profile matches are rejected, noted in the device’s log and alarming the administrators about a potential attack. Beside unnecessary load on the network and the devices, this causes stress for the administrators, too.


11-09-2018 07:15 AM

Well I am pretty sure there's a use case for all three scenarios. What speaks against implementing it on three levels, leaving the customer in control when he wants to use it globally or maybe just on a device level?

07-28-2017 03:37 PM

Would making it an Advanced Feature configured against the Discovery Profiles make life easier?


Use that to tell it which profiles would be used in such a scenario?

07-28-2017 03:31 PM

If we were to provide a a switch to control whether CAPM would attempt to contact a device on other SNMP Profiles after X missed polls or not, how should this switch be scoped?


Global - apply to all devices in the system

IP Domain - apply to all devices in an IP domain (might be useful in multi-tenant environments)

Device - granular control, but more difficult to apply in bulk


Other suggestions?

12-07-2015 05:10 PM

Great idea!

12-07-2015 05:03 AM

I agree with christianelgass this is a much appreciated functionality.