26
HP 2910al-48G Switch Redundant (Welche Einstellung?)
Hallo Liebe Gemeinde,
ich stehe vor der Aufgabe, 2 HP 2910 Switche redundant fahren zu lassen.
Folgende Struktur:
2 ESXi-Hosts (VMWARE) mit jeweils 2 NIC´s.
2 HP-2910er Switche.
Nun will ich die Ports am Switch konfigurieren und weiß nicht was ich einstellen muss.
Ich möchte ESXi1 an Switch 1 und 2 jeweils an Port 1 und 2 anstecken.
Nun gibt es Trunk Group / Trunk Type usw.
Welche Einstellung muss ich vornehmen?
Lieben Gruß
MKS
ich stehe vor der Aufgabe, 2 HP 2910 Switche redundant fahren zu lassen.
Folgende Struktur:
2 ESXi-Hosts (VMWARE) mit jeweils 2 NIC´s.
2 HP-2910er Switche.
Nun will ich die Ports am Switch konfigurieren und weiß nicht was ich einstellen muss.
Ich möchte ESXi1 an Switch 1 und 2 jeweils an Port 1 und 2 anstecken.
Nun gibt es Trunk Group / Trunk Type usw.
Welche Einstellung muss ich vornehmen?
Lieben Gruß
MKS
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 302813
Url: https://administrator.de/contentid/302813
Ausgedruckt am: 25.11.2024 um 22:11 Uhr
26 Kommentare
Neuester Kommentar
Hallo,
Und deine ESXi sollen jeweils pro NIC eine eigene andere IP haben (also 4 IPs oder doch nur 2 und die IPs sind alle aus dem gleichen Netz), oder?
Gruß,
Peter
Und deine ESXi sollen jeweils pro NIC eine eigene andere IP haben (also 4 IPs oder doch nur 2 und die IPs sind alle aus dem gleichen Netz), oder?
Gruß,
Peter
Hallo Pjodorf,
die Nic´s sollen 1 IP haben.
die Nic´s sollen 1 IP haben.
Nachtrag: es wird über VM-Ware ein Lastenausgleich gefahren. Es sind 2 aktive Nic´s.
"Anhand IP-Hashs routen" heisst es bei VMware.
"Anhand IP-Hashs routen" heisst es bei VMware.
Hi,
wenn mich nicht alles täuscht, musst du die Switche stacken, damit diese als ein logischer Switch in erscheinung treten.
Dazu müsstet ihr eure 2910er aber mit entsprechenden Modulen erweitern...
Ich beschäftige mich gerade ebenfalls mit dieser Thematik, komme allerdings von zwei HP 1810-24G Switchen, welche nun gegen zwei Cisco SG500X-48 Switche getauscht werden und in dem Zuge gestacked werden sollen (die Lieferung wird erwartet :D).
Vermutlich sollte dir dieser Beitrag im HPE-Forum weiterhelfen:
http://community.hpe.com/t5/ProCurve-ProVision-Based/2920-Stack-with-Es ...
Zudem dieser Link von hier:
HP 2920-48G im Stack
Insgesamt würde ich aber u.U. noch aqui's Feedback hier abwarten. Vielleicht gäbe es ja eine andere Variante..
Gruß
em-pie
wenn mich nicht alles täuscht, musst du die Switche stacken, damit diese als ein logischer Switch in erscheinung treten.
Dazu müsstet ihr eure 2910er aber mit entsprechenden Modulen erweitern...
Ich beschäftige mich gerade ebenfalls mit dieser Thematik, komme allerdings von zwei HP 1810-24G Switchen, welche nun gegen zwei Cisco SG500X-48 Switche getauscht werden und in dem Zuge gestacked werden sollen (die Lieferung wird erwartet :D).
Vermutlich sollte dir dieser Beitrag im HPE-Forum weiterhelfen:
http://community.hpe.com/t5/ProCurve-ProVision-Based/2920-Stack-with-Es ...
Zudem dieser Link von hier:
HP 2920-48G im Stack
Insgesamt würde ich aber u.U. noch aqui's Feedback hier abwarten. Vielleicht gäbe es ja eine andere Variante..
Gruß
em-pie
Danke für deine Antowort. Gerne warte ich auf Aqui oder Pjordorf.
So schaut es jetzt aus:
bzw. so habe ich es vor.
PS: ich habe verbessen das die beiden Switche natürlich noch über 4 Kupferkabel verbunden sein müssen.
bzw. so habe ich es vor.
PS: ich habe verbessen das die beiden Switche natürlich noch über 4 Kupferkabel verbunden sein müssen.
Moin,
wen du das so wie beschrieben machen willst musst du mit den Switchen (vmwareseitig) gar nix machen, das Loadbalancing uebernimmt VMware anhand der IP der VM. Wenn du allerdings mehrere NICs pro Server auf einen Switch verbinden willst brauchst du bei IP Hash einen Trunk/Etherchannel ueber die NICs je Server. Ich wuerde an deiner Stelle aber KISS machen und Port Hash verwenden. Ich wuerde die Switche auch nicht stacken, da sie dann bei einem Firmwareupdate beide gleichzeitig rebooten. Da braucht man dann wieder ein Wartungsfenster. Ansonsten halt noch ein Trunk fuer die 4 Switchverbindungen und dann kanns losgehen.
VG,
Thomas
wen du das so wie beschrieben machen willst musst du mit den Switchen (vmwareseitig) gar nix machen, das Loadbalancing uebernimmt VMware anhand der IP der VM. Wenn du allerdings mehrere NICs pro Server auf einen Switch verbinden willst brauchst du bei IP Hash einen Trunk/Etherchannel ueber die NICs je Server. Ich wuerde an deiner Stelle aber KISS machen und Port Hash verwenden. Ich wuerde die Switche auch nicht stacken, da sie dann bei einem Firmwareupdate beide gleichzeitig rebooten. Da braucht man dann wieder ein Wartungsfenster. Ansonsten halt noch ein Trunk fuer die 4 Switchverbindungen und dann kanns losgehen.
VG,
Thomas
Hi tkr,
also an den Switchen muss ich beispielsweise einen Trunk1 mit Port 1+2 erstellen?
Lacp oder TRK?
also an den Switchen muss ich beispielsweise einen Trunk1 mit Port 1+2 erstellen?
Lacp oder TRK?
Nein musst du nicht, die Verbindungen kommen doch jeweils von diskreten Servern.
VG,
Thomas
VG,
Thomas
Um die beiden NIC Links als Link Aggregation zu fahren mit 802.3ad und LACP was sehr sinnvoll wäre, müssen die beidne Switches stacking fähig sein !
Hier ist aber Vorsicht angebracht. Billigheimer HP supportet meist nur ein einfaches Clustering was die frech als Stacking bezeichnen.
Clustering führt die Switches nur managementmäßig zusammen.
Bei echtem Stacking agieren die Geräte als physisch ein Switch. Das muss auch so sein, denn sonst wäre es technisch nicht möglich die beiden las 802.3ad, LACP Link Aggregation konfigurierten Server Links auf beide Geräte aufzuteilen.
Es kommt somit zu einem Loop und zum Netzwerk Kollaps.
Man kann die Server Links dann nur gänzlich ohne Link Aggregation betreiben.
Sind hier VLANs mit im Spiel ?
Hier ist aber Vorsicht angebracht. Billigheimer HP supportet meist nur ein einfaches Clustering was die frech als Stacking bezeichnen.
Clustering führt die Switches nur managementmäßig zusammen.
Bei echtem Stacking agieren die Geräte als physisch ein Switch. Das muss auch so sein, denn sonst wäre es technisch nicht möglich die beiden las 802.3ad, LACP Link Aggregation konfigurierten Server Links auf beide Geräte aufzuteilen.
Es kommt somit zu einem Loop und zum Netzwerk Kollaps.
Man kann die Server Links dann nur gänzlich ohne Link Aggregation betreiben.
Sind hier VLANs mit im Spiel ?
Hi Aqui, ja Vlans sind im Spiel.
OK, wird aber erst relevant wenn du sicher klären kannst ob die Switches voll stackbar sind oder ob sie nur ein billiges Clustering supporten.
Manual sollte hier helfen...
Ein paar Grundlagen erklärt dieses Tutorial:
Netzwerk Management Server mit Raspberry Pi
Manual sollte hier helfen...
Ein paar Grundlagen erklärt dieses Tutorial:
Netzwerk Management Server mit Raspberry Pi
Hi Aqui, dann müssen die Switches "nur" auf das ensprechnede Vlan-Netz getagged werden und gut is.
Am Switch trunke ich Port 1+2. Fertig
Am Switch trunke ich Port 1+2. Fertig
Ich glaube, du brauchst da nirgends etwas trunken/ eine lag einrichten.
Problem:
Der HP scheint kein echtes stacking zu können:
"2. Seite, unten links"
Wenn du nun auf Port 1+2 eine LAG einrichtest, erwartet der Switch auf der Seite gegenüber physikalisch ein einziges Gerät. Was du aber hättest, wären zwei Geräte: ESX01 und ESX02
Ich habe es aktuell so, dass lediglich ein ESX Host mit 4 Beinen an einem Switch hängt, dort die vier Ports als tagged für die relevanten vlans gesetzt und in VMware derzeit alles auf default belassen. Ergo Port-basiertes Loadbalancing, wobei das momentan nicht redundant ist, daher u.A. die o.g Änderung.
Es müsste (noch nicht getestet) daher funktionieren, wenn du einfach je Server 1 Bein an einen Switch hängst (wie in deiner Zeichnung). Lediglich die vlans an den Ports 1+2 auf tagged setzen. Rest macht VMware. Also wie tkr bereits versuchte zu formulieren.
Zwischen beiden Switches kannst du aber 'nen Trunk formen, sofern nicht jeder der Switche an einem gemeinsamen Core-Switch hängt und STP nicht konfiguriert ist.
Problem:
Der HP scheint kein echtes stacking zu können:
"2. Seite, unten links"
Wenn du nun auf Port 1+2 eine LAG einrichtest, erwartet der Switch auf der Seite gegenüber physikalisch ein einziges Gerät. Was du aber hättest, wären zwei Geräte: ESX01 und ESX02
Ich habe es aktuell so, dass lediglich ein ESX Host mit 4 Beinen an einem Switch hängt, dort die vier Ports als tagged für die relevanten vlans gesetzt und in VMware derzeit alles auf default belassen. Ergo Port-basiertes Loadbalancing, wobei das momentan nicht redundant ist, daher u.A. die o.g Änderung.
Es müsste (noch nicht getestet) daher funktionieren, wenn du einfach je Server 1 Bein an einen Switch hängst (wie in deiner Zeichnung). Lediglich die vlans an den Ports 1+2 auf tagged setzen. Rest macht VMware. Also wie tkr bereits versuchte zu formulieren.
Zwischen beiden Switches kannst du aber 'nen Trunk formen, sofern nicht jeder der Switche an einem gemeinsamen Core-Switch hängt und STP nicht konfiguriert ist.
hi em-pie,
ja so habe ich das ganze auch verstanden. Zwischen den beiden Switchen wollte ich 4 Kupfer zusammen zu einem trunk führen.
Ich bin mir bei einem trunk nicht sicher, ob ich hier stp aktivieren muss?
Gruss mks
ja so habe ich das ganze auch verstanden. Zwischen den beiden Switchen wollte ich 4 Kupfer zusammen zu einem trunk führen.
Ich bin mir bei einem trunk nicht sicher, ob ich hier stp aktivieren muss?
Gruss mks
Ich meine wenn ich von Switch 1 auf Switch 2 mit 4 Kupfer-Kabeln gehe, dann muss ich doch einen Trunk machen oder?
In diesem Fall muss STP nicht aktiviert werden?
In diesem Fall muss STP nicht aktiviert werden?
Jupp, so schaut es aus.
Aqui wird vermutlich STP empfehlen, aber es funktioniert auch ohne. Hab es ebenfalls so am laufen ;)
Aqui wird vermutlich STP empfehlen, aber es funktioniert auch ohne. Hab es ebenfalls so am laufen ;)
Also wenn ich dich richtig verstehe muss ich bei einem Trunk (egal wieviel Ports) nie STP aktivieren, da dieser als 1 Port zählt?
Wenn ich Spanning Tree auf dem Switch aktiviere, und mit 4 Leitungen die Redundanz zwischen den beiden Cores bilde, wieviele werden dann geblockt? 3?
Wenn ich Spanning Tree auf dem Switch aktiviere, und mit 4 Leitungen die Redundanz zwischen den beiden Cores bilde, wieviele werden dann geblockt? 3?
müssen die Switches "nur" auf das ensprechnede Vlan-Netz getagged werden und gut is.
Am Switch trunke ich Port 1+2. FertigJa, richtig, wenn du damit deine aggregierten Uplinks meinst ! Wenn du mit VLANs arbeitest müssen die Tagged sein und als LACP LAGs definiert sein, richtig.
Sorgen sollte dir allerdings das bereiten was Kollege em-pie schreibt sofern es denn wahr ist: "Der HP scheint kein echtes stacking zu können:"
Das ist leider bei HP Billigswitches oft so. Ein Grund die Finger von HP zu lassen aber viele wollen ja da nicht hören und meinem immer wer gute Drucker und Laptops bauen kann kann auch Netzwerk...das genaue Gegenteil ist der Fall.
Wenn dem so ist ist das natürlich der Todesstoß für deinen Split Trunks (LAGs).
Im Grunde schmeisst das dann dein ganzes Konzept über den Haufen und diese Switches kannst du als gestacktes Core Pärchen dann sofort vergessen ! Ein krasser Fehlkauf wäre das dann.
Mit z.B. 2 Brocade ICX 7250 wärst du da erheblich besser gefahren. Sollte es denn stimmen...?!
Mit STP dann zu handhaben und zu basteln konterkariert dein gesamtes Ausfallsicheres Core Konzept ! Damit schaffst du eine Krücke die dir nicht hilft nur um diese übelen Switches zu behalten.
Wenn die neu sind versuche die besser gegen "richtige" stacking fähige Switches zu tauschen wie z.B. die oben genannten.
Wenn ich Spanning Tree auf dem Switch aktiviere, und mit 4 Leitungen die Redundanz zwischen den beiden Cores bilde, wieviele werden dann geblockt?
3 werden geblockt, das ist richtig ! Es darf ja niemals einen Loop im Ethernet geben !Tausch die Switches wenn irgend möglich...das wäre die beste Lösung.
Am Switch trunke ich Port 1+2. Fertig
Ja, richtig, wenn du damit deine aggregierten Uplinks meinst ! Wenn du mit VLANs arbeitest müssen die Tagged sein und als LACP LAGs definiert sein, richtig.
Ja, richtig, wenn du damit deine aggregierten Uplinks meinst ! Wenn du mit VLANs arbeitest müssen die Tagged sein und als LACP LAGs definiert sein, richtig.
Ja auf den Ports sind wie in der Zeichnung ESX1 und ESX2 angeschlossen. Sollten der Trunk auch auf LACP stehen?
Sorry mein Fehler, nein das sind die Ports für die ESX´n.
Sollten der Trunk auch auf LACP stehen?
In jedem Fall ! Bei LAGs zwischen herstellerfremden Geräten sollte IMMER LACP aktiviert sein ! So oder so ist es immer sinnvoll LACP zu aktivieren. Bei statischen Trunks sollte man genau wissen was man tut.LACP ist immer erste Wahl.
Trunks und ESXi guckst du hier:
LACP and ESXi 5.1
@mks
Bedenke aber, dass ein Trunk zwischen ESX und Switch nur funktioniert, wenn du ein echtes stacking bei den Switchen hinbekommst.
Ein Trunk auf einem Switch zu errichten, bei dem jeder Trunk-Member (also ein Port) von unterschiedlichen ESXi Hosts stammt, ist ohne einen Stack nicht umsetzbar (ausnahme wären noch modulare Chassi-Switche, z.B. HP5406zl).
schau dir dazu auch folgenden Beitrag an, insbesonde den Absatz über dem Cisco-Chassis-Switch
Quelle1 und Quelle2
@aqui
LACP in vmWare funktioniert nur mit Distributed Switches.
Dieses Feuture ist aber erst in der höchsten Lizenzversion (Enterprise Plus) erhältlich: Quelle
Ich stelle mal die Behauptung auf, dass diese Lizenz bei mks nicht existent ist.
Bedenke aber, dass ein Trunk zwischen ESX und Switch nur funktioniert, wenn du ein echtes stacking bei den Switchen hinbekommst.
Ein Trunk auf einem Switch zu errichten, bei dem jeder Trunk-Member (also ein Port) von unterschiedlichen ESXi Hosts stammt, ist ohne einen Stack nicht umsetzbar (ausnahme wären noch modulare Chassi-Switche, z.B. HP5406zl).
schau dir dazu auch folgenden Beitrag an, insbesonde den Absatz über dem Cisco-Chassis-Switch
Quelle1 und Quelle2
@aqui
LACP in vmWare funktioniert nur mit Distributed Switches.
Dieses Feuture ist aber erst in der höchsten Lizenzversion (Enterprise Plus) erhältlich: Quelle
Ich stelle mal die Behauptung auf, dass diese Lizenz bei mks nicht existent ist.
Hallo Aqui, nein diese Lizenz ist leider nicht vorhanden.
Gilt folgende Aussage als richtig --> bei einem grtrunkten Port ist kein STP nötig, egal wieviele Ports?
@em-pie vielen Dank für diese Info.
Gilt folgende Aussage als richtig --> bei einem grtrunkten Port ist kein STP nötig, egal wieviele Ports?
@em-pie vielen Dank für diese Info.
STP ist nur zur Loopvermeidung da !!
Generell stimmt deine Aussage. Aaaaber...
Viele Treiber, besonders bei PS bzw. Server basierten Endgeräten sind schlampig programiert. Im Fall des Bootens oder andere undefinierter Status der NICs kann es zu einem Loop kommen der dann das netzwerk lahm legt.
Verantwortungsvolle Netzwerker lassen also IMMER auch STP aktiviert auf den Switchkomponenten wenn sie mit LACP LAGs hantieren !
Es dient der Sicherheit und Stabilität. Ein redundantes Netzwerk ohne eine Art von STP zu betreiben ist Russisches Roulette !
Ausnahme: Du hast vollständig stackbare Switches ! Die müssen dann aber richtiges Stacking supporten und nicht nur so ein billiges Clustering wie die HP Billigswitches.
Generell stimmt deine Aussage. Aaaaber...
Viele Treiber, besonders bei PS bzw. Server basierten Endgeräten sind schlampig programiert. Im Fall des Bootens oder andere undefinierter Status der NICs kann es zu einem Loop kommen der dann das netzwerk lahm legt.
Verantwortungsvolle Netzwerker lassen also IMMER auch STP aktiviert auf den Switchkomponenten wenn sie mit LACP LAGs hantieren !
Es dient der Sicherheit und Stabilität. Ein redundantes Netzwerk ohne eine Art von STP zu betreiben ist Russisches Roulette !
Ausnahme: Du hast vollständig stackbare Switches ! Die müssen dann aber richtiges Stacking supporten und nicht nur so ein billiges Clustering wie die HP Billigswitches.
Für solche lächerliche Konfig mit 3 Zeilen CLI Code etwas viel Aufwand....
Das Grundproblem des fehlenden Full Stackings was die Maschinen einfach nicht können, hier aber zwingend erforderlich wäre, würden die TBCS Kollegen wohl auch nicht fixen können.
Die könnten nur einen schlechten Workaround mit Spanning Tree machen. Ein ziemlicher Rückschroitt in die netzwerk Steinzeit dann für den TO und seine Anforderung. Mehr wird dann wohl auch nicht machbar sein wenn er nicht noch tauschen kann...?!
Fazit: Falsche HW
Das Grundproblem des fehlenden Full Stackings was die Maschinen einfach nicht können, hier aber zwingend erforderlich wäre, würden die TBCS Kollegen wohl auch nicht fixen können.
Die könnten nur einen schlechten Workaround mit Spanning Tree machen. Ein ziemlicher Rückschroitt in die netzwerk Steinzeit dann für den TO und seine Anforderung. Mehr wird dann wohl auch nicht machbar sein wenn er nicht noch tauschen kann...?!
Fazit: Falsche HW
