24
Ubiquiti Verständnisfrage
Moin,
ich habe mal eine Verständnisfrage.
Wir haben 2 HP DL380 gen9 als vmware Cluster.
Momentan hängen beide an einem HP Procurve Stack, was sich ändern soll.
Der Plan ist folgender:
Jeder DL 380 verfügt über 4 10 GBit Netzwerkports.
Wir verfügen über 2 US-16-XG.
ESXI1 Port 1 und 2 soll an US-16-XG
ESXI1 Port 3 und 4 soll an US-16-XG
ESX2 Port 1 und 2 soll an US-16-XG
ESX2 Port 3 und 4 soll an US-16-XG
Dann sollen die Client-Switche jeweils mit einem Uplink an jeden US-16-XG Switch.
Wie muss ich das konfigurieren? Ich wäre über jeden Tipp echt dankbar, denn eine Portgruppe (LAG) kann ich ja nur an einen Switch binden. Ich würde in der vmware Umgebung auf jeden ESXI einen vswitch haben und die relevanten vLANS auf dem vSwitch an die NICs binden, korrekt?
Würde die Konfig so passen?
Und was stelle ich im Unifi Controller ein? Einfach nur die beiden Kupfer-Uplinks der USG, die an einen esxi gehen, als Aggregation Ports?
Ich wäre euch für sachdienliche Hinweise echt dankbar.
ich habe mal eine Verständnisfrage.
Wir haben 2 HP DL380 gen9 als vmware Cluster.
Momentan hängen beide an einem HP Procurve Stack, was sich ändern soll.
Der Plan ist folgender:
Jeder DL 380 verfügt über 4 10 GBit Netzwerkports.
Wir verfügen über 2 US-16-XG.
ESXI1 Port 1 und 2 soll an US-16-XG
ESXI1 Port 3 und 4 soll an US-16-XG
ESX2 Port 1 und 2 soll an US-16-XG
ESX2 Port 3 und 4 soll an US-16-XG
Dann sollen die Client-Switche jeweils mit einem Uplink an jeden US-16-XG Switch.
Wie muss ich das konfigurieren? Ich wäre über jeden Tipp echt dankbar, denn eine Portgruppe (LAG) kann ich ja nur an einen Switch binden. Ich würde in der vmware Umgebung auf jeden ESXI einen vswitch haben und die relevanten vLANS auf dem vSwitch an die NICs binden, korrekt?
Würde die Konfig so passen?
Und was stelle ich im Unifi Controller ein? Einfach nur die beiden Kupfer-Uplinks der USG, die an einen esxi gehen, als Aggregation Ports?
Ich wäre euch für sachdienliche Hinweise echt dankbar.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 5492848340
Url: https://administrator.de/contentid/5492848340
Printed on: April 27, 2024 at 15:04 o'clock
24 Comments
Latest comment
Moin,
eine USG unterstützt kein LAG.
Das, was du machen kannst, ist mithilfe von Spanning Tree eine redundante Verkabelung danach erzeugen.
Ein Beispiel.
VG
eine USG unterstützt kein LAG.
Das, was du machen kannst, ist mithilfe von Spanning Tree eine redundante Verkabelung danach erzeugen.
Ein Beispiel.
VG
Moin,
sch... ich hatte oben einen Typo. Schon zu spät. US-16-XG und der kann LAG
sch... ich hatte oben einen Typo. Schon zu spät. US-16-XG und der kann LAG
Du sprichst von dem Fiber Switch, wenn du USG schreibst und nicht von dem UniFi Security Gateway?
Hey du,
ja, ich habe da gerade ein paar Abkürzungen durcheinandergeworfen.
Ich meine das ding hier:
https://store.ui.com/collections/unifi-network-switching/products/unifi- ...
ja, ich habe da gerade ein paar Abkürzungen durcheinandergeworfen.
Ich meine das ding hier:
https://store.ui.com/collections/unifi-network-switching/products/unifi- ...
Du bräuchtest m-lag das kann ubishity aber nicht.
Was stimmt den mit den Oro Curves nicht? Welche sind das?
Warum soll vom ESXI ein LAG zum Switch gehen?
Und bist du dir sicher, wirklich die Ubnt Switches als Ersatz für die Pro Curves nehmen zu wollen?
Dito. Das wäre das Optimum.
Warum soll vom ESXI ein LAG zum Switch gehen?
Und bist du dir sicher, wirklich die Ubnt Switches als Ersatz für die Pro Curves nehmen zu wollen?
Dito. Das wäre das Optimum.
Hallo,
Hast du die Enterprise Plus von VMware? Ich glaube nicht, denn dann hättest du kein normales vSwitch Standard.
Also kannst du somit dein vorhanden mit LAG / LACP vergessen.
Denn nur mit DistributedSwitches „richtige“ LAG bei VMware möglich.
Andernfalls verbindest du die Server nur direkt an die Switches (auch unterschiedliche) und konfigurierst in VMware die Schnittstellen als active oder Standby. Wie ist deine Entscheidung.
Funktioniert problemlos und ist auch so natürliches supported.
Ps.: ich hatte jahrelang 5 ESXI Hosts an Unifi US-16-XG angeschlossen
Hast du die Enterprise Plus von VMware? Ich glaube nicht, denn dann hättest du kein normales vSwitch Standard.
Also kannst du somit dein vorhanden mit LAG / LACP vergessen.
Denn nur mit DistributedSwitches „richtige“ LAG bei VMware möglich.
Andernfalls verbindest du die Server nur direkt an die Switches (auch unterschiedliche) und konfigurierst in VMware die Schnittstellen als active oder Standby. Wie ist deine Entscheidung.
Funktioniert problemlos und ist auch so natürliches supported.
Ps.: ich hatte jahrelang 5 ESXI Hosts an Unifi US-16-XG angeschlossen
M-LAG oder Stacking Option wäre essentiell um diese beiden Switches in einen redundanten Verbund zu bringen.
Link Aggregation (LAG) im Netzwerk
Link Aggregation (LAG) im Netzwerk
Das Ubiquiti-Spielzeug nimmt man wegen solcher Klopper auch nicht im professionellen Firmenumfeld, sorry.
1Das Ubiquiti-Spielzeug...
Wahre Worte...! In einer redundanten ESXi Server Umgebung wo es auf Verfügbarkeit ankommt ein NoGo...aber egal!Zitat von @aqui:
Das Ubiquiti-Spielzeug...
Wahre Worte...! In einer redundanten ESXi Server Umgebung wo es auf Verfügbarkeit ankommt ein NoGo...aber egal!„Aber es ist doch soooo billig…!“ wie oft muss man sich sowas anhören.
Ich sollte mal für ein Kraftwerk ein neues Netzwerkkonzept erstellen. Da kam dann einer der IT „Manager“ auf die Idee und hat Ubiquiti in den Raum geworfen. Ich wäre am liebsten heulend aus dem Raum verschwunden… das Zeug hat einfach in keiner Firmenumgebung was zu suchen.
Einfach unglaublich.
1
Das muss aber ein komisches Kraftwerk sein, dass nicht mit Ubnt laufen würde.
Ein bisschen 104 kann ich auch mit Rauchzeichen übertragen.
Ein bisschen 104 kann ich auch mit Rauchzeichen übertragen.
Zitat von @2423392070:
Das muss aber ein komisches Kraftwerk sein, dass nicht mit Ubnt laufen würde.
Ein bisschen 104 kann ich auch mit Rauchzeichen übertragen.
Das muss aber ein komisches Kraftwerk sein, dass nicht mit Ubnt laufen würde.
Ein bisschen 104 kann ich auch mit Rauchzeichen übertragen.
Ich nehme an, das ist Ironie
Falls nicht, allein die Anzahl der VLAN-Interfaces, BGP im Core, OSPF zwischen Core + Aggregation und die quasi nicht vorhandene "Stacking-Fähigkeit" sind hier einige der Argument.
Dazu kommt: Hersteller-Support. Der ist quasi Pflicht. Ebenso wie eine 4h Mission Critical (auch, wenn Spare-Parts vor Ort sind - das Chassis oder die Fabric des Cores ist es meist nicht)
Wir reden von Leitständen und Leittechnik?
Ich kenne diverse Kraftwerke, Gas, Strom, Kohle, Photovoltaik und da sind ein per Fernwirksysteme von z. B. SAE mit etwas Siemens und Wago Geraffel...
Der werden Telegramme (104) vorrangig getauscht und dazu ist fast nichts nötig.
Ich kenne diverse Kraftwerke, Gas, Strom, Kohle, Photovoltaik und da sind ein per Fernwirksysteme von z. B. SAE mit etwas Siemens und Wago Geraffel...
Der werden Telegramme (104) vorrangig getauscht und dazu ist fast nichts nötig.
Zitat von @2423392070:
Wir reden von Leitständen und Leittechnik?
Ich kenne diverse Kraftwerke, Gas, Strom, Kohle, Photovoltaik und da sind ein per Fernwirksysteme von z. B. SAE mit etwas Siemens und Wago Geraffel...
Der werden Telegramme (104) vorrangig getauscht und dazu ist fast nichts nötig.
Wir reden von Leitständen und Leittechnik?
Ich kenne diverse Kraftwerke, Gas, Strom, Kohle, Photovoltaik und da sind ein per Fernwirksysteme von z. B. SAE mit etwas Siemens und Wago Geraffel...
Der werden Telegramme (104) vorrangig getauscht und dazu ist fast nichts nötig.
Wir reden von dem gesamten Netzwerk. Unterteilt in zahlreiche Unterbereiche. Der Leitstand ist ein sehr kleiner davon. WAGO spielt dort keine Rolle (außer die WAGO Klemmen natürlich in zahlreichen E-Verteilungen
) - Siemens schon eher, ABB noch viel mehr.Das Prozessnetz an sich ist noch einmal eine ganz andere Nummer.
Es geht dabei nicht darum, dass der Switch nicht in der Lage wäre Pakete zu schubsen, sondern niemand ihm eine solche Aufgabe zutrauen würde
dafür ist das Netzwerk schlicht zu kritisch.
Ich rede auch vom gesamten Netzwerk. Wenn das Netz down ist geht alles seinen Gang, es muss lediglich ein Mensch vor Ort sein und sich bewegen.
Ich würde sowas nicht am OEM festmachen und auch so nicht argumentieren.
Persönliche Präferenzen ja, das kann man vertreten. Sollte man aber auch als persönliche Präferenzen kennzeichnen.
Ich würde Ubnt auch dort nicht einsetzen und wenn auch nur als Access Switches, aber viel weiter würde ich nicht gehen.
Ubnt liefert viel Switch mit SDN fürs Geld und hat keine nennenswert hohen Ausfälle. Kann nur eben nicht viel.
Und bei der IT geht es oft um die Ausfallwahrscheinlichkeit.
Ich würde sowas nicht am OEM festmachen und auch so nicht argumentieren.
Persönliche Präferenzen ja, das kann man vertreten. Sollte man aber auch als persönliche Präferenzen kennzeichnen.
Ich würde Ubnt auch dort nicht einsetzen und wenn auch nur als Access Switches, aber viel weiter würde ich nicht gehen.
Ubnt liefert viel Switch mit SDN fürs Geld und hat keine nennenswert hohen Ausfälle. Kann nur eben nicht viel.
Und bei der IT geht es oft um die Ausfallwahrscheinlichkeit.
Zitat von @2423392070:
Ich rede auch vom gesamten Netzwerk. Wenn das Netz down ist geht alles seinen Gang, es muss lediglich ein Mensch vor Ort sein und sich bewegen.
Ich rede auch vom gesamten Netzwerk. Wenn das Netz down ist geht alles seinen Gang, es muss lediglich ein Mensch vor Ort sein und sich bewegen.
und das "Down" möchte ich nicht erleben. Daher Redundanzen - diese sind jedoch Loop-Free mit Ubiquiti meines Wissens nach nicht zu realisieren.
MLAG, OSPF mit ECMP -> Spine/Leaf mit VXLAN...
Ich weiß nicht was es bringen soll, Features zu vergleichen, die man nicht braucht und die ein Wettbewerber nicht beherrscht.
Du vergleichst Features eines hunderte Euro Switch mit denen eines tausende Euro Switch.
Ich könnte dir jetzt was über unsere Force10 oder Nvidia Switches erzählen. Bringt aber nichts und am Ende haben die auch nur ein langweiles Dasein.
Laufen aber.
Du vergleichst Features eines hunderte Euro Switch mit denen eines tausende Euro Switch.
Ich könnte dir jetzt was über unsere Force10 oder Nvidia Switches erzählen. Bringt aber nichts und am Ende haben die auch nur ein langweiles Dasein.
Laufen aber.
Zitat von @2423392070:
Ich weiß nicht was es bringen soll, Features zu vergleichen, die man nicht braucht und die ein Wettbewerber nicht beherrscht.
Du vergleichst Features eines hunderte Euro Switch mit denen eines tausende Euro Switch.
Ich könnte dir jetzt was über unsere Force10 oder Nvidia Switches erzählen. Bringt aber nichts und am Ende haben die auch nur ein langweiles Dasein.
Laufen aber.
Ich weiß nicht was es bringen soll, Features zu vergleichen, die man nicht braucht und die ein Wettbewerber nicht beherrscht.
Du vergleichst Features eines hunderte Euro Switch mit denen eines tausende Euro Switch.
Ich könnte dir jetzt was über unsere Force10 oder Nvidia Switches erzählen. Bringt aber nichts und am Ende haben die auch nur ein langweiles Dasein.
Laufen aber.
Es sind nunmal Features, die dort im Einsatz sind. Dass das nicht in jedem Kraftwerk so sein muss, mag ja sein, dennoch gibt es für alles Gründe.
Ein Grund könnte sein, dass man kein Layer 2 Netzwerk über das gesamte Kraftwerk spannen möchte. Ein anderer Grund könnte aber sein, dass der Betreiber das in seiner Ausschreibung so gefordert hat.
Kraftwerk ist ja nicht gleich Kraftwerk.
Reden wir von einem Kraft in dem zusätzlich ein Rechenzentrum betrieben wird oder eine Firma Büros hat?
Wir haben diverse Kraftwerke und sind auch Kritis-Zertifiziert und da würde niemand auf die Idee kommen höhere IT-Technik zu verbauen. Schon allein mit Blick auf Mai 23 und Kritis-Abforderungen ist das problematisch.
Wir haben diverse Kraftwerke und sind auch Kritis-Zertifiziert und da würde niemand auf die Idee kommen höhere IT-Technik zu verbauen. Schon allein mit Blick auf Mai 23 und Kritis-Abforderungen ist das problematisch.
Was ist in euren Kraftwerken denn Kritis zertifiziert? Alles? Oder nur der wirkliche Kritis-Teil?
Ich wüsste keinen Grund warum Ausfallsicherheit bzw Redundanz ein Thema sein sollte, was gegen eine Kritis Zertifizierung sprechen sollte. In einigen Bereichen ist dies sogar vorgeschrieben
Im Ernst: die Prozesstechnik ist natürlich soweit wie möglich von der IT getrennt - inkl. Vorgeschriebenen Medienbruch. Aber vom Prozessnetz redet ja niemand
Ich wüsste keinen Grund warum Ausfallsicherheit bzw Redundanz ein Thema sein sollte, was gegen eine Kritis Zertifizierung sprechen sollte. In einigen Bereichen ist dies sogar vorgeschrieben
Im Ernst: die Prozesstechnik ist natürlich soweit wie möglich von der IT getrennt - inkl. Vorgeschriebenen Medienbruch. Aber vom Prozessnetz redet ja niemand
Alles. Von der Tür im Zaun bis zu Klimaanlage auf dem Dach.
Gehen solche Sachen spricht: Keep it easy an simple.
Es wird eine minimale Bandbreite benötigt und wenn 104er Telegramme nach 10 Minuten eintreffen ist das völlig in Ordnung.
Der Desktop des Leitstandwarts ist ein Edge Client einer ganz anderen Infrastruktur, der lediglich in der selben Liegenschaft steht.
Gehen solche Sachen spricht: Keep it easy an simple.
Es wird eine minimale Bandbreite benötigt und wenn 104er Telegramme nach 10 Minuten eintreffen ist das völlig in Ordnung.
Der Desktop des Leitstandwarts ist ein Edge Client einer ganz anderen Infrastruktur, der lediglich in der selben Liegenschaft steht.
Zitat von @2423392070:
und wenn 104er Telegramme nach 10 Minuten eintreffen ist das völlig in Ordnung.
und wenn 104er Telegramme nach 10 Minuten eintreffen ist das völlig in Ordnung.
Und vorbei ist es mit der Regelreserve.
Das ist aber ein anderes Thema, was dir auch dein OSPF-VXLAN-iPhone-OEM-Switch nicht ändert.