LACP-Trunking 2x 1GBit scheint nicht zu funktionieren (1GBit wird nicht überschritten)
Hallo Gemeinde,
ich habe hier einen HP Server mit zwei unterschiedlichen und schnellen Platten-RAIDs.
Auf dem Gerät habe ich Linux installiert und mit einer zweiten Dual-NIX insgesamt 4 NIC-Ports.
Nun habe ich zwei Funktionen auf diesem Server eingetrichtet und zwei Trunks erstellt.:
Trunk 1
OnBoard NIC 1 und 2
Trunk Adresse: 192.168.233.11
Onboard NICs: beziehen weiter hin via DHCP eine Adresse (ist das richtig so?)
Trunk 2
PCI-E 4x Dual Head NIC Port 1 und 2
Trunk Adresse: 192.168.233.3
PCI-E NICs: beziehen weiter hin via DHCP eine Adresse (ist das richtig so?)
Weil ich weiß, dass ein 2x 1 GBit Trunk nicht gleich 2GBit an einen Client überträgt (in einer single TCP Session) habe ich zwei Test-PCs aufgebaut. Beide haben SSDs und ziehen alleine 112MB/s vom Server (Samba Share).
Der Server ist an einem HP 1810 Switch angeschlossen und die beiden Trunks sind am Switch auch konfiguriert. Als Protokoll kommt an beiden Enden LACP zum Einsatz.
Server und Switch zeigen Trunk Status (und Einzel-NICs) als "up" an.
Nach meinem Verständnis müsste ich in der Lage sein von PC 1 und PC2 gleichzeitig auf das SMB share auf 192.168.233.3 zuzugreifen und mit ~112MB/s ziehen. Das klappt aber nur mit einem. Zieht der Zweite gleichzeitig, droppt der Traffic auf exakt die Hälfte.
Gegenprobe: Client B greift auf SMB Share auf 192.168.233.11 zu und Client B auf 192.168.233.3. DENNCH halbiert sich pro Übertragung die Leistung.
Ist da noch im SMB-Konfig etwas einzustellen? Eine System- oder Netzwerkeinstellung, die ich nicht sehe?
Kann jemand helfen?
ich habe hier einen HP Server mit zwei unterschiedlichen und schnellen Platten-RAIDs.
Auf dem Gerät habe ich Linux installiert und mit einer zweiten Dual-NIX insgesamt 4 NIC-Ports.
Nun habe ich zwei Funktionen auf diesem Server eingetrichtet und zwei Trunks erstellt.:
Trunk 1
OnBoard NIC 1 und 2
Trunk Adresse: 192.168.233.11
Onboard NICs: beziehen weiter hin via DHCP eine Adresse (ist das richtig so?)
Trunk 2
PCI-E 4x Dual Head NIC Port 1 und 2
Trunk Adresse: 192.168.233.3
PCI-E NICs: beziehen weiter hin via DHCP eine Adresse (ist das richtig so?)
Weil ich weiß, dass ein 2x 1 GBit Trunk nicht gleich 2GBit an einen Client überträgt (in einer single TCP Session) habe ich zwei Test-PCs aufgebaut. Beide haben SSDs und ziehen alleine 112MB/s vom Server (Samba Share).
Der Server ist an einem HP 1810 Switch angeschlossen und die beiden Trunks sind am Switch auch konfiguriert. Als Protokoll kommt an beiden Enden LACP zum Einsatz.
Server und Switch zeigen Trunk Status (und Einzel-NICs) als "up" an.
Nach meinem Verständnis müsste ich in der Lage sein von PC 1 und PC2 gleichzeitig auf das SMB share auf 192.168.233.3 zuzugreifen und mit ~112MB/s ziehen. Das klappt aber nur mit einem. Zieht der Zweite gleichzeitig, droppt der Traffic auf exakt die Hälfte.
Gegenprobe: Client B greift auf SMB Share auf 192.168.233.11 zu und Client B auf 192.168.233.3. DENNCH halbiert sich pro Übertragung die Leistung.
Ist da noch im SMB-Konfig etwas einzustellen? Eine System- oder Netzwerkeinstellung, die ich nicht sehe?
Kann jemand helfen?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 323149
Url: https://administrator.de/forum/lacp-trunking-2x-1gbit-scheint-nicht-zu-funktionieren-1gbit-wird-nicht-ueberschritten-323149.html
Ausgedruckt am: 23.12.2024 um 02:12 Uhr
11 Kommentare
Neuester Kommentar
LACP verteilt den Traffic auf die verschiedenen Wege und nutzt einen Hash der MAC-Adresse, um den Weg auszusuchen. Daher ist dein beschriebenes Verhalten nicht unüblich. Es erfolgt keine Verteilung anhand der Linknutzung oder nach dem Round-Robin-Verfahren.
Des Weiteren nutzen die meisten Betriebssysteme, u.a. Linux, wenn mehrere Schnittstellen im gleichen IP-Netz sind, nur eine Netzwerkkarte für gesendeten Traffic.
Des Weiteren nutzen die meisten Betriebssysteme, u.a. Linux, wenn mehrere Schnittstellen im gleichen IP-Netz sind, nur eine Netzwerkkarte für gesendeten Traffic.
Hallo zusammen,
und was möchtest Du jetzt von uns hören? Oder wie soll sich denn der PC1 und der PC2
nun verhalten? Ich würde mal sagen Du erwartest ~112 MB/s auf beiden Leitungen, oder?
Sind denn auch immer beide Leitungen in Gebrauch?
Gruß
Dobby
und was möchtest Du jetzt von uns hören? Oder wie soll sich denn der PC1 und der PC2
nun verhalten? Ich würde mal sagen Du erwartest ~112 MB/s auf beiden Leitungen, oder?
Sind denn auch immer beide Leitungen in Gebrauch?
Gruß
Dobby
Ich hab das alles mal mit einer Synology DS414, einer SSD die 512 MB/Sec schafft und einem Netgear GS108T durchgeckeckt. Das ist eine Kombination aus NAS und Switch, die diese Fähigkeit prinzipiell mitbringt.
Das einzige OS, das überhaupt LACP parallel auf beiden Leitungen unterstütz sind aktuelle Mac-OS Versionen. Getestet mit einem Mac PRo, und da nur Mac Pro auch 2 oder 3 Ethernet Ports haben, komen nur MAc Pro Besitzer - wenn überhaupt - in Genuß dieser Datentransferraten. Weil nur im MacOSX die Link-Aggregation auch tatsächlich im Parallelbetrieb läuft. Windows und alle anderen OS beschickten eine Link aggregation abwechselnd mit Datenpaketen, aber nicht gleichzeitig auf beiden Leitungen.
VMware kann es bis ESX 6.0 nicht, HyperV als Host kann es nicht bis hin zu Windows 2012 R2 und folglich auch alle Guest-OS in VMs jener Virtualisierungen, der iSCSI Client von den Server-Versionen aller Microsoft-OS kann es nicht, Windows 7 bis 10 auch nicht. Stets kam der MAximalwert von 120 MB/Sec raus. Auch Citrix Xenserver briachte da keine anderen Resultate.
Da man im Profi-Bereich heute ohnehin auf 10 Gbit oder mehr ist ist das auch eine rein akademische Frage, wie man mit LACP im Heimbereich die 1 GBit-Marke knackt. Und es muß auch das Raid im NAS schnell genug sein. Die DS414 schafft im Raid5 Modus nur ca. 95 MB/Sec beim Lesenund Schreiben, schneller (also Datentransferrater einer Platte x2) tut sie das nur im Raid 10 Betrieb.
Das einzige OS, das überhaupt LACP parallel auf beiden Leitungen unterstütz sind aktuelle Mac-OS Versionen. Getestet mit einem Mac PRo, und da nur Mac Pro auch 2 oder 3 Ethernet Ports haben, komen nur MAc Pro Besitzer - wenn überhaupt - in Genuß dieser Datentransferraten. Weil nur im MacOSX die Link-Aggregation auch tatsächlich im Parallelbetrieb läuft. Windows und alle anderen OS beschickten eine Link aggregation abwechselnd mit Datenpaketen, aber nicht gleichzeitig auf beiden Leitungen.
VMware kann es bis ESX 6.0 nicht, HyperV als Host kann es nicht bis hin zu Windows 2012 R2 und folglich auch alle Guest-OS in VMs jener Virtualisierungen, der iSCSI Client von den Server-Versionen aller Microsoft-OS kann es nicht, Windows 7 bis 10 auch nicht. Stets kam der MAximalwert von 120 MB/Sec raus. Auch Citrix Xenserver briachte da keine anderen Resultate.
Da man im Profi-Bereich heute ohnehin auf 10 Gbit oder mehr ist ist das auch eine rein akademische Frage, wie man mit LACP im Heimbereich die 1 GBit-Marke knackt. Und es muß auch das Raid im NAS schnell genug sein. Die DS414 schafft im Raid5 Modus nur ca. 95 MB/Sec beim Lesenund Schreiben, schneller (also Datentransferrater einer Platte x2) tut sie das nur im Raid 10 Betrieb.
Das hatten wir hier grad gestern....
Windows Server 2012 R2 NIC Teaming mit Lancom Switch
Fehler der gemacht wird und vermutlich auch bei dir das du auf der Serverseite kein Teaming bzw. Link Aggregation nach dem 802.3ad Standard mit LACP gemacht hast.
Dann erkennt der Switch (der nur das kann !) den LAG nicht und kann keinen Trunk formen !
Kontrolliere das und dann kommt das auch sofort zum Fliegen !
Windows Server 2012 R2 NIC Teaming mit Lancom Switch
Fehler der gemacht wird und vermutlich auch bei dir das du auf der Serverseite kein Teaming bzw. Link Aggregation nach dem 802.3ad Standard mit LACP gemacht hast.
Dann erkennt der Switch (der nur das kann !) den LAG nicht und kann keinen Trunk formen !
Kontrolliere das und dann kommt das auch sofort zum Fliegen !
802.3ad habe ich verwenden (also LACP).
Wieso "also" LACP ?!Nicht das du hier was verwechselst !! 802.3ad Trunking bzw. Load Sharing hat rein gar nichts mit LACP zu tun ! 2 unterschiedliche Baustellen.
LACP sorgt lediglich dafür das die Trunk Gruppen über die physischen Links automatisch geformt werden. Den eigentlichen Balancing Algorithmus bestimmt der 802.3ad Standard.
Den aktuellen Treiber des Chipsatz Herstellers verwendest du ??? Niemals den Windows embeddeten verwenden !
In der Regel funktioniert das Trunking unter Windows aber fehlerfrei. Wichtig wie gesagt nur den richtigen Teaming Modus muss man auswählen.