11
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?
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: 323149
Url: https://administrator.de/contentid/323149
Ausgedruckt am: 22.11.2024 um 09:11 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.
Ich habe zwei völlig unterschiedliche Trunks. Mit unterschiedlichen MAC-Adressen. Und ich adressiere die Freigabe von verschiedenden IPs, ich bin der Meindung, dass Netzwerkseitig genug Trennung ist, um je 1GB zu fahren?!
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 Thema hab ich auch lange verfolgt .
Ohne 10Gbit keine nennenswerten Performancesteigerungen . Hab mich auch lange damit rum geärgert zwecks Datensicherung .
Ohne 10Gbit keine nennenswerten Performancesteigerungen . Hab mich auch lange damit rum geärgert zwecks Datensicherung .
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 !
Danke für die vielen Antworten,
doch, 802.3ad habe ich verwenden (also LACP).
Ich bin einen Schritt weiter gegangen: ich habe die Trunks mal testweise aufgelöst und habe zwei NICs de servers und zwei Client-PCs an den Gigabit-Switch gehängt.
Ja, nun hätte ich erwartet (da das Plattensysstem sehr viel schneller liefern kann als nur 1GBit), dass ich
- mit Client A auf die IP der NIC1 zugreifen kann, mit 112MBps ziehen kann und gleichzeitig
- mit Client B auf die IP der NIC2 zugreifen und AUCH mit 112MBPs kopieren kann. Wie gesagt, komplett getrenne NICs, eine OnBoard, eine im PCI-E 4x nachgerüstet
Aber Pustekuchen, beide NICs teilen sich 1GBit. Und ich verstehe nicht mehr warum. Es ist doch jetzt ALLES .. .aber wirklich ALLES getrennt.
doch, 802.3ad habe ich verwenden (also LACP).
Ich bin einen Schritt weiter gegangen: ich habe die Trunks mal testweise aufgelöst und habe zwei NICs de servers und zwei Client-PCs an den Gigabit-Switch gehängt.
Ja, nun hätte ich erwartet (da das Plattensysstem sehr viel schneller liefern kann als nur 1GBit), dass ich
- mit Client A auf die IP der NIC1 zugreifen kann, mit 112MBps ziehen kann und gleichzeitig
- mit Client B auf die IP der NIC2 zugreifen und AUCH mit 112MBPs kopieren kann. Wie gesagt, komplett getrenne NICs, eine OnBoard, eine im PCI-E 4x nachgerüstet
Aber Pustekuchen, beide NICs teilen sich 1GBit. Und ich verstehe nicht mehr warum. Es ist doch jetzt ALLES .. .aber wirklich ALLES getrennt.
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.
Zitat von @aqui:
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.
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.
"Auf dem Gerät habe ich Linux installiert"
Einer meiner ersten Sätze.
Ich habe das Ganze inzwischen neu eingerichtet, habe alle 4 NICs zu einem Trunk (LACP Active nach 802.3ad) zusammengefasst und auch endlich verstanden, wie ich es hinbekomme, dass das ganze System einizig und allein nur die IP-Adresse des trunks hat. Seitdem kann ich 2x 1GBit/Sek. gleich zeitig runterziehen.
Vielen Dank für die vielen Tips, die nächste LAN-Party kann kommen ;)
Zitat von @aqui:
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 !
Ich wollte zu dem Zeitpunkt ja noch gar nicht teamen. Als Endlösung kommt Teaming aber in Frage, geht jetzt auch (siehe letzten Post) ;)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 !
Hört sich gut an ! Klasse wenn nun alles klappt wie es soll. 
