LAN-Bündelung

Hier nochmal ausführlicher und vermutlich exakter als in meiner Beschreibung:

https://www.windowspro.de/wolfgang-sommergut/nic-teaming-konfigurieren-w ...

Grüße, JD

Jep, funktioniert bei uns sehr gut. "Switchunabhänig" mit Lastenausgleichsmodus "Dynamisch".

Damit hältst du dir die Option offen, eine einzelne NIC auf einen Backup-Switch zu hängen (außer du hast sowieso schon was gestacktes als RZ-Switch...), und das ohne, dass du auf 1Gbps als "Cold Standby" verzichten müsstest.
Hab den Haupt-Switch auch mal Samstags im laufenden Betrieb ausgesteckt. Es gab keinerlei Ausfall, da die verlorenen Pakete eben sofort über die verbliebene aktive NIC am Backupswitch erneut gesendet werden, sodass der Client davon garnichts mitbekommt (außer, dass die Netzwerkperformance halt logischerweise deutlich niedriger ist).

Gruß, JD

Hi,
kleiner PRaxistipp, Beim Teaming immer gerade Zahlen also 2^x nutzen. Ein ehemaliger Kollege Berichtete mir schon von Problemen bei einer ungeraden Anzahl im Trunk.

Ich hab ein 2012er Hyper-V mit 4 NICS als LACP auf einem Switch laufen, ohne Probleme
Auch hier das Teaming über das OS im Servermanager.

Gruß

Kann ich allerdings nicht bestätigen. Bei uns sinds wie gesagt 7 von 8, also auch ungerade. Könnte ich mir technisch auch überhaupt nicht erklären, was daran Probleme machen sollte... Wie sahen die Probleme denn aus?

Grüße, JD

Klares Nein !
Das geht nur wenn du das Microsoft proprietäre Verfahren nutzt. Dann macht der allerdings bei Active/Active ein Mac Adress Nailing also verteilt die Mac Adressen starr auf die NICs.
Sollte man besser nicht machen sondern immer eine 802.3ad bzw. .ax Standard konforme Konfig verwenden. Idealerweis emit LACP.
Das musst du natürlich dann zwingend auf dem Switch auch konfigurieren. Einige Hersteller wie z.B. HP lassen ihre Switchports im Default im LACP Passive Mode laufen. Sie erkennen also automatisch ob dort ein Endgerät (Server, Switch etc.) mit LACP Active angeschlossen wird und bilden dann automatisch einen LAG (Trunk).
Ob man das gut finden muss ist eine andere Frage. (...und andere Baustelle)
Was auf normalen Switches auch niemals geht ist ein Splitting des LAGs auf unterschiedliche physische Switches. Das supportet der Standard NICHT.
Das geht nur in einem Full Stack bei stacking fähigen Switches oder bei Switches die eine LAG Virtualisierung supporten wie vPC ( Cisco), MCT (Brockade/Ruckus) usw. Das ist aber immer Hersteller proprietär da nicht standartisiert.
Eine weitere Ausnahme sind Fabric basierte Switches die mit einem TRILL oder SPB Backbone arbeiten. Die supporten das per Default. Sind aber vermutlich eh nicht in deinem Budget Rahmen.
Fazit: Sowie du auf eine externe Switch Infrastruktur gehst solltest du immer 802.3ad /ax bevorzugen wenns geht.
Siehe auch:
Netzwerk Management Server mit Raspberry Pi
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Nein ! Es wird ja nicht die Geschwindigkeit der einzelnen Links erhöht. Daten fliessen hier also immer nur mit 1Gig über die Leitung, denn die physische Geschwindigkeit der LAG Member bleibt ja logischerweise auf 1 Gig !
Es kommt nur zu einer Verteilung der Kapazität, das der LAG quasi so viel Endgeräte bedienen kann wie eine 4Gig Leitung.
In der Praxis wird das abe rnie erreicht, da durch das Hashing Verfahren (Verteilung auf den Links) keine vollständig homogene Verteilung erreicht wird. Durch die geringe Entropie kommt es zu einer meist schlechteren Verteilung. Das ist aber dem 802.3ad bzw. .ax Standard geschuldet der das so definiert.
Ausnahme auch hier wieder Fabric Switches mit TRILL oder SPB, die machen auf Trunks ein reines per Packet Round Robin Verfahren ohne Hashing und eine genaue Aufteilung auf die Links.

Das stimmt so nicht ganz. Zumindest seit Server 2012 R2 nicht mehr. Seit dem gibt es nämlich den dynamischen Modus für den Lastenausgleich.

Zitat aus dem windowspro.de-Link über diesen Modus:

Dynamisch: Diese mit Windows Server 2012 R2 eingeführte Option kombiniert die beiden oben erwähnten Verfahren, indem ausgehender Traffic nach der Adresshash-Methode über die NICs verteilt wird. Dabei ist der dynamische Ansatz in der Lage, ausgehende Daten in Echtzeit zwischen den Adaptern verteilt. Eingehende Ströme werden nach dem Muster von Hyper-V-Port zwischen den Team-Mitgliedern ausbalanciert. Die dynamische Methode bietet im Allgemeinen die beste Performance, wenn man den Switch-unabhängigen Modus gewählt hat.

Ich kann aus Erfahrung sagen, dass die Switchunabhängige Methode, ohne LACP-Konfiguration am Switch und verteilt über zwei Switche (wie oben beschrieben) sehr gut funktioniert. Wo siehst du da den Nachteil/das Risiko/den Vorteil von LACP?

Grüße, JD

EDIT: Die Modi "Switchunabhänig" und "Dynamisch" sind in dieser Kombination wohl auch von Microsoft empfohlenes best practice. Siehe: https://docs.microsoft.com/en-us/windows-server/networking/technologies/ ...

Es ist aber eine starre Verteilung. Wie sollte sonst ein Layer 2 Switch der sich nur rein anhand der Mac Adressen orientieren kann damit umgehen ? Gerade wenn auch ein Vewrteilen auf unterschiedliche physische Switches (sogar auch ungemanagte) damit supportet ist ? Der Switch darf dann an dem LAG Port immer nur die eine NIC Mac Adresse "sehen". Das darf sich niemals ändern, denn sonst würde ja im Layer 2 die Mac Adresse an einzelnen Switches doppelt in der Mac Tabelle auftauchen, was fatal wäre für das Netz.
Das ist dann aber ein proprietäres MS Vewrfahren was auch und nur auf einem Adress Hash basiert. Das gesamte Mac Handling obliegt dann dem NIC Treiber.
Das ist auch von MS sicher so gewollt, da viele Sewrver Administratoren wenig bis keine Netzwerk Kenntisse haben und ein Fehler hier fatale Folgen für die Stabilität des netze hätte (Loops usw.).
Da macht es natürlich Sinn einen DAU festen Modus zu finden auch für ungemanagte Switches. In kleinen Netzen ist das sicher auch kein Thema. Da dürfte es ziemlich egal sein was man macht. Ob Standard oder MS verfahren hat dort sicher nur geringe bis keine Unterschiede und das MS Verfahren ist in der Beziehung sicherer, da eine falsche Konfig und Netzwerk Chaos so gut wie fast ausgeschlossen ist
Ob man mit einer proprietären Lösung leben will muss jeder für sich entscheiden. Meist zählt ja nur das Ergebnis in kelinen Designs.
LACP hat den Vorteil das der LAG nicht ausfällt wenn einzelne Memeber ausfallen und recovered sich selber wenn sie wieder online sind.

Okay, verstanden. Deine Zweifel beziehen sich also nicht auf die grundsätzliche Funktionalität, sondern darauf, dass man anstatt auf ein dezidiertes Netzwerkprotokoll eben auf den Microsoft-Treiber vertraut.
Meine Erfahrung zeigt, dass es in unserer kleinen IT-Umgebung (3 Hyper-V-Server, 15 VMs) bisher ohne jegliche Probleme funktioniert. Plus: Es hat den Vorteil, dass man sehr einfach eine aktive Backup-Konfiguration realisieren kann.

Das wiederum kapier ich nicht ganz. Wenn ich z.B. den Stecker einer einzelnen NIC abziehe, dann funktioniert die LAG in meiner Konfiguration auch noch, das hab ich mehrfach getestet. Es kann, wie bereits erwähnt, auch der ganze Switch ausfallen wenn nur eine NIC am Backupswitch hängt...