Strukturprotokolle der Datenkommunikation – IEEE 802.1ad Link Aggregation

Anbieter zum Thema

ALE Deutschland GmbH

Erlaubte und verbotene Aggregierungen

Ein weiteres Problemfeld sind erlaubte und nicht erlaubte Aggregierungen. In einem ersten, relativ statischen Ansatz hat man sich ja dazu entschlossen, für die Aggregierung den Port mit der niedrigsten Nummer auszuwählen. So kann man anhand der Konfigurierung eindeutig erkennen, welche Ports zu welcher Aggregierung gehören.

Dies hat natürlich den Nachteil, dass man neu konfigurieren, und damit das System kurzzeitig unterbrechen muss, wenn ein neuer Port zur Gruppe hinzukommt, der selbst eine niedrigere Nummer als der hat, der bislang der Aggregierungs-Port war. Andererseits, wenn man den Port, der bisher der Aggregierungs-Port war, entfernen will, so muss man ebenfalls neu konfigurieren, weil man ja jetzt den Port mit der nächst höheren Nummer zum Aggregierungs-Port machen muss.

Sieht man sich diesen Vorschlag genau an, kommt man schnell dazu, dass er in der Praxis nicht zu handhaben ist – besonders bei tausenden von Ports, bei denen laufend Änderungen anfallen. Eine andere, elegantere Möglichkeit wäre es, neben den physischen auch logische Ports eindeutig zu identifizieren, sozusagen logische MAC Adressen zusätzlich einzuführen.

Glatte Skalierbarkeit durch Trunking

Eigentlich ist das Trunking eine besonders gute Methode zur Realisierung von glatter Skalierbarkeit zwischen den Leistungsbereichen von IEEE 802.3. Denn die Sprünge zwischen 10 und 100, sowie zwischen 100 und 1000 Mbit/s sind ja doch recht groß.

Trunking kann sowohl im Backbone als auch im Backend sinnvoll eingesetzt werden. Existierende Netzwerk-Implementierungen kann man dabei so lassen, wie man möchte, weil sich jenseits der MAC-Dienstleistungsschicht nichts ändert, es wird einfach nur schneller, da für die höheren Protokolle ohnehin alles transparent bleibt.

Es gibt allerdings Einschränkungen. Das Trunking bezieht sich nur auf parallele Punkt-zu-Punkt-Verbindungen, die darüber hinaus noch Full-Duplex-fähig sein und die gleiche Übertragungsleistung aufweisen müssen. Für ein redundantes Netz möchte man Ersatzwege schalten können. Diese führen aber gegebenenfalls über andere Switches. Das geht aber gerade wieder nicht, weil getrunkte Leitungen parallel sein müssen.

Aber auch im Zusammenwirken mit höheren Protokollen gibt es Schwierigkeiten, und zwar wegen der Notwendigkeit der Eindeutigkeit einer MAC-Adresse, die bislang eigentlich den ganzen Standard durchzogen hat. Entweder muss man also der aggregierten Link-Gruppe eine einzige Adresse zuordnen oder mit einem speziellen Protokoll für den Lastausgleich eine Adresse eines höheren Protokolls, z.B. eine IP-Adresse auf mehrere MAC-Adressen abbilden.

Wenn man nur ein Trunking-Verfahren für die Gruppierung von Ports zu Gruppen zulässt, ist dies nicht für alle Anwendungen optimal. So legt z.B. eine Anwendung zwischen vielen Clients und einem Server über zwei Switches hinweg besonderen Wert auf Parallelität und Integrität von Sessions, aber weniger auf hohe rohe Bandbreite.

Tauschen sich hingegen zwei Server, z.B. ein SAP-Anwendungsserver und ein SAP-Druckserver aus, geht es vor allem um hohe Leistung, also möglichst viele parallele Links in einem Trunk. Lässt man jedoch mehrere Trunking-Verfahren zu, so müssten sich die Anwendungen eines aussuchen bzw. darüber verhandeln. Es ist aber gerade das Hauptargument der Ethernet-Verfechter, das alles so einfach wie möglich bleiben soll. Davon kann man aber nicht mehr sprechen, wenn Anwendungen Trunk-Verfahren unter sich aushandeln müssen, weil die Schnittstellen in keinster Weise darauf eingerichtet sind.

Wie zu Anfang bei den Switches gibt es auch beim Trunking Probleme mit einfachen Diagnosehilfsmitteln wie RMON oder SNMP, weil die sich gar nicht vorstellen können, dass es etwas anderes gibt als eine feste Zuordnung von z.B. je einer IP-Adresse zu einer festen, definierten MAC-Adresse. Momentan geht es in der Arbeitsgruppe um eine möglichst einfache Implementierung, die letztlich dazu führt, dass der interessierte Anwender einfach Ports gruppieren kann, wenn er dies im Rahmen der Anwendungen für sinnvoll hält.