IPMI v1.5 & v2.0

Hello
We have many old iDrac5 monitored with all their services correctly and without problems (IPMI v1.5). But just one iDrac6 is giving us problems with the same rules that we are using for iDracs5. There is no way to get the services remotely.


What I have done is launch ipmitool via command (IPMI v2.0), I can get the services, but adding the option -I lanplus:

#ipmitool -H myip -U myuser -P mypassw -I lanplus -L operator sdr
Temp | disabled | ns
Temp | disabled | ns
Temp | disabled | ns
Temp | disabled | ns
Ambient Temp | 16 degrees C | okay
CMOS Battery | 0x00 | okay
ROMB Battery | 0x00 | okay
VCORE | 0x00 | okay
VCORE | 0x00 | okay
VTT CPU | 0x00 | okay
1.5V PG | 0x00 | okay
1.8V PG | 0x00 | okay
3.3V PG | 0x00 | okay
5V PG | 0x00 | okay
1.5V PXH PG | 0x00 | okay
5V Riser PG | 0x00 | okay
Backplane PG | 0x00 | okay

My question is, how can I tell checkmk to use IPMIv2.0 so it can show all services via ipmi?. Any idea about it?

Thanks!

Ana

Is on your system also “ipmi-sensors” available as command?
The problem is that the special agent knows no option for the “ipmitool” to switch between “lan” and “lanplus”.
With the “ipmi-sensors” you have the options inside the special agent configuration like “driver-type” and there you can insert “LAN_2_0” what’s something like the lanplus in your example.
The “freeipmi” package is a little bit more flexible with the configuration of the connection.

Hi Andreas,

Indeed the Freeipmi is more flexible and I have been able to get the sensors information with the configuration that you told me but a new problem has appeared, some services are in CRIT:

Those services are OK from console…Don´t know why they are like this.

On the other hand,

Testing this command:

ipmi-sensors -h myip -u myuser -p mypass -l operator -vv -D LAN_2_0

The result of the record ID which refers to this CRIT alarm

image

is:

Record ID: 29
Record Type: Compact Sensor Record (2h)
ID String: 1.05 V PG
Sensor Type: Voltage (2h)
Sensor Number: 43
IPMB Slave Address: 10h
Sensor Owner ID: 20h
Sensor Owner LUN: 0h
Channel Number: 0h
Entity ID: system board (7)
Entity Instance: 1
Entity Instance Type: Physical Entity
Event/Reading Type Code: 3h
Sensor Direction: Unspecified
Assertion Event Enabled: 'State Deasserted’
Assertion Event Enabled: 'State Asserted’
Deassertion Event Enabled: 'NONE’
Share Count: 1
ID String Instance Modifier Type: Numeric
ID String Instance Modifier Offset: 0
Entity Instance Sharing: Increments for reach shared record
Sensor Event: ‘State Deasserted’

Any idea is so much appreciated!!!

Thanks!

Ana

Deasserted sensors can also be ignored i think.
Is this data generated with the IPMI special agent or from the IPMI Linux agent output?
If you use the special agent this can be suppressed with the option “Suppress not available sensors” if i remember it correctly.
Or the discovery rule for IPMI sensors has the option to ignore some sensor states like the “deasserted”.

Hi Andreas,

I created the discovery rule for IPMI sensors and ignored the deasserted states, and that´s fine. But I´ve realized that when monitoring via IPMI, the interfaces are not apperaring. I mean, there are no interface services (if) as before activated IPMI. And this is a problem…

Before monitoring with ipmi:

After activated IPMI, there are no interfaces. In the host properties, just activated the check_MK Agent:

Any idea?

Thanks so much!

Ana

Is it possible that in your system a rule exists that the if/if64 check is ignored if you select to query with agent this host?

I´ve just realized that the interfaces appears in DRAC5, but not in DRAC6…Not sure what the problem is.

A few differences between them…

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact @fayepal if you think this should be re-opened.