iMC 7.0 E202 : unable to restore automaticaly traps ?

[Alain WINKEL]

Hello,

At work, I have currently iMC 7.0 E0202.

When I try to restore automaticaly a trap definition, unable to find it. Il found just all other enterprise's traps.

Is there a bug with this version of iMC ?

Thanks. Regards.

Alain.

[LindsayHill]

Where are you looking? You should be able to go to Trap Management-> Trap Definition, choose a trap, click "Modify", and then select "Restore Trap"

Can you post a screenshot of what you're seeing?

[Alain WINKEL]

Hi,

The screenshots :

My license :

Test with trap "device denied snmp access", for "auto" restore of trap himself. Same problem with all other traps :

[Alain WINKEL]

Unable to "auto" restore the traps himself.

With iMC 5.2 that was possible, but not yet with 7.0. Idem with actual patch 7.0 E0202P03...

Test made also at home with fresh install (without entering my enterprise's license), same problem.

Thanks.

Alain.

[LindsayHill]

Normally the "Restore Trap" option is used because you want one trap to close another - e.g. you want "Link Up" to close a "Link Down" incident.

What's the goal here? What are you trying to achieve? Do you want the most recent trap to automatically restore older versions of the same trap? Or do you want to suppress a specific trap completely?

I suspect (but don't know for sure) that the developers have decided that it doesn't make sense to have a trap close itself. There might be a use case they haven't thought about.

You might have to log a support case about this to get confirmation.

[Alain WINKEL]

Hi,

Normally alarms are acknowledged manually. But you have to log into an account with administrative rights into iMC to do this. And into the IT infrastructure team there are only 2 people who are working for network and security, with this right on iMC. It's just a matter of security ...

We receive mails for each alarm. So alarms like as "cold start", topology changes, or "config management event" did instead of staying active until I log in to the iMC, to perform it manually (not a very interesting task no ?).

Alarms "link down" are deleted by the alarm "link state up" (which also kills itself).

In our organization we just want to avoid repetitive administrative connections. And it was a legitimate demand of others in the team.

iMC should work without that must be permanently connected. Emails are used to it for alarms. And we have a monitoring screen for iMC network supervision (with read access).

Could you tell me how to open a call at HP about this problem ?

Thanks for your reply.

Alain

[Neelixx]

Hi Alain.  For the trap restoration, you have to define a trap that is received by IMC as a "restoring trap".  This means, IMC must receive the trap.

In your example, you are talking about traps that, I do not believe, have restoring traps.  They are only single event traps.  For example, "Device Denied SNMP Access".  To my knowledge, there is not a trap that says "Device Allowed SNMP Access".  It only sends a trap when it's denied.

The same goes for the cold start.  A trap is received that a cold start happened.... but then what?  The device does not send another trap saying "Cold Start Completed".  It's just a single trap event.

In those instances, I think you have two options:

1).  Alarm, and force technicians to recover/acknowledge it, so you are aware that the device rebooted, or denied access, etc.

2).  Don't alarm.  You can still keep the event, but not alarm or notify on it.

If there are traps that have recovering traps.... let's say, LinkDown, then find the trap that shows LinkUp and use that as a recovery trap.  When defining recovery traps, you usually will have to identify parameters to look at, since you don't want a LinkUp trap for DeviceA to recover DeviceB.

The way I do it, is I wait for the recovering trap to be received, so I know specifically what trap is being sent.  Then, define THAT trap that was received as the recovering trap.

[Alain WINKEL]

Hi all,

I just opened a call to HP about my problem. I will keep you informed as soon as possible. Thanks again.

[LindsayHill]

---

@Alain WINKEL wrote:

Hi all,

I just opened a call to HP about my problem. I will keep you informed as soon as possible. Thanks again.

---

So...do you want IMC to represent current network status, or not? Sure, you've sent an email, but how do you know if anything was done about it? For someone looking at the IMC screen, how will they know that the problems have been fixed?

It sounds like what you really need is for IMC to create events in a proper trouble ticketing system (not email). Then when the incident is resolved in that system, it should close the alarm in IMC (using eAPI).

Or...if you don't want IMC to show specific alarms, but you DO want it to trigger an email, then what you could do is lower the severity of those alarms to Info. Then they won't affect device status, but you can still configure Email escalation for Info-level alarms.

[Alain WINKEL]

Hello,

So I opened a ticket with HP through my employer. And indeed after checking it turns out that rather serves missed with this update that eliminates a feature that was used before. The problem is in the hands of their developer. A patch would normally be offered.

Thanks.