Supermicro IPMI und VPN

Steggi

Enthusiast
Thread Starter
Mitglied seit
31.12.2010
Beiträge
3.483
Mahlzeit allerseits,

hat einer von euch bereits Erfahrungen mit IPMI über VPN?

Folgendes Problem: Ich versuche mich grade auf das IPMI meines Supermicro X9DRi-F aufzuschalten. Das ganze geht über VPN über eine normale DSL Leitung. Bis auf das IPMI ist jede andere Maschine (übrigens auch das RSA meiner IBM Server) erreichbar, aber das IPMI des SM Boards gibt noch nicht mal ne Antwort auf nen Ping.

Versuch ich das gleiche über VNC von einem Server der im selben Rack Subnetz ist, wie Laptop und IPMI, klappt es Problemlos.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie versuchst du denn draufzukommen?

Ich kann alle meine IMPI Kisten (6 Stück) via IP und VPN ansprechen.
 
Ganz normal über die IP im Browser --> Zeitüberschreitung
Ping --> Zeitüberschreitung

Ein Trace geht bei der ersten Runde anhand der Pingzeit anscheinend bis zum Gateway, endet dann aber auch in ner Zeitüberschreitung.
IPMI und Laptop wurden bereits einmal neu gestartet und neu ins VPN eingelogt hab ich mich auch schon einige male.

Im IPMI sind nur die IP und Subnetzmaske hinterlegt, aber auch mit hinzugefügtem Gateway (das ja eigentlich nicht benötigt wird, da ja IPMI und Läppi im selben Netz sind) tut sich da leider nichts :(
 
Gateway brauchste ja nur, wenn du routen hast, ist ja nicht der Fall.

Pingen kann ich IPMI im übrigen auch ohne Probleme. Wie ist das VPN gelöst? (ich nutze Windows Server als Kopf)
 
Ein Linux-Server im Netzwerk? Dann per SOCKS-Proxy über SSH drauf zugreifen.
 
Als Gateway dient ein W2K8 R2 auf dem ich im Moment bis auf PPTP runter gegangen bin, was aber auch nichts brachte. Weder Ping noch HTTP werden von irgendwelchen Firewalls geblockt und andere IPs (die sogar Physikalisch im selben Server stecken) sind problemlos erreichbar -.-

Ein Linux-Server im Netzwerk?

An sich sogar mehrere, aber leider nicht in diesem Teil des Netzes, und die sind im Moment alle nicht erreichbar, da ich hier ne größere Systemumstellung mache.

Dann per SOCKS-Proxy über SSH drauf zugreifen.

Ist ja noch nicht mal nötig. Komme von hier aus ja noch auf andere Server (unter anderem auch auf das Gateway), von denen ich das IPMI aufrufen kann. Das scheint also irgendwo am Gateway zu hängen oder der Trafic wird nicht richtig weitergeleitet...
 
Zuletzt bearbeitet:
Hat der VPN Teilnehmer evtl eine andere Route die er für die IP nutzen kann?

Grundlegend ist Aufbau gleich mit meinem. Und ich kann in meinem Netz wirklich jeden Teilnehmer erreichen.
 
Hat der VPN Teilnehmer evtl eine andere Route die er für die IP nutzen kann?

Nein, aber es gibt noch eine zweite Leitung hinter der noch ein anderes Gateway hängt, welches aber im Moment offline ist.
Sobald ich hier mit der ganzen ESXi und vCenter Patcherei durch bin und die VMs wieder laufen werd ich mich mal über das zweite Gateway einwählen und schauen ob das was bringt und das erste auch mal neu starten

---------- Post added at 20:43 ---------- Previous post was at 17:09 ----------

Es scheint so, als hab ich den Fehler gefunden, aber der Grund ist mehr als nur Merkwürdig...

Sobald ich das IPMI über eine VM (z.B über das VPN-Gateway) aufrufe die auf dem X9DRi-F läuft, bekomme ich keine Verbindung. Von allen anderen physikalischen Maschinen sowie den VMs auf anderen Hosts klappt es.
Schiebe ich jetzt das Gateway auf den anderen ESXi Host, dann ist auch die Verbindung wieder da und die Pings kommen an. Schieb ich die VM wieder auf den Server mit dem SM Board, dann ist die Verbindung wieder weg und über die Konsole des ESXi schlägt der Ping ebenfalls fehl.

Da sich sowohl das IPMI als auch die NIC des ESXi im selben Netz und am selben Switch im selben VLAN hängen, gehe ich mal davon aus, dass es ein Problem des Boards ist.

Währe also klasse, wenn ein anderer SM Board Besitzer das mal bei seinem Board testen könnte. Vor allem die Rückmeldung von TCM würde mich interessieren, da er ja nahezu das gleiche Board hat wie ich (bis auf die zusätzlichen SAS Ports)
 
Jetzt wo du es sagst, fällt mir da was ein.
In dieser Richtung habe ich auch schon Beobachtungen gemacht.

Bei meinem H8SGL gibt es 2 OnboardNICs von Intel, dazu gibt es noch einen IPMI Port, der, so glaube ich, über einen BMC irgendwas-chip realisiert wird.

Jetzt wird es aber interessant. Dieser Chip ist nutzt nicht nur seinen eigenen IPMI LAN Port, sondern auch die anderen Ports. (RMII und RGMII)
Das bedeutet, egal welche RJ45 Port du mit dem Netz verbindest, du hast immer eine Verbindung zum IPMI. Evlt hilft dir das irgendwie weiter. Ich habe mich darum nicht weiter gekümmert.
 
Die Kiste auf die du per IPMI willst ist aber nicht zufällig die selbe die auch Gateway ist?
 
Ich hab nämlich ein ähnliches Problem:
Mein IPFire System (auch ein SM Board) hat auch IPMI.

Die IPMI Schnittstelle ist mit der internen Schnittstelle zusammen auf "grün", also der internen LAN Schnittstelle.
Vom Netzwerk aus komm ich auch problemlos drauf, wenn ich per OpenVPN von außen zugreif (OpenVPN Server läuft mit aufm IPFire) komm ich per IPMI nicht drauf.

Ich hab den Verdacht dass das daran liegt dass auf dem shared LAN Port selbst kein Switching statt findet und mein Switch nicht auf dem Quellport wieder raus geht.

Als Lösungsansatz könnte ich mir vorstellen IPMI auf ein extra VLAN zu legen und dort entsprechend zu routen aber das hab ich noch nicht probiert.
 
Die IPMI Schnittstelle ist mit der internen Schnittstelle zusammen auf "grün", also der internen LAN Schnittstelle.

Hab ich das richtig verstanden, dass bei dir die normale NIC mit dem IPMI in einer Schnittstelle stecken, ähnlich wie bei den normalen vPro Boards?
Bei mir sind die NICs ja getrennt, also das IPMI hat ne eigene LAN Buchse.

Werd mal schauen, ob es was bringt, wenn ich die Tage einfach die vSwitches im ESXi an eine zusätzliche PCIe NIC hänge und von da aus dann auf das IPMI gehe. Notfalls werden die onboard NICs zu StorageNICs verdonnert :fresse:
 
Ja bei mir ist die IPMI mit einer der beiden LAN-Buchsen geshared.
 
OK, bei mir sind es ja drei einzelne Ports.
Das die Sharedlösungen wohl nicht auf sich selbst zugreifen können weiß ich noch von meinem Core 2 Board, bei dem die NIC und vPRO ein einzelner Port waren. Das stand in dem Fall aber auch im Handbuch. Bei SM ist mir da leider noch nichts aufgefallen.

Vielleicht schaut hier ja noch einer vorbei, bei dem das IPMI auch auf nem eigenständigen Port lauft und das mal kurz testen kann :wink:
 
@steggi

Schon weitergekommen?

Geh mal ins IPMI Interface->Config->Network->ganz unten "LAN Interface" -> "dedicated". Das sollte dann klappen.
 
Zuletzt bearbeitet:
Bei meinem X9SCL-F kann ich problemlos von den normalen NICs aufs IPMI Modul zugreifen. Da muss aber der dedicated Anschluss auch angeschlossen sein. Und bei neueren SM Boards kann man den Anschluss zum IPMI nicht konfigurieren - da geht nur der dedicated. Übrigens funktioniert der nur, wenn das Netzwerk Kabel am dedicated Anschluss angeschlossen ist, wenn der BMC bootet. D.h., wenn man das Kabel im Betrieb abzieht und dann wieder ansteckt, ist IPMI tot :(
 
Ich habe ein H8SGL und da kann man das LAN Interface einstellen.

Ich kann bei meinen Boards auch nach durchgestartetem BMC den IPMI Port mit dem LAN Verbinden und habe auch direkt Zugriff. (H8SGL und H8DI3+) Ich kann da Stecken und Ziehen wie ich will, Verbindung geht dann sofort wieder.

Wer dynamische IPs hat, da mag das sein. Zumindest meine ich mich zu erinnern, dass das am Anfang so war. Der BMC bekam dann keine IP vom DHCP und hat sich dann eine eigene Ausgedacht. Er hat diese auch nicht mehr aktualisiert, nachdem die Connection da war.
 
Zuletzt bearbeitet:
Naja, das X9SCL-F scheint auch ein Sonderfall zu sein. Die IPMI Adresse ist natürlich statisch (wäre blöd, die jedesmal neu zu suchen oder extra den Router zu programmieren). Trotzdem geht es nur, wenn der BMC neu bootet. Ich erinnere mich auch, dass man bei anderen SM Boards wesentlich mehr Einstellmöglichkeiten hatte. Bei Asus ist das übrigens so, dass man 2 IPs vergeben kann - eine für den dedicated und eine für einen shared. In dem einzigen Fall, wo ich bisher damit ein Problem hatte, haben aber beide nicht funktioniert.:fresse:
 
@steggi

Schon weitergekommen?

Geh mal ins IPMI Interface->Config->Network->ganz unten "LAN Interface" -> "dedicated". Das sollte dann klappen.

Die steht schon auf dedicate, und laufen tuts immer noch nicht :(

Die IP ist bei mir übrigens auch statisch
 
Das ist doch eigenartig. Sind die MACs unterschiedlich? Sollten sie ja eigentlich.

Wie sieht das denn aus bei dir mit dem Umstand, dass die normalen NICs IPMI können, sollte ja nun nicht gehen.
 
Das ist doch eigenartig. Sind die MACs unterschiedlich? Sollten sie ja eigentlich.

Ja sind sie...

IPMI --> 00-25-90-6F-ac-47
NIC1 --> 00-25-90-6b-05-dc
NIC2 --> 00-25-90-6b-05-dd

Zudem steht ja auch auf der SM Seite zu dem Board, dass es eine eigenständige NIC ist :p

Network Controllers

Intel® i350 Dual Port Gigabit Ethernet
Virtual Machine Device Queues reduce I/O overhead
Supports 10BASE-T, 100BASE-TX, and 1000BASE-T, RJ45 output
1x Realtek RTL8201N PHY (dedicated IPMI)


Wie sieht das denn aus bei dir mit dem Umstand, dass die normalen NICs IPMI können, sollte ja nun nicht gehen.

Nö, auf den anderen Ports läuft kein IPMI, da lauscht nur der ESXi^^
 
Irgendwelche Quelladressfilter hast du aber nicht drin?

Gesendet von meinem HTC One X mit der Hardwareluxx App
 
Update zum X9SCL-F: Nach Firmware-Update des IPMI Modules (einfach, problemlos, remote) und BIOS Update (sehr zickig) kann man das Netzwerkkabel am IPMI anschließen, wann man will und es funktioniert. :)
 
OK, das Problem tritt bei mir ja nicht auf (habs grade nochmal getestet) aber leider gibts für das X9DRI-F keine (neuere) Firmware zum Download. Zumindest war hier --> Super Micro Computer, Inc. | Support <-- nix zu finden, und das BIOS ist immer noch die neueste Version...

Ich hab zwar inzwischen eine der neuen NICs bekommen, allerdings fehlt mir im Moment sowohl die Zeit für den Einbau als auch kommt die Quad Port NIC ins Storage und nicht in den ESXi, da wirds nur ne Dual Port NIC und die ist noch unterwegs :coffee:
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh