Dell (r200) IPMI netwerk probleem

[Verwijderd]

Ik heb 4 exact dezelfde Dell R200 servers. Nu wil ik via IPMI de status gaan uitlezen van mijn temp fan's etc etc.

Als ik op Server(S)1 ben ingelogd met SSH, kan ik de andere 3 servers uitlezen, alleen S1 kan ik dan niet uitlezen.
Als ik op S2 ben ingelogd kan ik S1, S3 en S4 uitlezen alleen S2 niet
(en zo ook met de andere servers)

Als ik een ping doe naar mijn IPMI ip adressen krijg ik geen ping reply, maar krijg wel netjes een mac adres terug, behalve van de interface op de server zelf.

vanaf S1: (arp -a)
(192.168.60.31) at <incomplete> on eth1
(192.168.60.32) at 00:1E:C9:FE:76:B1 [ether] on eth1

vanaf S2: (arp -a)
(192.168.60.31) at 00:1E:C9:FE:71:5F [ether] on eth1
(192.168.60.32) at <incomplete> on eth1

Het lijkt er dus op dat dit op de een of andere manier geblokkeerd wordt, maar de grote vraag is, waarom en hoe zou ik het eventueel kunnen oplossen.

Ik heb op mijn S1 server een vmware server draaien, als ik vanuit die vmware-server (S1-VM) een ping/arp request uitstuur krijg ik helaas ook geen reply van S1, andere servers zijn wel goed bereikbaar.

Het lijkt er dus op dat IPMI het niet toestaat om door de lokale server aangesproken te worden.

Omdat ik mijn monitor server virtueel heb draaien is er ook geen mogenlijkheid om voor die server een request te sturen dat niet over het netwerk gaat.

- zijn er meer mensen die mijn verhaal kunnen bevestigen?
- heeft iemand een oplossing voor dit probleem?

Alvast bedankt!

[Foeijonghaai]

Wij hebben ook meerdere Dell-systemen en zien hetzelfde (wij hebben geen R200 maar SC1435, PE1950, PE2950 etc). Ik dacht dat het wel algemeen bekend was, maar ik heb zo geen bronnen bij de hand.

Lokaal moet je 'ipmitool' draaien zonder de hostname-optie. Dan probeert ipmitool het via /dev/ipmi0.

Ik weet niet hoe het bij de R200 zit, maar bij onze machines heeft de IPMI-controller een netwerkkaartje dat meelift op de fysieke aansluitingen van je eerste netwerkkaart (eth0). Dat schijnt de reden te zijn waarom ze niet via netwerk met elkaar kunnen communniceren.

[Kippenijzer]

De standaard IPMI lift 'out-of-band' mee op de bestaande interface. Dit houd in dat het van buitenaf komende verkeer gecontroleerd wordt of het voor de IPMI kant van het systeem bestemd is. Een switch zal in principe nooit bij een ARP request dezelfde poort als waarvan de request kwam als antwoord geven, om broadcast storms te voorkomen e.d. (Als een poort vraag om een MAC adres en de poort zelf is het antwoord dan is er een kip en ei, de switch geeft dat antwoord dus nooit, want door de request impilceert de poort dat hij dat MAC adres niet kent.

Wat je eraan kunt doen? Extra NIC plaatsen die je voor het externe verkeer gebruikt en de IPMI NIC enkel voor IPMI gebruiken.

[TrailBlazer]

De uitleg van Kippenijzer klopt wel ongveer maar het werkt net even wat anders. Een switch zal namelijk nooit reageren op een arp requests omdat dat een onderdeel is van de IP stack en een switch werkt enkel op L2.
Een switch zal L2 broadcasts broadcasten naar alle poorten behalve de poort waarop de broadcast binnenkwam. ARP requesten zijn nu eenmaal broadcasts dus daarom gaat het in dit geval mis. Je zou kunnen kijken of een static arp voor het IPMI ip adres het probleem oplost.

Ja ik weet dat er L3 switches zijn maar dat is even niet van belang in dit geval.

edit.
static arp werkt denk ik ook niet want unknown unicasts worden denk ik ook alleen maar geflood naar alle poorten behalve de inkomende.

[ Voor 11% gewijzigd door TrailBlazer op 22-10-2008 08:49 ]