11
NIc teaming und link aggregation
Hallo Leute,
ich hätte einpaar Theorie fragen an euch
1.) Wenn man Nic-Teaming am Server einstellt (beispielsweise mit 4 Interfaces). Bedeutet das ,dass ich 1 Leitung benutze und WENN ein Ausfall stattfindet eine andere einspringt? ODER wenn ich am Switch keine Link-aggregation einstelle, sondern nur Nic-Teaming am Server habe ist dann die geschwindigkeit * 4?
2.) Ist Link-Aggregation ein Trunk (LAG)? oder ist das beim Switch dann eine eigene Konfiguration? ... muss dann der Switch wahrscheinlich können?
3.) Falls dies der Switch kann ist es auch möglich zu sagen 4 Ports sind mit Link-Aggregation gebündelt aber 2 Lan-Kabel führen zu Swtich 1 und 2 Lan-Kabel führen zu Switch 2 wegen Ausfallsicherheit... beide Switche natürlich getrunkt...?
DANKE
lg Samet
ich hätte einpaar Theorie fragen an euch
1.) Wenn man Nic-Teaming am Server einstellt (beispielsweise mit 4 Interfaces). Bedeutet das ,dass ich 1 Leitung benutze und WENN ein Ausfall stattfindet eine andere einspringt? ODER wenn ich am Switch keine Link-aggregation einstelle, sondern nur Nic-Teaming am Server habe ist dann die geschwindigkeit * 4?
2.) Ist Link-Aggregation ein Trunk (LAG)? oder ist das beim Switch dann eine eigene Konfiguration? ... muss dann der Switch wahrscheinlich können?
3.) Falls dies der Switch kann ist es auch möglich zu sagen 4 Ports sind mit Link-Aggregation gebündelt aber 2 Lan-Kabel führen zu Swtich 1 und 2 Lan-Kabel führen zu Switch 2 wegen Ausfallsicherheit... beide Switche natürlich getrunkt...?
DANKE
lg Samet
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: 289331
Url: https://administrator.de/contentid/289331
Ausgedruckt am: 25.11.2024 um 04:11 Uhr
11 Kommentare
Neuester Kommentar
Hahaha das ist nicht ganz so Trivial...
Ja, oft wird Aggregation bei einigen Herstellern als Trunking bezeichnet.
Hyper V unterstützt ja drei Modi beim Teaming. Wenn du einen LACP fähigen Switch hast, kannst LCAP auswählen und auf der gegenstelle einen Switch mit einer 4er LAG konifgurieren.
Grundsätzlich bleibt deine Durchsatzrate bei 1GBit/s pro Stream, die Bandbreite liegt dann aber bei 4GBit/s, es wird also Loabalancing auf dieser einen 4er Verbindung durchgeführt.
Ist eine NicTeam eingestellt, kann der Server nur kommunizieren, wenn auf der Gegenseite auch LACP aktiviert ist. Die LAGruppe auf zwei Switche zu legen ist nicht empfehlenswert. Das wird als distributed trunking bezeichnet, das muss zwingend vom Switchhersteller so vorgesehen und freigegeben sein. Andernfalls kann es zu nicht nachvollziehbaren Kommunikationsproblem führen.
Zwecks ausfallsicherheit auf Switch-Seite solltest du entweder Switche benutzen, die wie bei HP z.B. mittels IRF zu einerm Logischen Switch zusammengeführt werden oder am Server das Feature "Netzwerklastenausgleich" nutzen.
Dann kannst du auch mittels zwei LAGs die Anbindung über zwei Switche realisieren. Dazu gibt es bei MS ausführliche Dokus ;)
Gruß
Ricardo
Ja, oft wird Aggregation bei einigen Herstellern als Trunking bezeichnet.
Hyper V unterstützt ja drei Modi beim Teaming. Wenn du einen LACP fähigen Switch hast, kannst LCAP auswählen und auf der gegenstelle einen Switch mit einer 4er LAG konifgurieren.
Grundsätzlich bleibt deine Durchsatzrate bei 1GBit/s pro Stream, die Bandbreite liegt dann aber bei 4GBit/s, es wird also Loabalancing auf dieser einen 4er Verbindung durchgeführt.
Ist eine NicTeam eingestellt, kann der Server nur kommunizieren, wenn auf der Gegenseite auch LACP aktiviert ist. Die LAGruppe auf zwei Switche zu legen ist nicht empfehlenswert. Das wird als distributed trunking bezeichnet, das muss zwingend vom Switchhersteller so vorgesehen und freigegeben sein. Andernfalls kann es zu nicht nachvollziehbaren Kommunikationsproblem führen.
Zwecks ausfallsicherheit auf Switch-Seite solltest du entweder Switche benutzen, die wie bei HP z.B. mittels IRF zu einerm Logischen Switch zusammengeführt werden oder am Server das Feature "Netzwerklastenausgleich" nutzen.
Dann kannst du auch mittels zwei LAGs die Anbindung über zwei Switche realisieren. Dazu gibt es bei MS ausführliche Dokus ;)
Gruß
Ricardo
Hi,
ich gehe jetzt mal davon aus, das du Nic-Teaming = LACP ist.
wie soll denn sonst der Switch wissen was er mit dem Datenhaufen machen soll. Es käme eh vorher keine Kommunikation zustande.
Wenn du den 4er Port in 2er Ports zerlegen kannst, dann kann der auch zu zwei Switche gehen. Aber es sind dann auch 2 IPs.
Sinnvoll ist das, wenn du 2 Switche in einen logischen/virtuellen Stack verwandelst, dann kann der LACP an beide Switche gehen.
So, ich hoffe das hilft dir weiter.
ricardo hat auch schon einiges geschrieben.
VG,
Deepsys
ich gehe jetzt mal davon aus, das du Nic-Teaming = LACP ist.
Zitat von @samet22:
1.) Wenn man Nic-Teaming am Server einstellt (beispielsweise mit 4 Interfaces). Bedeutet das ,dass ich 1 Leitung benutze und WENN ein Ausfall stattfindet eine andere einspringt?
Nein, es werden immer die 4 Leitungen benutzt; fällt eine aus, dann eben 31.) Wenn man Nic-Teaming am Server einstellt (beispielsweise mit 4 Interfaces). Bedeutet das ,dass ich 1 Leitung benutze und WENN ein Ausfall stattfindet eine andere einspringt?
ODER wenn ich am Switch keine Link-aggregation einstelle, sondern nur Nic-Teaming am Server habe ist dann die geschwindigkeit * 4?
Du musst es auf beiden Seiten einstellen!wie soll denn sonst der Switch wissen was er mit dem Datenhaufen machen soll. Es käme eh vorher keine Kommunikation zustande.
2.) Ist Link-Aggregation ein Trunk (LAG)? oder ist das beim Switch dann eine eigene Konfiguration? ... muss dann der Switch wahrscheinlich können?
Ja, es muss auf beiden Seiten eingestellt sein!3.) Falls dies der Switch kann ist es auch möglich zu sagen 4 Ports sind mit Link-Aggregation gebündelt aber 2 Lan-Kabel führen zu Swtich 1 und 2 Lan-Kabel führen zu Switch 2 wegen Ausfallsicherheit... beide Switche natürlich getrunkt...?
Jein.Wenn du den 4er Port in 2er Ports zerlegen kannst, dann kann der auch zu zwei Switche gehen. Aber es sind dann auch 2 IPs.
Sinnvoll ist das, wenn du 2 Switche in einen logischen/virtuellen Stack verwandelst, dann kann der LACP an beide Switche gehen.
So, ich hoffe das hilft dir weiter.
ricardo hat auch schon einiges geschrieben.
VG,
Deepsys
Vielen Dank für deine Antwort...
Ich habe gerade das Problem das ich ein Netzwerk übernommen habe, dort sind auf unserem Server 4 Interface unter Windows 2012 mit Nic-teaming gebündelt. Diese hängen auf einem Netgear switch, jedoch hat der Netgear Switch kein LACP/LAG auf den Ports konfiguriert... Wie wirkt sich das auf mein netzwerk aus? wie agiert nun der Server und der Switch?
Danke
lg Samet
Ich habe gerade das Problem das ich ein Netzwerk übernommen habe, dort sind auf unserem Server 4 Interface unter Windows 2012 mit Nic-teaming gebündelt. Diese hängen auf einem Netgear switch, jedoch hat der Netgear Switch kein LACP/LAG auf den Ports konfiguriert... Wie wirkt sich das auf mein netzwerk aus? wie agiert nun der Server und der Switch?
Danke
lg Samet
An für sich dürftest in diesem Fall gar keine Kommunikation über die Teaming Nic möglich sein.
Schau mal im "Manager für virtuelle Netwerke" ob das Team überhaupt einem Virtuellen Switch zugeordnet ist. Wenn nicht, musst du nur schauen ob die Nic ein deinem System irgend einem Dienst zugewiesen ist.
Ist das auch nicht der Fall, evtl mal zu einem Zeitpunkt an dem keine User arbeiten (nach Dienstschluss) die Nic deaktivieren (aber nicht löschen!!!).
Switch-Seitig dürft höchstens die Backplane-Leistung sinken, das der Switch damit beschäftigt ist die Packete zu untersuchen und zu verwerfen.
Das geht natürlich zu kosten der CPU Last, sollte aber keine Gravierenden Beeinträchtigungen haben.
Schau mal im "Manager für virtuelle Netwerke" ob das Team überhaupt einem Virtuellen Switch zugeordnet ist. Wenn nicht, musst du nur schauen ob die Nic ein deinem System irgend einem Dienst zugewiesen ist.
Ist das auch nicht der Fall, evtl mal zu einem Zeitpunkt an dem keine User arbeiten (nach Dienstschluss) die Nic deaktivieren (aber nicht löschen!!!).
Switch-Seitig dürft höchstens die Backplane-Leistung sinken, das der Switch damit beschäftigt ist die Packete zu untersuchen und zu verwerfen.
Das geht natürlich zu kosten der CPU Last, sollte aber keine Gravierenden Beeinträchtigungen haben.
Zitat von @-ricardo-:
An für sich dürftest in diesem Fall gar keine Kommunikation über die Teaming Nic möglich sein.
Schau mal im "Manager für virtuelle Netwerke" ob das Team überhaupt einem Virtuellen Switch zugeordnet ist. Wenn nicht, musst du nur schauen ob die Nic ein deinem System irgend einem Dienst zugewiesen ist.
Ist das auch nicht der Fall, evtl mal zu einem Zeitpunkt an dem keine User arbeiten (nach Dienstschluss) die Nic deaktivieren (aber nicht löschen!!!).
Switch-Seitig dürft höchstens die Backplane-Leistung sinken, das der Switch damit beschäftigt ist die Packete zu untersuchen und zu verwerfen.
Das geht natürlich zu kosten der CPU Last, sollte aber keine Gravierenden Beeinträchtigungen haben.
An für sich dürftest in diesem Fall gar keine Kommunikation über die Teaming Nic möglich sein.
Schau mal im "Manager für virtuelle Netwerke" ob das Team überhaupt einem Virtuellen Switch zugeordnet ist. Wenn nicht, musst du nur schauen ob die Nic ein deinem System irgend einem Dienst zugewiesen ist.
Ist das auch nicht der Fall, evtl mal zu einem Zeitpunkt an dem keine User arbeiten (nach Dienstschluss) die Nic deaktivieren (aber nicht löschen!!!).
Switch-Seitig dürft höchstens die Backplane-Leistung sinken, das der Switch damit beschäftigt ist die Packete zu untersuchen und zu verwerfen.
Das geht natürlich zu kosten der CPU Last, sollte aber keine Gravierenden Beeinträchtigungen haben.
Hallo,
Ich glaube jetzt weis ich warum LAG am Switch nicht eingestellt wurde. Dieses Nic-Team wird für Hyper-V benutzt und ist somit eigentlich am Virtuellen-Switch angesteckt. Trotzdem gehen aber 4 Kabeln vom Server zum Switch. Ich glaube das somit jeder Virtuelle-Server auf einem echten Port schlussendlich hängt... ansonst wäre hier nämlich auch LAG/LACP nötig... oder?
lg Samet
Klingt komisch :D Teaming zwischen virtuellen Switchen ist nonsens, habe auch noch nie getestet ob sowas geht.
Du kannst im Server-Manager nachschauen auf welchen Adapetern das Team genau hängt.. Das 4 Kabel raus gehen muss nichts heißen, es kann auch einfach nur aus dem Grund sein, dass jedem Server eine dedizierte Nic zugewiesen wurde, was auch in vielen Fällen sinnvoll ist.
Gruß
Richard
Du kannst im Server-Manager nachschauen auf welchen Adapetern das Team genau hängt.. Das 4 Kabel raus gehen muss nichts heißen, es kann auch einfach nur aus dem Grund sein, dass jedem Server eine dedizierte Nic zugewiesen wurde, was auch in vielen Fällen sinnvoll ist.
Gruß
Richard
Nur weil die 4 Kabel am Switch hängen, müssen die nicht im LAG sein.
Es kann ja auch jedes Kabel in einem eigenen VLAN hängen, oder die Ports sind deaktiviert oder sonstwie geschaltet ...
HyperV kann ich nicht helfen, haben wir nicht.
Es kann ja auch jedes Kabel in einem eigenen VLAN hängen, oder die Ports sind deaktiviert oder sonstwie geschaltet ...
HyperV kann ich nicht helfen, haben wir nicht.
Zitat von @Deepsys:
Nur weil die 4 Kabel am Switch hängen, müssen die nicht im LAG sein.
Es kann ja auch jedes Kabel in einem eigenen VLAN hängen, oder die Ports sind deaktiviert oder sonstwie geschaltet ...
HyperV kann ich nicht helfen, haben wir nicht.
Nur weil die 4 Kabel am Switch hängen, müssen die nicht im LAG sein.
Es kann ja auch jedes Kabel in einem eigenen VLAN hängen, oder die Ports sind deaktiviert oder sonstwie geschaltet ...
HyperV kann ich nicht helfen, haben wir nicht.
Komisches Forum hier ... wieso schreibt man etwas, mit dem Anhang "haben wir nicht, kann eh nicht helfen"... :D
1.)
Das kann man so machen (Failover) macht aber kein Mensch mehr da kontraproduktiv.
In der Regel bildet man immer einen Standard basierten 802.3ad basierten Trunk (Link Aggreagtion) mit LACP um nicht nur den Failover zu haben sondern auch die 4fach Bandbreite zu nutzen !
2.)
Es ist jeweils eine eigene Konfiguration auf Switch und Endgerät. Da die meist unterschiedliche Betriebssysteme haben liegt es auf der Hand das diese Konfig auch unterschiedlich ist.
Wichtig ist aber immer das Link Aggregation IMMER eine beidseitige Angelegenheit ist !
3.)
Das ist natürlich möglich und auch sehr sinnvoll ! (Siehe Punkt 1.)
Sehr vorsichtig musst du mit der Aufsplittung eines solchen 4er Trunks auf 2 Switches sein. Dabei sind sehr wichtige Punkte zu beachten:
Hast du Dummswitches die 1. oder 2. nicht supporten ist so eine Konstellation einen gesplitteten LAGs NICHT supportet und führt in eine Netzwerk Katastrofe (Looping).
Grundlagen dazu findest du hier:
Netzwerk Management Server mit Raspberry Pi
oder auch in folgendem Thread:
Symantec Backup Exec 2010 R3 - Netzwerk-Teaming für größeren Durschsatz
und den dort genannten anderen Threads.
Das kann man so machen (Failover) macht aber kein Mensch mehr da kontraproduktiv.
In der Regel bildet man immer einen Standard basierten 802.3ad basierten Trunk (Link Aggreagtion) mit LACP um nicht nur den Failover zu haben sondern auch die 4fach Bandbreite zu nutzen !
2.)
Es ist jeweils eine eigene Konfiguration auf Switch und Endgerät. Da die meist unterschiedliche Betriebssysteme haben liegt es auf der Hand das diese Konfig auch unterschiedlich ist.
Wichtig ist aber immer das Link Aggregation IMMER eine beidseitige Angelegenheit ist !
3.)
Das ist natürlich möglich und auch sehr sinnvoll ! (Siehe Punkt 1.)
Sehr vorsichtig musst du mit der Aufsplittung eines solchen 4er Trunks auf 2 Switches sein. Dabei sind sehr wichtige Punkte zu beachten:
- Generell ist das aus Failover Sicht sehr sinnvoll ! Klappt aber nur unter den folgenden technischen Voraussetzungen:
- 1.) Diese beiden Switches MÜSSEN Stack fähig sein also sich per Stacking in einen virtuellen physischen Switch verwandeln lassen.
- 2.) Beide Switches müssen über ein LACP Clustering Protokoll verfügen. Da gibt es keinen Standard und Hersteller haben unterschiedliche Implementationen die das ermöglichen wie z.B. Cisco = Virtual Port Channel, Brocade = MCT Multi Chassis Trunking usw.
Hast du Dummswitches die 1. oder 2. nicht supporten ist so eine Konstellation einen gesplitteten LAGs NICHT supportet und führt in eine Netzwerk Katastrofe (Looping).
Grundlagen dazu findest du hier:
Netzwerk Management Server mit Raspberry Pi
oder auch in folgendem Thread:
Symantec Backup Exec 2010 R3 - Netzwerk-Teaming für größeren Durschsatz
und den dort genannten anderen Threads.
VIELEN DANK! hat mir einen guten überblick gegeben!
