HP SIM 6.3 receiving traps from Procurve as "generic unregistered"

[flatfour67]

So I know that SIM and Procurve and MIBs have been discussed at length on the forum, but I'm still struggling with how and why this isn't working.

I have (for testing) a 2610-48 (J9088A), that is properly set up to send traps to my SIM server, and to send the traps I want.  It is also correctly identified within SIM as expected.

SIM is not only recently updated to 6.3, but has had the latest (Jan 2011) Procurve MIBs compiled and imported.

However, the bulk of the traps from this switch appear as generic unregistered.

The ones I am interested in are those called hpSwitchStpErrantBpduReceived - which is defined in CONFIG-MIB.mib.  (This is a trap you can enable to be sent when STP detects a loop where there shouldn't be)

"hpSwitchStpErrantBpduReceived TRAP-TYPEENTERPRISE hpSwitchTrapsVARIABLES { hpSwitchStpPort, hpSwitchStpPortErrantBpduCounter, dot1dStpPortState, dot1dStpPortDesignatedBridge, dot1dStpPortDesignatedPort, hpSwitchStpErrantBpduSrcMac, hpSwitchStpErrantBpduDetector }DESCRIPTION "This trap indicates that unexpected (errant) STP BPDU  has been received on a port (e.g. on a port that is connected to non-STP device). This notification trap is controlled by the state of 'hpSwitchStpTrapCntl' object. Implementation of this trap is optional."::= 1"

I've checked the import dependencies of this MIB and renamed the dependent MIBs to match the names used in this one, as mentioned in another post.

But the traps still show as generic unregistered.  The OID appears to be correct if I load that MIB into a MIB browser:

hpSwitchStpErrantBpduReceived, 1.3.6.1.4.1.11.2.14.11.5.1.7.1.0.1, CONFIG-MIB, TRAP-TYPEhpSwitchConfig, 1.3.6.1.4.1.11.2.14.11.5.1.7.1, CONFIG-MIB, OBJECT IDENTIFIER

Seems to match up with the OID shown in the event within SIM:  1.3.6.1.4.1.11.2.14.11.5.1.7.1

I have also verified this trap is being sent correctly by using a freebie trap receiver, and I can see not only the OID but also the variables in there too, such as the switch port numbers and mac addresses.

So I just don't get it - everything seems to be in place but SIM just doesn't associate this trap with the correct definition from the MIB.

Help, anyone?!

Bob

[jim goodman]

Under Options -->Events --> Snmp Trap Settings

Do you see the Procurve Mibs?

[flatfour67]

Hi Jim

Yes I do, although some don't have traps listed but I believe that is normal.

(I've read that some only contain object-identifiers?  I'm new to SNMP!)

Specifically, I do have the trap name 'hpSwitchStpErrantBpduReceived' listed under CONFIG-MIB.mib, which I believe is the trap that I'm generating.

Thanks

Bob

[jim goodman]

I am going to do some digging since this has come up before - I had a customer ask me about this not too long ago as well so I ought to educate myself a bit more on this. I'll post back if I come up with anything.

I trust you followed the Whitepaper for compiling and customizing mibs. Let me also ask you what the mib kit is you installed and for what product.

Thanks

[flatfour67]

Well I was going to tell you it's the MIBs that come with 6.3, plus the pack downloaded from the Procurve support site, listed under the 2610-48 switch.  That's a pack of MIBs they call "mibs_Apr10", but the .mib files within are dated January 2011.

However, as I admit to some major hassles upgrading from 5.3 it seems some other MIBs I'd tried previously are still in there - specifically this CONFIG-MIB.  That has actually come from oidview.com - although it appears to be a HP MIB.

Within the .mib itself it's titled "HP Enterprise Switch Configuration MIB " - seems to be a lot of object-types under the hpconfig branch, but then with this one trap defined right at the very end.

So I think I might have raised another question - why is this trap not present in any of the MIBs that are part of the Procurve support download?!

(And have been digging further - that pack from the Procurve site contains .mibs without hypens in the names, as the default ones do - but the import references within them look to the hypenated names!  So they will be importing the old versions at that point, not the updated ones......  So perhaps my MIB collection is more screwed up than I thought!)

[flatfour67]

Ok whoa, may have found something.

Seems this trap /is/ defined in one of the MIBs from the Procurve pack - hpSwitchConfig.mib.

(Which sounds like a new proper name for config-mib.mib really).

But, while this MIB is present in the list under Options/Events/SNMP Trap Settings, it does /not/ contain any traps - according to SIM anyway.  But I can see the trap defined in the .mib file at the end, in the same place as in the old config-mib.mib.

But it does have the hypenated names listed under imports at the beginning of the file - could that be related?

Specifically HP-ICF-TC and HP-ICF-OID - the 'new' versions do not have the hypens.

I may try making copies of the new ones and removing the hyphens, import all and see what happens.  But then what if these refer to hyphenated mibs too, aaaah this could go on forever!

[jim goodman]

You hit on exactly my question to the team - I know the ones with SIM are SNMPv1 MIBS that SIM understands and can agregate with all of the meaningful info you see in an event. What I don't know is if the Procurve kit is SNMPv1 or standard to the format that SIM requires to put all of the pieces together.

[flatfour67]

I presume you have yet to receive an answer!

As mentioned am no expert in SNMP but learning as I go - certainly mcompile is supposed to compile v2 into the SIM compatible format, this is lifted straight from the PDF that describes SNMP customisation in SIM:

"This paper discusses the tools provided by HP Systems Insight Manager to integrate third-party (non-HP) SNMP v1/v2 MIBs into HP Systems Insight Manager to provide support for processing and displaying traps from other systems."

And I can say that visually the MIBs look the "same", although fully appreciate there may be syntax differences I'm not aware of.

So I would hope that even if they are a later version, mcompile would iron that out and all would be fine.

I'm more concerned now that mcompile is compiling information from the old MIBs with hypenated names when compiling the new MIBs, so it believes it is importing successfully as it finds a file with that name, but it is not aware they are missing information.

Whom did you raise the question with - team SIM or team Procurve?

[flatfour67]

Interesting - from the 'loading order' html file shipped with the procurve MIB pack:

"The first column, "MIB", is the filename of the MIB that you wish to compile into your MIB browser software (the actual MIB name is shown in parentheses)."

Then this is one of the first column entries:

hpAcmxlBase.mib; (HP-BASE-MIB)

So based on that it almost implies the file name doesn't matter, as the real MIB name is detected when compiling.

But - mcompile reads the imports list (which are MIB names?) and interprets that as the file name - here is pasted output from that command:

C:\Program Files\HP\Systems Insight Manager\mibs>mcompile hpacmxlsystem.mib
HP Systems Insight Manager Mib Compiler, Version 5.0.2.1Copyright (c) 2003-2006 Hewlett Packard Corporation
Compiling hpacmxlsystem.mib
Processing import file: SNMPv2-SMI.mib

Processing import file: SNMPv2-TC.mib

Processing import file: SNMPv2-CONF.mib

Processing import file: HP-BASE-MIB.mib

Mib Compilation completed successfully

Now it's clear that this is importing HP-BASE-MIB.mib - when according to the description of file name to MIB name association, it should actually be importing hpAcmxlBase.mib.

Is this down to the Procurve team not naming their files properly or the SIM team who wrote the MIB compiler picking up MIB names as file names?!

Cos something ain't right there.....

[jim goodman]

Generally speaking this is what I know:

SIM is a hardware monitoring tool, up/down/general status when it comes to networking gear. What that means is you have MIBs in SIM for the Procurve line that meet the principle of what SIM is designed to do. Now there are MIB kits like you have that are written to be leveraged by network specific applications designed to monitor bandwidth, through-put for each port etc. giving you a look into the switch performance right down to the ports and protocols.

Saying that SIM is only designed to handle MIBs specific and aggregated from HEX to meaningful output by external files that further process the recieved trap to meaningful information displayed in SIM. SIM's focus is hardware specific therefore the support is not there beyond simple up/down. Your network applications are written to support and handle MIBs that go beyond simple hardware. Which makes sense in the grand scheme of things.

I'll post other things if I find them out, but right now that is the best I have - if you believe there is still a problem you will have to go through the support channel and get a case that can works its way into a formal response.