Sep 22, 2015

6093

ESXi-Server NIC Trunking vs. Einzeln

Hallo,
wir haben bei uns mehrere Server (ESXi) wo jeweils die einzelnen NICS separat auf den Switch gehen. Ich habe mich nun gefragt, ob es sinnvoll ist (aus Performancegründen) die NIC's als Trunk zum Switch zu packen und alle vserver auf einen Virtuellen Switch zu packen. Kann hierzu jemand etwas sagen, hat jemand Erfahrungswerte?

ESXi-Version: 5.0
Gast-OS: Windows 2008R2, Linux

Gruß

Please also mark the comments that contributed to the solution of the article

Content-Key: 283571

Url: https://administrator.de/contentid/283571

Printed on: April 19, 2024 at 12:04 o'clock

33 Comments

Latest comment

Einzeln ohne eine Aggregation Techknik oder Separation in VLANs wäre tödlich, denn es droht immer ein L2 Loop.
Ein Trunking oder Lonk Aggregation mit 802.3ad und LACP ist also immer der richtige Weg.
http://rickardnobel.se/lacp-and-esxi-5-1/

Hallo

@aqui du verwechselst da etwas, bei VMWare hast du zwar eine vSwitch aber dem ist egal mit wie vielen Ports du wohin gehst, unser Server "hängen" auch mit 4+ Ports am Switch ohne das LACP oder ähnliches eingestellt - ist ja keine Connect von Switch zu Switch im eigentlichen Sinne.

@killtec LACP, Trunk oder ähnliches kannst überall machen, außer bei iSCSI da sollte man das lassen damit die Vorteile von MPIO greifen können.

Gruß
@clSchak

Hi,
also gedacht ist halt die jetzt vier separaten vSwitche, die einzeln via 1GBit Link auf den Switch gehen in ein vSwitch zu packen und das mit einem 4Gbit LACP zum Normalen Switch zu machen.
Das Einzigste, was via iSCSI ist, wäre der Zugriff auf ein Backupnas von einem einzelnen Server, ggf, noch zwei Admin-PC's. Siehe dazu:
ISCSI Volume NTFS-Formatiert - was geht

Gruß

Moin,

vier separaten vSwitche, die einzeln via 1GBit Link auf den Switch gehen

Also das ist schon mal die schlechteste Konfig von allen. Hier hast du weder Redundanz noch Lastverteilung.
Pack alle VMs und alle Uplinks auf einen vSwitch, dann passt es. LACP Trunks würde ich perönlich nicht konfigurieren.

lg,
Slainte

Hi

@aqui

wir haben bei uns mehrere Server (ESXi) wo jeweils die einzelnen NICS separat auf den Switch gehen

In diesem Fall kümmert sich VMware auf dem vSwitch um das richtige Load balancing und um eine Loop freie Topologie

LG

Hi,
Also im Moment haben wir das so (1 JPG sagt Mehr als 1000 Docs :D ):

Diese 4-5 Adapter dachte ich als LCAP auf den Switch laufen zu lassen. Also ein VSwitch und dann die Physischen Adapter auch auf einen VSwitch. Hoffe ich drücke mich richtig aus

-> VMWare macht das Balanching dann wirklich selbst? Gibt es da keine Loops?

Will das jetzt nicht einfach so testen, ist nen Produktivsystem....

Gruß

Jo, genau so isses Mist.

So muss das:

OK, und du hast deine vmnics nicht als Trunk gemacht?

du verwechselst da etwas, bei VMWare hast du zwar eine vSwitch aber dem ist egal mit wie vielen Ports du wohin gehst,

Sorry aber kann ich mir nicht wirklich vorstellen.
Es ist unmöglich das man den vSwitch einfach so ohne jegliche Konfig parallel iirgendwo raufsteckt. Jeder Laie weiss das das im Ethernet nicht geht und man so einen Loop hat.
Gut wenn der STP aktiviert hat dann geht das und dann blockt er halt von 4 Ports 3 wieder und gut iss. Aber genau DAS will man ja nicht.
Wenn also eine Bündelung mit 802.33ad / LACP dann muss das auch auf einem vSwitch und auf der HW Intrafstruktur aktiviert sein.
Anders kann es nicht gehen...oder wäre ein netztechnisches Wunder

In diesem Fall kümmert sich VMware auf dem vSwitch um das richtige Load balancing und um eine Loop freie Topologie

Das mag sein aber ganz sicher nicht von ganz allein, denn wie sollte das gehen ?

OK, und du hast deine vmnics nicht als Trunk gemacht?

Genau.

@aqui

Sorry aber kann ich mir nicht wirklich vorstellen.
Es ist unmöglich das man den vSwitch einfach so ohne jegliche Konfig parallel iirgendwo raufsteckt.

Das sind bei den vSwitches keine "normalen" Switchports sondern dedizierte Uplinks über die VMWare in der default Einstellung MVs im "Round Robin" mit dem phys. Switch verbindet. Ein loop kann da nicht entstehen.

Das weiss der externe Switch aber nicht und loopt oder versucht es. Wie verhindert der vSwitch das ?

Werde das nachher mal zuhause nachstellen und testen...

Zitat von @aqui:

Das weiss der externe Switch aber nicht und loopt oder versucht es. Wie verhindert der vSwitch das ?

Der vSwitch forwarded grundsätzlich nicht zwischen den Uplinks,/vNICs sondern nur zwischen Uplinks und VMs

Mmmmhhh, wie kann er denn aber eine bidirektionale Layer 2 Kommunikation im Ethernet leisten ? Das wäre ja dann technisch unmöglich wenn das nur eine Einbahnstrasse ist.

...oder wäre ein netztechnisches Wunder

Und so etwas gibt es eben nicht!

Ein LAG (LACP) ist immer eine zwei seitige Sache, also eine Sache mit zwei Enden
und das LACP konfiguriert dann auf beiden Seiten automatisch die LAG.

Das sind bei den vSwitches keine "normalen" Switchports sondern dedizierte
Uplinks über die VMWare

Richtig nur muss trotz alle dem dann dort auf beiden Seiten des LAGs mittels
LACP ausgehandelt werden was, wer, wo, mit wem und wie weiterleitet.

in der default Einstellung MVs im "Round Robin" mit dem phys. Switch verbindet.

Macht @Dani auch so bei sich im Betrieb hat sie hier mal geschrieben und sogar
mittels statischem LAG und iSCSI, aber dann ist eben kein LACP mit im Spiel und
man muss wirklich aufpassen das auf beiden Seiten des LAGs alles genau gleich
konfiguriert wird sonst wird es nichts mit dem LAG.

Werde das nachher mal zuhause nachstellen und testen...

Wären denn eventuell noch PCI/PCIe Slots frei und man sollte eventuell
auch einmal eine 10 GBit/s Dual Port Karte mit ins Auge fassen?
Ist jetzt nicht böse gemeint nur wenn es der Performancesteigerung
dienen soll ist das auch eine Sache die recht schnell sehr gute Ergebnisse
liefern könnte.

Gruß
Dobby

Hi, habe das mal "nachgestellt"
Allerdings ohne 10G Karte... Hat der Switch nicht und der Server auch nicht.
Ein Loop wurde nicht erkannt... (Nichts in den Switch logs eingetragen).
In dem Produktivsystem klappt das auch nicht mit der 10 Gig Karte. Die Performance soll auf den Uplinkstrecken laufen... U.A. Wegen Backups auf dem iSCSI Ziel...

Gruß

Allerdings ohne 10G Karte... Hat der Switch nicht und der Server auch nicht.

Macht nix mit 1G oder 100Mbit gehts ja auch

Ein Loop wurde nicht erkannt...

Rennt auf den vSwitches oder deinem externen evtl. Spanning Tree per Default ? Das wäre dann eine Erklärung.
Mach mal ein "show spanning tree" auf dem externen ob du einen Bridge Neighbor siehst ! Würde dann für STP sprechen...

Wichtig ist das die Ports des vSwitch die über unterschiedliche physische NICs auf einen externen Switch gehen in der gleichen Layer 2 Broadcast Domain, sprich VLAN liegen müssen und einen Loop zu provozieren.
In getrennten passiert das logischerweise nicht.
Der Switch muss dann Broad- oder Multicast Pakete zwingend forwarden auf allen Ports was ein sofortiges Looping auslöst. Es sei denn....
einer der Switches sei es vSwitch oder der Externe spricht Spanning Tree !
Oder es reicht auch wenn der externe Switch Spanning Tree spricht und der vSwitch Spanning Tree BPDU Paket "durchschleift" so das sie am externen Switch dann wieder ankommen und der sein Ports in Blocking setzt.
Nur so kann man ja einen Loop vermeiden.
Man müsste das auch sehen wenn man mal einen Wireshark an den ESXi mit vSwitch hängt. Dort müssten dann STP BPDU Frames zu sehen sein....
Vermutlich passiert das bei allen Unwissenden die parallele Links stecken. Die merken dann nur an schlechter Perfmance da immer n-1 Links in Blocking gehen.
Wenn aber vSwitch und externer Switch keinerlei Loop Protection haben sei es STP oder ähnliches muss es ja zwangsweise zum Loop kommen.

Will man also mehrere Links am vSwitch parallel nutzen auf einen externen Switch, was ja durchaus sehr viel Sinn macht wenn man multiple NICs mit einer 4er Karte oder sowas im Server hat, muss man also eine Art von Aggregation machen.
Wie Kollege @108012 oben richtig sagt ist das immer eine zweisetige Angelegenheit, sonst klappt das nicht.
Da geht dann nur statische Aggregation oder immer besser die mit LACP.
Beide basieren auf dem 802.3ad Balancing Algorithmus also dem XOR Link Hashing auf Basis der letzen 4 Bit der Mac oder IP Adresse. Bessere Switches hashen noch den Port mit dazu damit sie granularer werden in der Verteilung der Layer 2 Sessions über die Links.
Letzteres ist auch immer der Nachteil von Link Aggregation, da ein Balancing nie homogen ist aufgrund der nicht homogenen Verteilung der Macs oder IPs.
Besser ist denn da doch immer noch die "Fat Pipe" mit 10 oder 40G

Zitat von @aqui:

Das mag sein aber ganz sicher nicht von ganz allein, denn wie sollte das gehen ?

Moin,

das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den phyhsischen Switches nix konfiguriert werden. Bei Ausfall einer NIC wird dann halt neu gewuerfelt...

VG,

Thomas

das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die
Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den
phyhsischen Switches nix konfiguriert werden. Bei Ausfall einer NIC wird
dann halt neu gewuerfelt...

Das wäre natürlich eine Erklärung, aber die NICs müssen wenn man am Switch LAG
(LACP) einstellt doch auch via LACP angebunden werden, sicher wenn das dann intern
anders gehandhabt wird ist das ja auch eine ganz andere Sache.

Gruß
Dobby

@aqui&Dobby: Ihr könnt den anderen ruhig glauben. Auch bei uns funktioniert das so. Gänzlich ohne Teaming/Link Aggregation und STP. Da loopt nichts und es geht auch kein Port auf blocking. Entsprechend konfiguriert kümmert sich vmware um das Loadbalancing und das Failover. Unser vmware-Spezi hatte mir vor Jahren bei der Ersteinrichtung auch die Konfigurationsmöglichkeiten und deren Vor- und Nachteile erläutert. Gemerkt hab ich es mir leider nicht. Meine Zuständigkeit hört (zumindest in diesem Fall) bei den aktiven Netzkomponenten auf.

Gruß
sk

Zitat von @108012:

Das wäre natürlich eine Erklärung, aber die NICs müssen wenn man am Switch LAG
(LACP) einstellt doch auch via LACP angebunden werden, sicher wenn das dann intern
anders gehandhabt wird ist das ja auch eine ganz andere Sache.

Man stellt am Switch kein LACP ein, es werden ganz normale Access Ports benutzt.

VG,

Thomas

Um das ganze mal abzukürzen... Hier liegt das PDF von Vmware zum Thema "VMware Virtual Networking Concepts" - da lässt sich (ab Seite 4) alles nachlesen.

Zusammengefasst:
- Multiple phys. Uplink pro vSwitch
- kein STP nötig
- kein LACP nötig

Hi,
also kann demnach auch durchaus eine ungerade Zahl von Links auf einem vSwitch "gesteckt" werden ohne ein LACP zu nutzen, richtig?
Das ist aber dann eine Spezielle VMWare Funktion oder?

Gruß

also kann demnach auch durchaus eine ungerade Zahl von Links auf einem vSwitch "gesteckt" werden ohne ein LACP zu nutzen, richtig?

Gerade, ungerade, völlig egal.

Das ist aber dann eine Spezielle VMWare Funktion oder?

Wenn du willst, ja.

das geht und zwar fuer den Anwender wirklich "von ganz allein". Man kann z.B. die Nutzung der NICs anhand des IP Hashes konfigurieren, dafuer muss an den phyhsischen Switches nix konfiguriert werden.

OK, das mag ja stimmen aber man muss ja immer auch die andere Seite sprich den externen Switch betrachten.
Der weiss ja gar nichts von den ominösen Algorythmen und Zaubereinen die der vSwitch da vollführt.
Wenn dort 2 oder 4 parallele Links gesteckt sind, dann forwardet der alles auch dahin solange das in einer L2 Domain ist. Er muss ja davon ausgehen das da auch 2 oder 4 einzelne Endgeräte dran sind.

Der vSwitch kann ja dedizierte Mac Pärchen verteilen...keine Frage aaaaber...
Was passiert mit inbound Broad- und Multicasts und vor allen Dingen mit STP Paketen die der externen Switch an diese Ports flutet ?? Wie verhält sich der vSwitch da ?? Droppt der die ?? Kann er ja nicht....
Spannend die Frage was mit STP Paketen passiert ?
Wenn er die durchschleift, dann gehen alle parallelen Ports am externen Switch in Blocking.
So würde dann wieder ein Schuh draus das der vSwitch "das von alleine" kann. Anders nicht.
Hilft wohl nix.... muss man wohl mal die VmWare Spezifikation zum vSwitch lesen...

Die Doku hier:
http://www.admin-magazin.de/Das-Heft/2010/05/Redundante-Netzanbindung-m ...
Ist da aber ganz klar und eindeutig: (Zitat):
In der Regel entscheidet man sich, zumindest auf einem virtuellen Switch zwei physische Netzwerkadapter zusammenzufassen. VMware nennt dies NIC Teaming. Bei der IEEE ist der geläufige Begriff Link Aggregation, definiert in der IEEE 802.1ax (früher 802.3ad). Neben VMware nutzen auch die meisten anderen Hersteller eigene Marketingbegriffe, um Link Aggregation zu beschreiben. Üblich sind zum Beispiel die Bezeichnungen Etherchannel, Trunking, Bündelung, Teaming oder Port Aggregation.

Link Aggregation bezeichnet die parallele Bündelung von mehreren Netzwerkadaptern zu einem logischen Kanal. Diese Technik bietet zwei wesentliche Vorteile gegenüber der klassischen Verkabelung mit einem Netzwerkkabel: höhere Verfügbarkeit und höhere Übertragungsgeschwindigkeiten. Solange zumindest ein physischer Link vorhanden ist, bleibt die Verbindung bestehen, nur die zur Verfügung stehende Bandbreite verringert sich.

Es ist ausschliesslich von Link Aggregation die Redebei Verwendung paralleler NICs ! Eine Option die einfaches paralleles Zusammenstecken auf einem externen Switch beschreibt existiert ja de facto nicht !
Das wäre auch sehr verwunderlich, denn es würde sämtlichen Ethernet Konventionen widersprechen.

Den Schluss den man dann daraus ziehen kann ist das Admins die ohne Konfig einfach so mal parallele Links zusammenstecken dann vom Spanning Tree "gerettet" werden der ihnen alle Links bis auf einen wieder abschaltet (Blocking) um so ein Looping zu verhindern.

Zitat von @aqui:

Den Schluss den man dann daraus ziehen kann ist das Admins die ohne Konfig einfach so mal parallele Links zusammenstecken dann vom Spanning > Tree "gerettet" werden der ihnen alle Links bis auf einen wieder abschaltet (Blocking) um so ein Looping zu verhindern.

Nein, die werden nicht vom STP gerettet weil STP nicht notwendig ist. Im von SlainteMhath verlinkten Dokument kannst du auf Seite 5 lesen warum es nicht notwendig ist. Und ja, wenn man moechte kann man natuerlich LACP verwenden - macht aber fuer kleinere Installationen keinen Sinn weil es das Setup unnoetig verkompliziert.

OK, das Dokument klärt das ! Ein zusätzlicher Anruf bei einem VmWare Profi beim Hersteller selber erklärte dann den Rest.
Des Rätsels Lösung ist das der vSwitch kein "richtiger" Switch ist bzw. nicht als solcher funktioniert.
Inbound Broad- und Multicast Traffic wird nicht wieder an diese Ports geforwardet. Letztlich funktionieren diese Ports quasi wie ein PVLAN oder isolated VLAN auf einem "richtigen" Switch..
Zusätzlich kommt hinzu das der vSwitch eine dedizierte Zuweisung der VMs auf die Ausgangsports NICs macht.
Aus Sicht eines externen Switches sieht es dann so aus als ob diese Ports quasi die Endgeräte Ports sind so als wenn die VMs physisch daran angeschlossen sind.
Werden mehrere VMs gemappt ist das so wie ein kleiner 5 Port Dummswitch der da angeschlossen ist.
OK so wird ein Schuh draus.....

Damit ist aber auch klar das es mit dieser einfachen und normalen Vorgehensweise des VM Mappings am vSwitch keinerlei Link Aggregation gibt. Eine VM kann immer nur starr ihren zugewiesen Port nutzen.
OK, bei wenigen VMs auf einem Host ist das dann sicher egal aber hat man mehrere VMs auf wenigen NIC Ports ist ein Balancing mit 802.3ad (oder .ax) und LACP (oder ohne LACP mit statischen Trunks) in jedem Falle vorzuziehen !

Auf alle Fälle hat die gute Diskussion hier mal gezeigt das ein vSwitch nicht wie ein "richtiger" Switch agiert !!
Dank auch des guten Dokument URL vom Kollegen @SlainteMhath
Case closed...

Ich hätte aber noch zwei Fragen dazu.

1.- Wenn man nun eine Intel Quad Port Server NIC nimmt und ein an einem
verwalteten Switch ein LAG (LACP) damit bildet und dann erst einen vSwitch
auf dem Hypervisor anlegt und diesem vSwitch dann an 4 vPorts 4 VMs zuweist
und auf der anderen Seite nur diesen "einen Adapter" mit einer IP Adresse, sollte
das doch auch funktionieren oder etwa nicht?

2.- Wenn man 4 Intel Quad Port Server NICs im Server eingebaut hat und auch wieder ein
LAG anlegt was eventuell statisch ist und via Round Robin die Verteilung vornehmen soll.
Und dann lege ich 4 vSwitches intern an und weise dann je einem vSwitch eine Karte zu
bzw. ein Interface zu und auf der anderen Seite lege ich dann also 4 vSwitche an und
weise dann jeder VM einen eigenen vSwitch zu, sollte das nicht auch funktionieren?

Sicherlich braucht es intern kein LAG und kein LACP, nur wenn ich nun einmal via LAG
sei es nun dynamisch über LACP oder statisch die Daten verteilen will, kann man dann
nicht vorher ein LAG aufsetzen und dann trotzdem dem vSwitch zuweisen?

Gruß
Dobby

1.)
Nein, das funktioniert de facto nicht. Du hast ja kein 802.3ad / LACP auf dem vSwitch eingerichtet ! Jedenfalls hast du das nicht geschrieben oben ?!
Musst du aber machen damit der Trunk aktiv wird.
Ohne LACP Polling beiseitig wird der externe Switch den LAG nicht aufbauen und den auf "shutdown" setzen ! Wie du selber immer richtig sagst: Link Aggregation ist immer eine zweiseitige Angelegenheit !!!

802.3ad / LACP MUSS also zwingend auch auf der vSwitch Seite aktiviert sein, dann klappt es natürlich.
Minimal aber ein statisches Trunking / LAG auf dem vSwitch. Analog dann auch statisches Trunking auf dem externen Switch.
So klappt das und wäre der richtige Weg für ein Load Balancing.
OK, wenn du eine Quad Karte hast mit 4 VMs musst du das nicht. Denn dann kann jede VM einen Port haben. Hast du aber 8 oder 16 VMs ist eine Link Aggregation Konfig erheblich besser als ein NIC Sharing, da die Traffic Verteilung so homogener ist.
2.)

und via Round Robin die Verteilung vornehmen soll.

Das ist technisch unmöglich. Es gibt keinen Standard der Round Robin kann ! Trunking bzw. Link Aggregation funktioniert immer nur mit Hashing ! Das ist vom IEEE 802.3ad bzw. .ax Standard zwingend so vorgegeben.
Das was du mit der VM zu vSwitch zu NIC Zuweisung beschreibst macht VmWare schon von sich aus. Das ist das was nicht switchkonform" ist verglichen zu normalen Switches. Eine VM bekommt einen dedizierten vSwitchport der wieder dediziert einem NIC Port zugewiesen wird.
Die VM "sieht" einzig nur diesen Port und NIC. Das ist das was mit PVLAN und Isolated VLAN gemeint ist auf "normalen" Switches.
Fakt ist: Für Trunking bzw. Link Aggregation MUSS beidseitig 802.3ad / ax mit oder ohne LACP aktiviert sein sprich vSwitch UND externer Switch müssen das konfiguriert haben.

Sicherlich braucht es intern kein LAG und kein LACP

Doch ! Wenn damit nach außen kommuniziert wird.
Einer VM mehrere virtuelle NICs zuzuweisen die dann per LAG auf den vSwitch zu legen ist völliger Unsinn, das ist richtig.
Die virtuellen Links intern arbeiten mit Systemgeschwindigkeit, da gibt es keine Infrastruktur bestimmten Speeds wie im Ethernet. Folglich ist es völlig sinnfrei vNICs auf den VMs zu aggregieren, das meintest du vermutlich und hättest damit Recht.

Zitat von @108012:

Ich hätte aber noch zwei Fragen dazu.

1.- Wenn man nun eine Intel Quad Port Server NIC nimmt und ein an einem
verwalteten Switch ein LAG (LACP) damit bildet und dann erst einen vSwitch
auf dem Hypervisor anlegt und diesem vSwitch dann an 4 vPorts 4 VMs zuweist
und auf der anderen Seite nur diesen "einen Adapter" mit einer IP Adresse, sollte
das doch auch funktionieren oder etwa nicht?

Ja, das funktioniert. Aber normalerweise haben die NICs auf ESXi Seite keine IP, die wird ja erst in der VM vergeben.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&am ...

2.- Wenn man 4 Intel Quad Port Server NICs im Server eingebaut hat und auch wieder ein
LAG anlegt was eventuell statisch ist und via Round Robin die Verteilung vornehmen soll.
Und dann lege ich 4 vSwitches intern an und weise dann je einem vSwitch eine Karte zu
bzw. ein Interface zu und auf der anderen Seite lege ich dann also 4 vSwitche an und
weise dann jeder VM einen eigenen vSwitch zu, sollte das nicht auch funktionieren?

Ja, wenn ich dich richtig verstanden habe sollte das auch funktionieren, ob das so ueberhaupt sinnvoll ist steht nochnmal auf einem anderen Blatt. Allerdings sollte man bei diesem Bandbreitenbedarf doch ueber 10G nachdenken, das haette dann noch andere Vorteile.

VG,

Thomas

alles klar danke @aqui und danke Thomas, es war ja auch nur des Verständnisses halber
die Frage ob sich das überhaupt so realisieren ist.

Gruß
Dobby

HI,
also Zusammengefasst kann man sagen, dass ein LCAP / Aggregation besser ist, das aber dann jedoch nur mit "geraden" Nic Zahlen, also 2,4, usw.

Danke für eure zahlreichen Infos und die super Diskussion

Gruß

M.E. ist das abhängig von der Anzahl der VMs und vorhandenen physischen NICs. Geht das auf, dann bringt vermutlich eine Link Aggregation nicht viel, denn so kann man ja jeder VM dediziert eine NIC zuweisen.
Die Aggregation macht dann Sinn wenn es mehr VMs als physische NICs gibt und verbessert sich im Nutzen und Sinnhaftigkeit immer mehr je größer das Delta zwischen VMs und physischen NICs wird oder ist.

Kollege tkr104 hat aber letztlich recht, denn durch das Hashing hat man bei der Aggregation immer einen Nachteil das die Homogenität der Auslastung paralleler Links anbetrifft. Letztlich ist die "Fat Pipe" dort immer besser und vorteilhafter.
Für den der kein 10G zur Verfügung hat und nur multiple 1G ist dann aber Link Aggreagtion immer noch die beste Lösung.

Danke für eure zahlreichen Infos und die super Diskussion

Dem schliess ich mich an ! Bringt eben was wenn man von jedem Fachgebiet gute Inputs bekommt !

German Question LAN, WAN, Wireless Networks

Hotly discussed

Check of ZFW Firewallgleixnerd - 3 Comments

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

WIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment