18
LAG kommt nicht über 1Gbit
Servus;
Ich habe ein LAG aus 4x 1 Gbit Ports und egal was ich mache, er kommt nicht über 1 Gbit.
Aufbau:
Server 2022 auf einem uralt IBM x3450 M4, auf dem läuft Veeam und der backupt die Hyper-V Server.
An dem hab ich ein Team angelegt.
Im Status des Adapter steht auch 4 Gbit.
Der Server ist an einem Cisco CBS350-48P-4X wo ich Link Aggregation eingerichtet mit LACP.
Dieser Switch ist mit einem weiteren Cisco CBS350-48P-4X per 10 Gbit LWL angebunden.
Dort hab ich genauso Link Aggregation eingerichtet.
An diesem hängt dann das NAS, QNAP TS-853A, wo ein Teil der Backups landet.
Dort ist ebenfalls Port Bündelung eingerichtet.
Wenn ich jetzt vom Server auf das NAS bzw umgekehrt ein großes File per SMB kopiere, komme ich nicht über 1 Gbit hinweg (~980 Mbit).
Auf dem Server ist ein RAID 5 mit 4x 2,5" 10k SCSI Platten, auf dem NAS ein RAID 5 mit "normalen" 7,2k 3,5" HDDs.
Dass die Storages zu langsam sind kann ich ausschließen, zum einen weil es genau bei 1 Gbit ansteht, zum anderen wenn ich eine Datei vom Storage auf das selbige kopiere, komme ich weit über 200 MB/s.
Alle Ports sind UP und in den Switches sind in den Logs keine Auffälligkeiten.
Der Text ist leider etwas lang geworden, ich hoffe es ist halbwegs verständlich.
Also, hat wer eine Idee dazu?
Zusatz:
Ganz vergessen zu erwähnen, mit iperf vom Server zum NAS und umgekehrt hab ich mich auch schon gespielt. Natürlich mit mehreren Verbindungen.
Ich habe ein LAG aus 4x 1 Gbit Ports und egal was ich mache, er kommt nicht über 1 Gbit.
Aufbau:
Server 2022 auf einem uralt IBM x3450 M4, auf dem läuft Veeam und der backupt die Hyper-V Server.
An dem hab ich ein Team angelegt.
Im Status des Adapter steht auch 4 Gbit.
Der Server ist an einem Cisco CBS350-48P-4X wo ich Link Aggregation eingerichtet mit LACP.
Dieser Switch ist mit einem weiteren Cisco CBS350-48P-4X per 10 Gbit LWL angebunden.
Dort hab ich genauso Link Aggregation eingerichtet.
An diesem hängt dann das NAS, QNAP TS-853A, wo ein Teil der Backups landet.
Dort ist ebenfalls Port Bündelung eingerichtet.
Wenn ich jetzt vom Server auf das NAS bzw umgekehrt ein großes File per SMB kopiere, komme ich nicht über 1 Gbit hinweg (~980 Mbit).
Auf dem Server ist ein RAID 5 mit 4x 2,5" 10k SCSI Platten, auf dem NAS ein RAID 5 mit "normalen" 7,2k 3,5" HDDs.
Dass die Storages zu langsam sind kann ich ausschließen, zum einen weil es genau bei 1 Gbit ansteht, zum anderen wenn ich eine Datei vom Storage auf das selbige kopiere, komme ich weit über 200 MB/s.
Alle Ports sind UP und in den Switches sind in den Logs keine Auffälligkeiten.
Der Text ist leider etwas lang geworden, ich hoffe es ist halbwegs verständlich.
Also, hat wer eine Idee dazu?
Zusatz:
Ganz vergessen zu erwähnen, mit iperf vom Server zum NAS und umgekehrt hab ich mich auch schon gespielt. Natürlich mit mehreren Verbindungen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3443725423
Url: https://administrator.de/contentid/3443725423
Printed on: April 27, 2024 at 19:04 o'clock
18 Comments
Latest comment
Moin,
working as indended... Eine TCP-Session im LAG kann sich nicht über mehrere physische Links ausdehnen.
lg,
Slainte
working as indended... Eine TCP-Session im LAG kann sich nicht über mehrere physische Links ausdehnen.
lg,
Slainte
2
Mahlzeit.
Das LAG erhöht nicht den Durchsatz, sondern stellt mehr Bandbreite zur Verfügung, um Lastverteilung zu erreichen.
Selbst wenn du vier 10 GBit/s bündelst und 40 GBit/s angezeigt bekommst kann trotzdem maximal mit 10 GBit/s in Richtung des Ziels gelesen / geschrieben werden.
EDIT:
Super Artikel von @aqui dazu:
Link Aggregation (LAG) im Netzwerk
Gruß
Marc
Das LAG erhöht nicht den Durchsatz, sondern stellt mehr Bandbreite zur Verfügung, um Lastverteilung zu erreichen.
Selbst wenn du vier 10 GBit/s bündelst und 40 GBit/s angezeigt bekommst kann trotzdem maximal mit 10 GBit/s in Richtung des Ziels gelesen / geschrieben werden.
EDIT:
Super Artikel von @aqui dazu:
Link Aggregation (LAG) im Netzwerk
Gruß
Marc
2
Ist doch normal, ein LAG kann niemals die Geschwindigkeit eines Einzelinks übersteigen sondern erhöht nur die Kapazität für mehrere Clients/Verbindungen die auf die Links verteilt werden, da hast du offensichtlich das Prinzip LAG nicht ganz verstanden 
...
Gruß Katrin
...Gruß Katrin
Wenn der "Lastausgleich" anhand der Quell-MAC oder Quell-IP vertielt, it offensichtlich klar, dass kein einzelner Node über 1GBit kommt.
Aber auch die anderen LAstausgleichs Konfigurationen nehmen nur einen der Links (man korrigiere mich, wenn es jemand besser weiss).
https://en.wikipedia.org/wiki/Link_aggregation
Aber auch die anderen LAstausgleichs Konfigurationen nehmen nur einen der Links (man korrigiere mich, wenn es jemand besser weiss).
https://en.wikipedia.org/wiki/Link_aggregation
Zitat von @SlainteMhath:
Moin,
working as indended... Eine TCP-Session im LAG kann sich nicht über mehrere physische Links ausdehnen.
lg,
Slainte
Moin,
working as indended... Eine TCP-Session im LAG kann sich nicht über mehrere physische Links ausdehnen.
lg,
Slainte
Weiß ich, aber sind nicht mehrere Kopiervorgänge, mehrere TCP-Sessions?
Zitat von @radiogugu:
Mahlzeit.
Das LAG erhöht nicht den Durchsatz, sondern stellt mehr Bandbreite zur Verfügung, um Lastverteilung zu erreichen.
Selbst wenn du vier 10 GBit/s bündelst und 40 GBit/s angezeigt bekommst kann trotzdem maximal mit 10 GBit/s in Richtung des Ziels gelesen / geschrieben werden.
EDIT:
Super Artikel von @aqui dazu:
Link Aggregation (LAG) im Netzwerk
Gruß
Marc
Mahlzeit.
Das LAG erhöht nicht den Durchsatz, sondern stellt mehr Bandbreite zur Verfügung, um Lastverteilung zu erreichen.
Selbst wenn du vier 10 GBit/s bündelst und 40 GBit/s angezeigt bekommst kann trotzdem maximal mit 10 GBit/s in Richtung des Ziels gelesen / geschrieben werden.
EDIT:
Super Artikel von @aqui dazu:
Link Aggregation (LAG) im Netzwerk
Gruß
Marc
Weiß ich.
Zitat von @8030021182:
Ist doch normal, ein LAG erhöht niemals die Geschwindigkeit sondern erhöht nur die Kapazität für mehrere Clients/Verbindungen, da hast du offensichtlich was nicht ganz verstanden ...
Gruß Katrin
Ist doch normal, ein LAG erhöht niemals die Geschwindigkeit sondern erhöht nur die Kapazität für mehrere Clients/Verbindungen, da hast du offensichtlich was nicht ganz verstanden
...Gruß Katrin
Ich hab ja mehrere Verbindungen.
Zitat von @ITwissen:
Wenn der "Lastausgleich" anhand der Quell-MAC oder Quell-IP vertielt, it offensichtlich klar, dass kein einzelner Node über 1GBit kommt.
Aber auch die anderen LAstausgleichs Konfigurationen nehmen nur einen der Links (man korrigiere mich, wenn es jemand besser weiss).
https://en.wikipedia.org/wiki/Link_aggregation
Wenn der "Lastausgleich" anhand der Quell-MAC oder Quell-IP vertielt, it offensichtlich klar, dass kein einzelner Node über 1GBit kommt.
Aber auch die anderen LAstausgleichs Konfigurationen nehmen nur einen der Links (man korrigiere mich, wenn es jemand besser weiss).
https://en.wikipedia.org/wiki/Link_aggregation
Das ist mir alles bewusst, ich dachte allerdings wenn ich mehrere "Kopiervorgänge" starte dass das mehrere TCP Sessions sind und daher ich sehr wohl über 1Gbit komme.
er kommt nicht über 1 Gbit.
Dann hast du vermutlich die technischen Grundlagen eines LACP LAGs nach 802.3ad nicht richtig verstanden mit dem Hashing Verfahren, kann das sein?Link Aggregation (LAG) im Netzwerk
Lesen und verstehen! 🧐
Nochmal in Kurzform: Es ist ein Hashing Verfahren was je nach Adress Entropie im Netzwerk die Partner auf die Memberlinks verteilt. Ein Kommunikationspärchen nutzt als je nach Hashing Granularität immer nur einen festen Memberport und kann niemals mehr Geschwindigkeit haben als ein einzelner Memberport. Logisch...
Es ist lediglich ein Verteilungsverfahren was die Endgeräte auf die memberports verteilt und so zur Entlastung eines einzelnen Links führt. Wie die Verteilung geschieht hängt vond er Güte und featureset deines Switches ab. Billigteile machen das lediglich nur auf Mac Adressbasis bessere nehmen auch noch die IP Adresse, den TCP/UDP Port und die VLAN ID hinzu. Desto mehr Parameter, desto besser die Granularität bei der Verteilung. Einfache und banale Logik und hätte den Thread obsolet gemacht wenn du den RFC gelesen hättest... 😉
wenn ich mehrere "Kopiervorgänge" starte dass das mehrere TCP Sessions sind und daher ich sehr wohl über 1Gbit komme.
Nein und auch wenn ändert das ja rein gar nichts an den Parametern die den Hash berechnen!! Je nachdem auf was du für die Hashberechnung eingestellt hast?!
1Zitat von @aqui:
er kommt nicht über 1 Gbit.
Dann hast du vermutlich die technischen Grundlagen eines LACP LAGs nach 802.3ad nicht richtig verstanden mit dem Hashing Verfahren, kann das sein?Jo, scheint so.
Link Aggregation (LAG) im Netzwerk
Lesen und verstehen! 🧐
Nochmal in Kurzform: Es ist ein Hashing Verfahren was je nach Adress Entropie im Netzwerk die Partner auf die Memberlinks verteilt. Ein Kommunikationspärchen nutzt als je nach Hashing Granularität immer nur einen festen Memberport und kann niemals mehr Geschwindigkeit haben als ein einzelner Memberport. Logisch...
Es ist lediglich ein Verteilungsverfahren was die Endgeräte auf die memberports verteilt und so zur Entlastung eines einzelnen Links führt. Wie die Verteilung geschieht hängt vond er Güte und featureset deines Switches ab. Billigteile machen das lediglich nur auf Mac Adressbasis bessere nehmen auch noch die IP Adresse, den TCP/UDP Port und die VLAN ID hinzu. Desto mehr Parameter, desto besser die Granularität bei der Verteilung. Einfache und banale Logik und hätte den Thread obsolet gemacht wenn du den RFC gelesen hättest... 😉
Lesen und verstehen! 🧐
Nochmal in Kurzform: Es ist ein Hashing Verfahren was je nach Adress Entropie im Netzwerk die Partner auf die Memberlinks verteilt. Ein Kommunikationspärchen nutzt als je nach Hashing Granularität immer nur einen festen Memberport und kann niemals mehr Geschwindigkeit haben als ein einzelner Memberport. Logisch...
Es ist lediglich ein Verteilungsverfahren was die Endgeräte auf die memberports verteilt und so zur Entlastung eines einzelnen Links führt. Wie die Verteilung geschieht hängt vond er Güte und featureset deines Switches ab. Billigteile machen das lediglich nur auf Mac Adressbasis bessere nehmen auch noch die IP Adresse, den TCP/UDP Port und die VLAN ID hinzu. Desto mehr Parameter, desto besser die Granularität bei der Verteilung. Einfache und banale Logik und hätte den Thread obsolet gemacht wenn du den RFC gelesen hättest... 😉
Mir war bewusst, dass eine einzelne Verbindung auch nur 1 Gbit schaffen wird.
Aber wenn ich mehrere starte, war ich der Meinung dass es eben aufgeteilt wird und ich dann in Summe über 1 Gbit komme.
Aber wenn ich mehrere starte, war ich der Meinung dass es eben aufgeteilt wird
Wie denn wenn du die Parameter der Hashberechnung nicht änderst bzw. ändern kannst?Dann bleibt der physische Memberlink doch immer gleich weil der Hashwert gleich bleibt. Mit einer weiteren Session änderst du ja weder Mac Adresse noch IP Adresse und der CBS kann als einfacher Switch nicht den TCP/UDP Port und die VLAN ID zur Hash Berechnung verwenden weil er das nicht supportet. Folglich kann mit einem neuen oder anderen TCP Port der Hash sich nicht ändern. Einfache Logik
wenn ich mehrere "Kopiervorgänge" starte dass das mehrere TCP Sessions sind und daher ich sehr wohl über 1Gbit komme.
Nein und auch wenn ändert das ja rein gar nichts an den Parametern die den Hash berechnen!! Je nachdem auf was du für die Hashberechnung eingestellt hast?!Hab ich natürlich so gemacht, Den Guide von dir kenn ich auch, deswegen war ich mir auch sicher dass ich alles richtig eingestellt habe.
Zitat von @aqui:
Aber wenn ich mehrere starte, war ich der Meinung dass es eben aufgeteilt wird
Wie denn wenn du die Parameter der Hashberechnung nicht änderst. Dann bleibt der physische Memberlink doch immer gleich weil der Hashwert gleich bleibt. Mit einer weiteren Session änderst du ja weder Mac Adresse noch IP Adresse und der CBS kann als einfacher Switch nicht den TCP/UDP Port und die VLAN ID zu Berechnung verwenden weil er das nicht supportet. Einfache LogikHm, habe scheinbar das Ganze Thema falsch verstanden.
Das hast du ja auch, keine Frage. Aber eine neue oder zusätzliche TCP Session ändert halt nix an der Hashberechnung weil der Switch nur Mac und IP kann und die ändern sich ja eben nicht. 
Hm, habe scheinbar das Ganze Thema falsch verstanden.
Das wirds wohl sein, obwohl die Hash Berechnung im Tutorial explizit erklärt wird! 🤔
Hast du das Teaming im Server Manager erstellt? Es sieht so aus auf dem Bild.
Das dürfte doch gar nicht mehr funktionieren:
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
Das dürfte doch gar nicht mehr funktionieren:
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
Moin @Freak-On-Silicon,
als ja, mehrere Kopiervorgänge können durchaus mehrere Sessions öffnen, aber, diese lassen sich nicht über einen LACP-Trunk verteilen, weil sie immer von derselben IP/MAC kommen.
Die einzige Möglichkeit die ich sehe, wie du über diese Konstellation an die 4GBit rankommst, ist SMB-Multichannel.
Der Windows Server kann es auf jeden Fall, ob es auch dein NAS unterstütz, musst du selber kurz prüfen.
Wenn du SMB-Multichannel jedoch nutzen möchtest, dann musst du die LACP Trunks auf der Server und der NAS Seite auflösen und die 4 NIC's je separat konfigurieren. Dabei muss jede NIC in ein eigenes Subnet, sonst funktioniert der SMB-Multichannel Spass nicht so wirklich.
Beispiel.
Server NIC 1 - 192.168.1.10/24 <--> NAS NIC 1 - 192.168.1.20/24 (VLAN 10)
Server NIC 2 - 192.168.2.10/24 <--> NAS NIC 2 - 192.168.2.20/24 (VLAN 11)
Server NIC 3 - 192.168.3.10/24 <--> NAS NIC 1 - 192.168.3.20/24 (VLAN 12)
Server NIC 4 - 192.168.4.10/24 <--> NAS NIC 2 - 192.168.4.20/24 (VLAN 13)
Die V-LAN's sind beim diesem Thema eigentlich nicht notwendig, ich finde es jedoch sauberer, wenn unterschiedliche IP Bereiche auch über unterschiedliche "logische" Netze und nicht im selben laufen.
Gruss Alex
Das ist mir alles bewusst, ich dachte allerdings wenn ich mehrere "Kopiervorgänge" starte dass das mehrere TCP Sessions sind und daher ich sehr wohl über 1Gbit komme.
als ja, mehrere Kopiervorgänge können durchaus mehrere Sessions öffnen, aber, diese lassen sich nicht über einen LACP-Trunk verteilen, weil sie immer von derselben IP/MAC kommen.
Die einzige Möglichkeit die ich sehe, wie du über diese Konstellation an die 4GBit rankommst, ist SMB-Multichannel.
Der Windows Server kann es auf jeden Fall, ob es auch dein NAS unterstütz, musst du selber kurz prüfen.
Wenn du SMB-Multichannel jedoch nutzen möchtest, dann musst du die LACP Trunks auf der Server und der NAS Seite auflösen und die 4 NIC's je separat konfigurieren. Dabei muss jede NIC in ein eigenes Subnet, sonst funktioniert der SMB-Multichannel Spass nicht so wirklich.
Beispiel.
Server NIC 1 - 192.168.1.10/24 <--> NAS NIC 1 - 192.168.1.20/24 (VLAN 10)
Server NIC 2 - 192.168.2.10/24 <--> NAS NIC 2 - 192.168.2.20/24 (VLAN 11)
Server NIC 3 - 192.168.3.10/24 <--> NAS NIC 1 - 192.168.3.20/24 (VLAN 12)
Server NIC 4 - 192.168.4.10/24 <--> NAS NIC 2 - 192.168.4.20/24 (VLAN 13)
Die V-LAN's sind beim diesem Thema eigentlich nicht notwendig, ich finde es jedoch sauberer, wenn unterschiedliche IP Bereiche auch über unterschiedliche "logische" Netze und nicht im selben laufen.
Gruss Alex
1
Moin @NordicMike,
das LBFO funktioniert auch weiterhin, solange du es nicht für Hyper-V verwenden möchtest und auch dort funktioniert es selbst beim Server 2022, mit einem kleinen Trick auch noch.
Ich kann was Hyper-V angeht, jedoch weder LBFO noch SET empfehlen, vor allem wenn man Schnickschnack wie VMQ oder SRIOV wirklich benutzen möchte.
Gruss Alex
Das dürfte doch gar nicht mehr funktionieren:
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
das LBFO funktioniert auch weiterhin, solange du es nicht für Hyper-V verwenden möchtest und auch dort funktioniert es selbst beim Server 2022, mit einem kleinen Trick auch noch.
Ich kann was Hyper-V angeht, jedoch weder LBFO noch SET empfehlen, vor allem wenn man Schnickschnack wie VMQ oder SRIOV wirklich benutzen möchte.
Gruss Alex
Zitat von @NordicMike:
Hast du das Teaming im Server Manager erstellt? Es sieht so aus auf dem Bild.
Das dürfte doch gar nicht mehr funktionieren:
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
Hast du das Teaming im Server Manager erstellt? Es sieht so aus auf dem Bild.
Das dürfte doch gar nicht mehr funktionieren:
https://hifish.ch/2022/11/26/hyper-v-switch-mit-embedded-teaming-set-ers ...
Ja, hab ich.
Und ja, hat mich anfangs auch verwundert.
Zitat von @MysticFoxDE:
Moin @Freak-On-Silicon,
als ja, mehrere Kopiervorgänge können durchaus mehrere Sessions öffnen, aber, diese lassen sich nicht über einen LACP-Trunk verteilen, weil sie immer von derselben IP/MAC kommen.
Die einzige Möglichkeit die ich sehe, wie du über diese Konstellation an die 4GBit rankommst, ist SMB-Multichannel.
Der Windows Server kann es auf jeden Fall, ob es auch dein NAS unterstütz, musst du selber kurz prüfen.
Wenn du SMB-Multichannel jedoch nutzen möchtest, dann musst du die LACP Trunks auf der Server und der NAS Seite auflösen und die 4 NIC's je separat konfigurieren. Dabei muss jede NIC in ein eigenes Subnet, sonst funktioniert der SMB-Multichannel Spass nicht so wirklich.
Beispiel.
Server NIC 1 - 192.168.1.10/24 <--> NAS NIC 1 - 192.168.1.20/24 (VLAN 10)
Server NIC 2 - 192.168.2.10/24 <--> NAS NIC 2 - 192.168.2.20/24 (VLAN 11)
Server NIC 3 - 192.168.3.10/24 <--> NAS NIC 1 - 192.168.3.20/24 (VLAN 12)
Server NIC 4 - 192.168.4.10/24 <--> NAS NIC 2 - 192.168.4.20/24 (VLAN 13)
Die V-LAN's sind beim diesem Thema eigentlich nicht notwendig, ich finde es jedoch sauberer, wenn unterschiedliche IP Bereiche auch über unterschiedliche "logische" Netze und nicht im selben laufen.
Gruss Alex
Moin @Freak-On-Silicon,
Das ist mir alles bewusst, ich dachte allerdings wenn ich mehrere "Kopiervorgänge" starte dass das mehrere TCP Sessions sind und daher ich sehr wohl über 1Gbit komme.
als ja, mehrere Kopiervorgänge können durchaus mehrere Sessions öffnen, aber, diese lassen sich nicht über einen LACP-Trunk verteilen, weil sie immer von derselben IP/MAC kommen.
Die einzige Möglichkeit die ich sehe, wie du über diese Konstellation an die 4GBit rankommst, ist SMB-Multichannel.
Der Windows Server kann es auf jeden Fall, ob es auch dein NAS unterstütz, musst du selber kurz prüfen.
Wenn du SMB-Multichannel jedoch nutzen möchtest, dann musst du die LACP Trunks auf der Server und der NAS Seite auflösen und die 4 NIC's je separat konfigurieren. Dabei muss jede NIC in ein eigenes Subnet, sonst funktioniert der SMB-Multichannel Spass nicht so wirklich.
Beispiel.
Server NIC 1 - 192.168.1.10/24 <--> NAS NIC 1 - 192.168.1.20/24 (VLAN 10)
Server NIC 2 - 192.168.2.10/24 <--> NAS NIC 2 - 192.168.2.20/24 (VLAN 11)
Server NIC 3 - 192.168.3.10/24 <--> NAS NIC 1 - 192.168.3.20/24 (VLAN 12)
Server NIC 4 - 192.168.4.10/24 <--> NAS NIC 2 - 192.168.4.20/24 (VLAN 13)
Die V-LAN's sind beim diesem Thema eigentlich nicht notwendig, ich finde es jedoch sauberer, wenn unterschiedliche IP Bereiche auch über unterschiedliche "logische" Netze und nicht im selben laufen.
Gruss Alex
Das hatte ich mir eh auch angesehen, finds nur irgendwie nicht so geil.
Aber wenn mir mal fad ist, werde ich mir das mal testen.
Andere Idee, einfach eine 10G Karte einbauen?
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
1
Moin @Deepsys,
das bringt dem TO nichts, weil die QNAP TS-853A kein 10G kann.
Gruss Alex
Andere Idee, einfach eine 10G Karte einbauen?
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
das bringt dem TO nichts, weil die QNAP TS-853A kein 10G kann.
Gruss Alex
1Zitat von @Deepsys:
Andere Idee, einfach eine 10G Karte einbauen?
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
Andere Idee, einfach eine 10G Karte einbauen?
Sollte auch in dem alten Server möglich sein, den 10G Switch hast du ja schon
Ja, hab ich an einem anderen Standort gemacht.
