Onderwerp: IPMI Supermicro

Goeiemiddag,

Ik heb een server staan (voorlopig lokaal in het LAN, moet binnenkort in het datacenter geplaatst worden) waarvan ik de IPMI niet volledig in orde krijg.
Het gaat om een Supermicro PDSMi+ moederbord met een AOC-IPMI20-E IPMI kaartje. Bios van het moederbord is geupdate naar de laatste versie.

Ik heb een floppy gemaakt met de firmware om de IPMI kaart te flashen. Hij kan daar perfect mee booten en de flash lukt ook zonder problemen. Dan run ik ipnmac.exe aan de dos prompt en stel ik een lokaal ip en het mac adres in.
Als mac adres neem ik wat de handleiding voor schrijft: het mac adres van nic 1.

Als ik op die moment IPMIView gebruik werkt alles perfect. Kan inloggen, krijg de console te zien, de sensors werken, ect.
Ik kan de server uitschakelen, en terug inschakelen.

Maar het probleem is dan dat als het normale OS boot (Scientific Linux 6, ervoor bij CentOS 5.5 hetzelfde probleem) de IPMI niet meer werkt. Device is offline.
Het vreemde is dat als ik de server uitschakel de IPMI ook niet meer opnieuw werkt.
Booten met de floppy en opnieuw flashen is de enige manier om er opnieuw leven in te krijgen.

Kortom IPMI werkt volledig tot het OS voor de eerste keer geboot is, en daarna niet meer.

De Supermicro tools onder linux zeggen no BMC found.

Ik heb al vanalles geprobeerd. Het mac van nic 2, 00:00:... als mac, hetzelfde ip als lan 1, verschillende ip's,...
Ben ten einde raad.

Wellicht zie ik gewoon iets over het hoofd. Iemand die meer weet?

mvg

Staat je console redirection goed in de bios? Denk dat het dit kan zijn dat voor problemen zorgt.

Staat ingesteld zoals de handleiding het zegt. Ben nu niet in de buurt van de server dus kan het niet meteen checken.

Maar dient dat niet alleen om de console te gebruiken via ipmi? Kan dat er voor zorgen dat alles werkt en na het booten en uitschakelen van het os niet meer?

Misschien dat je hier iets nuttig tussen vind.
https://www.ahead-it.eu/knowledgeman...rch.php?q=IPMI

Als je op centos de ipmi tools installeert kan je vanuit linux de ipmi configureren en dan zou het gewoon moeten werken... Was althans het geval bij een iets oudere supermicro over here.

ipmitools had ik al eens geprobeerd. Die vindt ook geen bmc.

Het is me ook al opgevallen dat als ik in de bios iets aanpas, dat de ipmi dan ook weer werkt tot het OS geboot wordt.
En bij het booten van het OS is dat totdat eth0 geactiveerd wordt.

Nu heb ik op een ander forum gelezen dat dat kan komen door een slechte e1000e driver. Details weet ik niet. Supermicro biedt zelf wel een recente e1000e driver aan maar nog geen tijd gehad om die eens te installeren.

Je ip moet sowieso niet hetzelfde zijn als het ip wat je in je OS gebruikt. Ook moet je soms even met de hand de ipmi modules onder linux laden voordat je ipmitool ook daadwerkelijk de bmc zien.
Dat laatste lost alleen je echte probleem niet op. Het enige is dat je dan wat handiger je ipmi kan configureren.
Als je ipmitool het doet, kun je misschien even naar de arp instellingen kijken. Doe dit met "ipmitool lan print". Dan zie je al je lan settings.
Bij mij staat er bij een soortgelijk kaartje dit:
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Disabled
En deze werkt goed. Misschien staat "arp responses" op disabled oid.
ook kun je met ipmitool het bmc kaartje resetten. Ben wel benieuwd of ie daarna ook weer gaat werken.

Ik heb eerst de e1000e driver geupdate. No change.

Dan "modprobe ipmi_devintf" geprobeerd en 'ipmitool lan print' geeft dan:

Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5 PASSWORD
: User : MD2 MD5 PASSWORD
: Operator : MD2 MD5 PASSWORD
: Admin : MD2 MD5 PASSWORD
: OEM : MD2 MD5 PASSWORD
IP Address Source : Static Address
IP Address : 192.168.0.106
Subnet Mask : 255.255.0.0
MAC Address : 00:30:48:97:24:38
SNMP Community String : public
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Enabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP : 192.168.0.254
Default Gateway MAC : 00:0d:b9:03:48:cc
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : Xaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM

Die gegevens zijn juist. Maar het probleem is daarmee niet opgelost. Gewoon effe de stroom uittrekken is voldoende. En dan kan ik wel connecteren, terwijl de server uit staat, en kan ik hem via IPMI aanzetten en de cosole volgen tot het punt dat het netwerk onder linux opgestart wordt...

Zoekend kwam ik het volgende tegen:
http://linux.derkeiler.com/Mailing-L.../msg06429.html
http://bugs.centos.org/view.php?id=3477

http://linux.derkeiler.com/Mailing-L.../msg06935.html

Due to rather bad experiences I'm always alarmed about IPMI problems (actually
so far not with supermicro, but with other vendors). So I contacted
supermicro and immediately got an answer they have a new LAP EEPROM to fix
this problem.

So the problem with supermicro is solved, lets see what the other vendor, I
also contacted, says.

Al contact gehad met supermicro?

Neen maar ik ga ze meteen mailen.
Tnx!

Heb al antwoord van Supermicro.
Het is een EOL product dus SL/CentOS/RHEL 6 ondersteunen ze niet en is ook niet getest.
De e1000e moet ik upgraden naar de 1.3.10a wat ik gisteren al gedaan had.
En bijgevoegd ook een beta firmware voor het IPMI kaartje. Te flashen onder Windows dus ik ga er vanavond nog een andere schijf moeten aanhangen met een Windows op.

Niet echt een super oplossing, maar je kunt overwegen de nic waar je ipmi op zit, alleen voor ipmi te gebruiken. En dus verder niet onder linux. Ik weet niet precies hoe je voor elkaar zou kunnen krijgen dat je de andere wel kunt gebruiken, aangezien die waarschijnlijk dezelfde driver gebruikt. Misschien op basis hardware/pci adres. Je kunt dan een extra netwerkkaartje plaatsen. Ik zie alleen dat het bord niet zo heel veel sloten heeft. Waarschijnlijk gaat het wel goed als je zorgt dat je OS er niets mee doet.
Als je 'm sowieso gaat flashen onder windows, ben ik benieuwd of (voor het flashen) ipmi wel blijft werken. Ik heb overigens wel eens van deze problemen gelezen mbt freebsd, maar dat is volgens mij ook al lang geleden.

Dat is eigenlijk geen slecht idee. Maar dan is er een 2de link nodig en eventueel een extra non-e1000e netwerkkaartje en dat heeft de klant er niet voor over.

Anyhow. Net geflashed met de beta firmware maar maakt niks verschil.
Dus nu weet ik effe niet meer wat er mee te doen. Heb nog 2 dagen tijd en dan vertrekt hij naar het datacenter...

Bekend probleem. Wij hebben hetzelfde moederbord met dezelfde IPMI module. Dit komt door de e1000 driver die in de nieuwere versies van CentOS zit. De hardwarematige CRC checking die wordt ingeschakeld helpt op de een of andere manier de IPMI pakketjes om zeep.

Simpele fix, voeg de volgende regel helemaal onderaan toe in "/etc/modprobe.conf":

options e1000e CrcStripping=0

Oorspronkelijk geplaatst door bassjuh

Bekend probleem. Wij hebben hetzelfde moederbord met dezelfde IPMI module. Dit komt door de e1000 driver die in de nieuwere versies van CentOS zit. De hardwarematige CRC checking die wordt ingeschakeld helpt op de een of andere manier de IPMI pakketjes om zeep.

Simpele fix, voeg de volgende regel helemaal onderaan toe in "/etc/modprobe.conf":

Wij hadden ook altijd een hoop problemen met de ipmi van supermicro op een gedeelde poort, ook met dat moederbord. Dus ben benieuwd of dit geholpen heeft.

Wij zijn ondertussen overgestapt op impi kaarten met eigen netwerk interface en hebben sindsdien eigenlijk nooit meer ipmi problemen