ProLiant Servers (ML,DL,SL)
1748169 Members
4425 Online
108758 Solutions
New Discussion

Re: Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

 
GoranTornqvist
Occasional Advisor

Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

Hi,
We´ve received traps from a few DL380-server with the trapoid .1.3.6.1.4.1.232.0.18012.
Example:
\'.1.3.6.1.2.1.1.5.0 (unknown):dl-ki-05.net.local
.1.3.6.1.4.1.232.11.2.11.1.0 (unknown):0
.1.3.6.1.4.1.232.18.2.3.1.1.5.3 (unknown):2
.1.3.6.1.4.1.232.18.2.3.1.1.10.3 (unknown):1
.1.3.6.1.4.1.232.2.2.4.17.0 (unknown):CPQ0762
.1.3.6.1.4.1.232.18.2.3.1.1.14.3 (unknown):4
.1.3.6.1.4.1.232.1.2.13.1.1.5.11.0 (unknown):Intel Corporation Unknown device 115e
.1.3.6.1.4.1.232.18.2.3.1.1.32.3 (unknown):d50868-04
.1.3.6.1.2.1.4.20.1.1.0.0.0.0 (unknown):0.0.0.0
.1.3.6.1.4.1.232.18.2.4.1.1.6.3 (unknown):N/A\'

I cannot find a MIB to download that contains these notifications.
Only found this link:
http://www.snmplink.org/cgi-bin/nd/m/Ent/H/Hewlett Packard (HP)/[ALL] - HP Insight Management/Compaq/cpqnic.mib

Can anyone point me to the correct MIB to handle these kinds of traps?

Thanks...

Regards
Goran
4 REPLIES 4
Matti_Kurkela
Honored Contributor

Re: Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

Here you can find a full kit of HP MIBs, including the cpqnic.mib you're looking for.

http://h18013.www1.hp.com/products/servers/management/hpsim/mibkit.html

The kit is nominally for HP SIM, but as the MIB file format is standard, you can use them with other software too.

Your trap is apparently "cpqNic3ConnectivityLost", which is included in MIB kit versions 8.00 and newer.

MK
MK
IanAtkinson
Occasional Visitor

Re: Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

Hi,

 

I'm in the process of writing a trap listener to monitor our HP servers via SNMP and this thread cropped up...

 

I'm not sure why but there seem to be extra bits on the OIDs that are sent out from the servers compared to the values in the MIBs. In my case sometimes they seem to have .0.2 added on and sometimes just .2 added on.

 

In the original post above they seem to have a .3 added on, e.g. the OID

 

.1.3.6.1.4.1.232.18.2.3.1.1.32.3 (unknown):d50868-04

 

Seems like it should be just 

 

1.3.6.1.4.1.232.18.2.3.1.1.32

 

Which according to http://www.oidview.com/mibs/232/CPQNIC-MIB.html is  cpqNicIfPhysAdapterPartNumber, if you add the .3 back on the end there's no mention of it.

 

I thought that I'd written my parser incorrectly but if I capture the traps in Wireshark the values that come out are the same and I've triple checked the code to make sure it's right.

 

As an example of some of the OIDs my program has received, for event 3040:

 

1.3.6.1.4.1.232.3.2.2.1.1.20.2: Slot 0

1.3.6.1.4.1.232.3.2.2.1.1.2.2: 33

 

Again the .2 on the end seems superfluous, 1.3.6.1.4.1.232.3.2.2.1.1.20 is cpqDaCntlrHwLocation and so on.

 

At the moment I've got my program knocking .2 or .0.2 off the end to see if it matches the known OIDs but that seems like a bit of a hack, it would be good to know why the traps don't match the ones in the MIBs properly if anyone can help?

 

Thanks,

 

Ian

Matti_Kurkela
Honored Contributor

Re: Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

> .1.3.6.1.4.1.232.18.2.3.1.1.32.3 (unknown):d50868-04

 

This would be "cpqNicIfPhysAdapterPartNumber.3" if using labels.

 

The extra .3 suffix at the end is because this entry is part of th cpqNicIfPhysAdapterTable: it means the system can have multiple NICs, with each one having its own part number field. In this case,this would be the third NIC in this table. All the other cpqNicIfPhysAdapter*.3 OIDs would refer to the same physical NIC, and any other suffixes would refer to other NICs.

 

> Again the .2 on the end seems superfluous, 1.3.6.1.4.1.232.3.2.2.1.1.20 is cpqDaCntlrHwLocation and so on.

 

Not at all: it simply means it's talking about the SmartArray controller #2 on the system.

Without the extra index, only one SmartArray controller could be monitored, and that would be just silly.

 

You can recognize these if you look at the parent and grandparent of the MIB name you're examining:

for example, for 1.3.6.1.4.1.232.3.2.2.1.1.20:

- the parent is 1.3.6.1.4.1.232.3.2.2.1.1 = cpqDaCntrlEntry

- the grandparent is  1.3.6.1.4.1.232.3.2.2.1 = cpqDaCntrlTable

 

The "somethingTable" and "somethingEntry" labels will be your clue that the child entries will be table-style entries, possibly containing multiple instances of the same data item.

 

Please see:

http://www.webnms.com/snmp/help/snmpapi/snmpv3/table_handling/snmptables_basics.html

 

If you're writing an OID parser from scratch, in my opinion that's a bad case of reinventing the wheel. Even if NET-SNMP or any other freely available SNMP library is not suitable for your project, you might take a look at their source code

MK
IanAtkinson
Occasional Visitor

Re: Unknown trap 1.3.6.1.4.1.232.0.18012 - trouble finding correct MIB

Hi Matti,

 

That makes sense now thank you, I haven't worked with SNMP before so I wasn't aware of that syntax.

 

All I have written really is a trap listener that parses the traps, I was just adding a bit of extra functionality to resolve the OIDs in the trap but rather than having a complicated MIB compiler in the program I just have a simple CSV of top level OIDs and values, obviously in this case that isn't going to be quite enough if I need to refer to things higher up the tree.

 

I have the info I need to sort it out now I know what it's doing though!

 

Thanks,

 

Ian