Network Management

I have the majority of ports on campus switches (5400zl/2910al/2930M/etc...) set with spanning-tree bpdu-protection.    I want alerts to notify me when IMC receives an errant-bpdu trap.   I have all of the campus switches set to trap to IMC.      I can see the traps being received in IMC with Trap Browse.   I can even see errant-bpdu alerts but there is no notifcation that is being sent at this time.    I see the traps in Wireshark captures on the server.   The port 162 is open.   The trap destination is defined.     I'm running E0705P06.  

For some reason in alarm browse it doesn't correlate the ObjectID, to the SNMP ObjectDescription, which being that all of the MIBS would be standard it should be able to interpret properly and do the correlation.

I've created a trap group browsing for the ErrantBPDU trap.    I've created an filter that will use the defined trap group, and then defined an alert for the corresponding trap data.    Traps continue to be received from what appears to be the proper trap, but nothing shows up in alarms.    I've changed the alert level of the trap from warning to minor as well.    When someone plugs in a bpdu broadcaster I want to have the port information available.

Has anyone successfully set up something like this for errant bpdu traps?

Hello,

I guess by seeing alerts but no notifications, you mean the trap is identified by iMC in Trap Browse, but does not generate an alarm. That would make sense, as iMC has a definition for the ErrantBDPU Traps (Trap OID 1.3.6.1.4.1.11.2.14.11.5.1.7.1.0.6.1), but by default does not trigger an alarm for them.

To do so, simply create a new Trap to Alarm rule that matches by Trap Type on the Trap OID 1.3.6.1.4.1.11.2.14.11.5.1.7.1.0.6.1:

It will be Enabled automatically, and trigger an alarm when such a trap is received. Note that the level of the alarm generated is determined by the severity of the trap - for ErrantBPDU that is Warning by default, and could be changed via Trap Definition page.

Also note that "filtering" eg. Filtering Trap page mean that you 'filter out' certain traps, so you don't see them nor get alarms from them. If you have defined a filter for the ErrantBPDU traps, then you should remove it, or you definitely won't get alarms for them.

Hope that helps.

Thanks for clarifying the filtering, I have a filtering group defined for a test network that I'm using to test these alerts and I pushed the filtering activation time into the future in 2021., so it shouldn't currently be active, but I will want to reactivate it later.   So the filtering shouldn't be occurring currently, however perhaps I'm not understanding the definition properly.

I modified the trap definition as you indicated and I did have that definition previously, however I've removed the time validity ranges to eliminate that from being a factor.

I trigger an errant BPDU and I get the following trap.    Now what strikes me as unusual is that it doesn't correlate the oids to names, which I think the trap should normally be able to do.   I've imported the hpconfig mib as well so I don't know why this data isn't populating some oid strings.    In defining the trap it understands the oid, but in the received trap it doesn't so I'm wondering if something is wrong in this correlation.

Hello,

Thanks for all the details. Based on the screenshot, it definitely looks like the Trap is not being recognized properly - which means it's an issue with either the Trap itself sent by the device, or the Trap Definition in iMC.

I did some research and as it turns out - this can be reproduced in the lab as well. It's an issue with the Trap Definition in IMC, using the wrong OID compared to what the devices are sending. Unfortunately though, as it's a pre-defined definition, there is no way to change the definition to work around this issue.

This will need fixing from Engineering. Can you please open a support case to have it resolved?