Ungenauigkeiten lagg(4) Link Aggreation nach IEEE 802.3ad

rMarkus

rMarkus

Chuck The Plant
Hallo,

das kommende FreeBSD 6.3 bzw. 7.0 unterstützt durch das Modul lagg(4) das nützliche Zusammenfassen von Netzwerklinks nach IEEE 802.3ad .

Ich habe letzte Woche mal eine kleine Howto für dieses Feature geschrieben:
http://wiki.bsdforen.de/freebsd/link_aggregation

Heute wurden zwei Fragen dazu aufgeworfen:

1. Nach meinen Unterlagen sollte IEEE 802.3ad speziell lacp den Trunk automatisch mit einem Switch aushandeln können, der das beherrscht. In dem Switch sollte die Konfiguration der betreffenden Ports also nicht mehr notwendig sein.
Könnt ihr das bestätigen?

2. Heute bin ich auf eine frische Doku zu dem Thema im FreeBSD-Handbuch gestoßen: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html
Zum Einen wird der Switch dort explizit konfiguriert (siehe meine 1. Frage) und zum Anderen wird da eine erschrenkende Thesen vertreten:

Es wird behauptet, dass die Reihenfolge bei Ethernet-Frames zwingend eingehalten werden muss. Aus dem Grund wird eine Verbindung von einem Rechner zu einem anderen immer nur über eine Verbindung des Trunks abgewickelt, so dass die maximale Geschwindigkeit zwischen zwei Rechnern auf die eines Interfaces limitiert ist.

Nach meinen Erinnerungen ist die Reihenfolge bei Ethernet-Frames egal, da erst Schicht 4 Protokolle wie TCP die Reihenfolge garantieren (und auch herstellen können).


Nach meinen ersten Tests mit lagg(4) geht bei einer Bündelung von 2 Netzwerkkarten fast der ganze Verkehr ueber ein Interface raus und kommt über das andere hinein. Das unterstützt die These.
Andererseits halte ich den Reihenfolgengrund als kaum haltbar für diese doch massive Beschränkung.

Wisst ihr vielleicht mehr?


Markus
 
Eine Layer-3 Kommunikationsrichtung sollte doch eben wegen solchen Effekten wie Reihenfolgeproblemen sowieso nur über einen Link der Aggregation erfolgen. Zumindest machen 3Com-Switche das so. LACP steigert also nur die aggregierte Bandbreite (wie ironisch) vieler Verbindungen zwischen verschiedenen Hosts.

Nach der Logik müsste eine 802.3ad Aggregation direkt an einem Host also mit vielen verschiedenen Hosts Verbindungen gleichzeitig aufnehmen, damit sich die gesteigerte Datenrate zeigt.

Wofür brauchst du denn lagg(4)? Ich kann mir irgendwie nicht vorstellen, dass die Bandbreite von Gigabit-Ethernet für gewöhnliche Anwendungen nicht ausreicht.
 
Endorphine schrieb:
Wofür brauchst du denn lagg(4)? Ich kann mir irgendwie nicht vorstellen, dass die Bandbreite von Gigabit-Ethernet für gewöhnliche Anwendungen nicht ausreicht.
Zum Vergrößern anklicken....

Mein Switch ist auch von 3Com und da habe ich das oben Beschriebene beobachtet, jedoch habe ich nur einen Ping und ein csup laufen lassen.

Trotzdem: Die Reihenfolge von IP-Paketen auf dem Kommunikationsweg ist egal, sie können auch über ganz ander Pfade laufen - damit ist die der Ethernet-Frames auch egal.
Kein vernünftiges Programm darf sich nach meinem Wissen auf Reihenfolge verlassen.
Ich halte es auch für sehr unwahrscheinlich, dass ein Switch Stream-Informationen aus den Ethernet-Frames gewinnt und danach die Verteilung macht. Maximal kann ich mir die (jedoch unsinnige) Verteilung von zwei Kommunikatonspartnern auf einen Trunk via Mac-Adressen vorstellen.


Hintergrund ist nebem meinem Interesse auch der Einsatz von 802.3ad mit mehreren LTO4-Laufwerken. Hierzu sollen 4 Gigabit-Kanäle verwendet werden.
 
Lies mal die 3Com Switch-Doku zu lagg. :)
rMarkus schrieb:
Hintergrund ist [...] der Einsatz von 802.3ad mit mehreren LTO4-Laufwerken. Hierzu sollen 4 Gigabit-Kanäle verwendet werden.
Zum Vergrößern anklicken....
Sind solche Storage-Datenraten nicht besser im SAN aufgehoben?

Ich finde lagg(4) eher interessant für Cluster und als billige 10-Gigabit NIC Alternative...
 
Zuletzt bearbeitet:
Das Sichern direkt über das SAN war angedacht, konnte aber wohl nicht umgesetzt werden, da da entweder der zu sichernde Host die Filessysteme loslassen müsste und der Backup-Host mounten oder ein Clusterfilesystem eingesetzt werden muss.

Das alles ist ziemlich wacklig und Online-Backups würde man so nur durch viel Fummeln hinbekommen.
Wir kommen aber vom Thema ab.

Auf welche Dokus beziehst Du Dich genau, die Doku zu meinem 3Com Switch ist nur "BlaBla".
 
Auf die Doku zum 3Com Superstack-3 4400. Ich glaube das Dokument heißt "Switch Implementation Guide". Da ist ein Abschnitt zur Link Aggregation drin. Leider sind dort die wichtigen Informationen aber in den Untiefen des Textes verborgen. Man muss also wirklich ein wenig lesen.
 
Auf den 3Com-Seite zum 2226-PWR Plus steht:
IEEE 802.3ad links aggregation (manual)

Wenn das schon explizit so dort steht, wird der Switch wohl kein LACP beherrschen.
 
Nach meinen Unterlagen sollte IEEE 802.3ad speziell lacp den Trunk automatisch mit einem Switch aushandeln können, der das beherrscht. In dem Switch sollte die Konfiguration der betreffenden Ports also nicht mehr notwendig sein.
Zum Vergrößern anklicken....

Kann ich so bestätigen:
Wenn lacp auf den Ports eingeschaltet ist funktioniert das. Das ist bei vielen Switches aber standartmäßig ausgeschaltet.

Ich aktiviere einfach immer lacp auf den entsprechenden Ports und packe diese später aber noch manuell in eine LinkAggregation Group, damit ich den Überblick behalte.
Außerdem bilde ich mir noch ein, dass die Switch schneller reagiert wenn man einen Link trennt.
 
Hallo,

ich habe das gerade getestet und das bestätigt die Aussagen von Endorphine und Ne0n:

Versuchsanordnung:
3Com Baseline 2226plus
- RechnerX mit einem Trunk an zwei 100-Bit-Ports (lacp ueber dual fxp) (Zwei Instanzen netstraind (Port 666 und 6667)
- RechnerA mit Anbindung ueber 1 GBit (netstrain client)
- RechnerB mit Anbindung ueber 100 MBit (netstrain client)

Netstrain immer im Vollduplex-Modus, d.h. die Datenraten gelten fuer beide Richtungen gleichzeitig.

1. Man muss das in jedem Fall auch switchseitig konfigurieren, sonst sendet der Switch nur auf einem Pfad zum Rechner - der Rechner aber auf beiden.

2. Eine Verbindung zwischen zwei Rechnern läuft immer nur über einen Kanal. Dieser Datenstrom ist durch die Empfänger-Sender-Hardwareadressen definiert.
2.1 RechnerX gegen RechnerA mit einer Netstrain-Verbindung schaffen rund 10 MByte/s
2.2 RechnerX gegen RechnerA mit zwei Netstrain-Verbindungen schaffen zusammen rund 10MByte/s
2.3 RechnerX gegen RechnerA und RechnerB mit zwei Netstrain-Verbindungen von A und B schaffen zusammen rund 20MByte/s
 
"1. Man muss das in jedem Fall auch switchseitig konfigurieren, sonst sendet der Switch nur auf einem Pfad zum Rechner - der Rechner aber auf beiden.

2. Eine Verbindung zwischen zwei Rechnern läuft immer nur über einen Kanal. Dieser Datenstrom ist durch die Empfänger-Sender-Hardwareadressen definiert"

Kann ich ebenfalls bestätigen. LACP ist da recht enfach konzipiert und macht so ein richtiges Load-Balancing nur in größeren geswitchten Netzwerken. Der Grund dafür ist die hohe Anzahl an unterschiedlichen MAC-Adressen in solchen Umgebungen. Das war wahrscheinlich auch der Grund warum Cisco sein proprietäres Etherchannel drübergestülpt hat, weil dadurch die Möglichkeit geschaffen wurde Layer4-Informationen in den Hash für die Lastverteilung zu integrieren.
 
Hallo,

nach meinem Wissen ist Ciscos Etherchannel viel älter als LACP. Die Technik wurde von Cisco erworben, als sie den Hersteller des ersten Switches geschluckt haben.

Wenn die Reihenfolge wirklich wichtig sein sollte für Ethernet-Frames, dann wird auch Etherchannel diese Einschränkung haben. Anderseits gibt's im Freebsd-lagg(4)-Modul auch eine Möglichkeit die Last zumindest sendend via Round-Robin zu verteilen, was ja eigentlich der Einschränkung wiederspricht.

Gerade in größeren Netzwerken sehe ich durch diese Einschränkung sogar eher ein Problem, da die Server sich oft in einem eigenen Subnetz befinden, getrennt von den Clients. Wenn ein Server nun via LACP angebunden ist, dann kommuniziert der im Wesentlichen mit den Routern (bzw. der virtuellen Router-Instanz des Routing-Switches) und der hat nur eine Mac-Adresse. So würde der Verkehr über nur einen Link laufen können.
 
Welches der beiden Protokolle älter ist, kann ich nicht sagen.

Die Lastverteilung aufgrund eines Hashes auf Layer4-Basis macht aber schon Sinn. Egal, ob sich die Server in ein und demselben Subnetz befinden, wird zur Berechnung des Hashwertes im Etherchannel auch der Port hinzugezogen. Aber davon mal ab...wenn Client A mit Server A (IP: x.x.x.1) kommunziert, benutzt er eine andere Leitung als würde Server B (IP x.x.x.2) ansprechen . Das Subnetz ist also erstmal egal in diesem Bespiel. Je nach Netzdesign kann es zu den unterschiedlichsten Szenarien kommen, in denen man in irgendeiner Weise eine Lastverteilung ereichen möchte. Deswegen gibt es bei Cisco die unterschiedlichen Möglichkeiten der Konfiguration (MAC-basiert, IP-basiert, Port-basiert).

Die Einschränkung, dass für lagg(4) die Reihenfolge der Frames wichtig ist, ist also eigentlich keine Einschränkung, sondern lediglich die Folge dessen, ankommende Frames einem physikalischen Link mithilfe eines eindeutigen Hashes zuzuordnen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben