Sie sind auf Seite 1von 14

L2 Multi-Pathing im modernen Netzwerk

Ngoc Khanh Truong


Fachbereich Angewandte Informatik
Hochschule Fulda
Marquardstrae 35
36039 Fulda
Ngoc.K.Truong@informatik.hs-fulda.de

Abstract: Im ungebrochenen Wachstum von Cloud Computing erfolgt der


Datenaustausch berwiegend innerhalb Rechenzentren. Dem Datenverkehr,
den IT-Services und den Anwendungen in Clouds wird ein starker Zuwachs
prognostiziert. Der Umgang mit Engpass wird deshalb zu einer Herausforderung fr den Betrieb moderner Rechenzentren, die zahlreiche Hosts und Applikationen beherbergen. Dafr spielt Layer 2 Multi-Pathing (L2MP) eine
ausschlaggebende Rolle. Die konventionellen Technologien wie Spanning
Tree Protokoll (STP) und Multi Chassis Link Aggregation Protokoll (MLAG)
knnen nicht die mit L2MP verbundenen Probleme grndlich angehen. Eine
effektive Lsung fr L2MP bietet Transparent Interconnection of Lots of
Links (TRILL) an, mit dem ein Large-Scale L2 Netzwerk zur effizienten
Bandbreiten- und Ressourcennutzung in Data Center konstruiert wird. Diese
Arbeit befasst sich mit diesem Protokoll in Hinsicht darauf, wie rationell
TRILL zur Erfllung von L2MP-Problemen ausgenutzt wird.

1 Einleitung
Seit den letzten fnf Jahren wchst Cloud Computing ungebremst. Laut Einschtzung von Experten und Analysten gehrt Cloud Computing die Zukunft. Im Alltag
werden Benutzer die Cloud unbewusst genutzt, entweder im eigenen Rechenzentrum oder ber einen Dienstanbieter. Nach Angabe von Cisco Global Cloud Index
erhht sich das weltweit durch die Cloud erzeugte Datenvolumen jhrlich um 35
Prozent und mglicherweise zwischen 2012 und 2017 um das 4,5-Fache [1]. Hervorzuheben ist es, dass bis 2017 vermutlich bis zu 76 Prozent des Datenverkehrs
innerhalb Rechenzentren entstehen knnten, d.h., 76 Prozent des Datenverkehrs
werden von Server zu Servern vom Ost zum West bermittelt. Aus dieser Statistik

ist es festzustellen, dass Cloud Computing zunehmend das Volumen des Datenverkehrs in Rechenzentren bestimmt und zur Entstehung der massiv skalierbaren
und kommodifizierten Rechenzentren (SKDC) fhrt [2, 3], wo mehr als ein hundert
tausend Server in Betrieb genommen werden, aus denen Pools von Compute und
Storage durch Virtuallisierungstechnick zum Hosten der Applikationen erzeugt
und geographisch verstreut werden. Zum Beispiel kann ein Suchbefehl auf einer
Webseite auf eine invertierte Datei zugreifen, die geografisch in 1000+ Servern
verstreut werden, und bis zu Petabytes von Informationen, die in tausend Maschinen gespeichert werden, mssen Storage und Tools zur Analyse interaktiv verarbeiten [4].
Solcher intensiver Austausch und Verarbeitung von Ost-zu-West-Datenverkehr
erfordert eine neue Methode zur Aggregierung und effizienten Nutzung von Bandbreite. Dazu ist L2MP als Erstes angedacht. Konventionelle Rechenzentren ber
Layer 2 (L2) Ethernet mit dem Einsatz von STP fokussiert sich ausschlielich auf
die Verteilung des Norden-zu-Sden-Datenverkehrs und nutzt nur 50 Prozent der
verfgbaren Bandbreite im Rand von Netze, auch wenn sie mit den hochleistungsfhigen IP-Switches und Routers ausgestattet werden. Als Alternative ermglicht
MLAG zwar die vollstndige Linknutzung, dennoch wird bis zum Zeitpunkt dieser
Arbeit noch nicht standardisiert und erschwert dadurch die Integration der Produkte mehrerer Firmen bzw. die Kollaboration in Cloud-Umgebungen. Auch Skalierbarkeit ist dabei problematisch. Eine innovative Lsung fr L2MP liefert das
Standard-Protokoll von Internet Engineering Task Force (IETF) TRILL [15], welches die Techniken von Layer 3 (L3) Routing und L2 Switching kombiniert, damit
sich Equal Cost Multi-Path Routing (ECMP) in L2 einbinden lsst. Es ist besonders darauf hinzuweisen, dass TRILL neben L2MP auch die anderen Anforderungen moderner Rechenzentren erfllen.
Diese Arbeit fokussiert sich mit der Lsung fr L2MP ber Ethernet mit dem
Protokoll TRILL, da Ethernet bisher Netzwerkinfrastruktur in Rechenzentren dominiert. Der Rest der Arbeit wird wie folgt gegliedert: Kapitel 2 gibt einen berblick ber konventionelle Methode fr L2MP ber Ethernet mit ihren Problemen.
Daraus werden die Anforderungen von L2MP in modernen Netzwerk festgestellt,
den TRILL Protokoll gengt, welches im Kapitel 5 in Bezug auf L2MP nher
erlutert wird. Dort erfolgt der Vergleich zwischen TRILL und seinem Alternative
Shortest Path Bridging.

2 Grundlagen
Die Netzwerkinfrastruktur in konventionellen Rechenzentren umfasst typischerweise die Switches, die sich in 3-Tier, zwar Core, Aggregation und Access, strukturieren, wie in Abbildung 1 dargestellt wird. In dieser Architektur funktionieren
Aggregation-/Core-Switches nach 1+1 Modell, d.h., ein Switch befindet sich in
Active-Zustand, das andere in Passive-Zustand und dient fr Redundanz auf Device-Level. Fr Redundanz auf Link-Level verbinden sich alle Switches auer Access-Switches auf Layer x mit einander und mit allen Switches auf Layer x 1. In
der Regel wird L2 Ethernet zwischen Access- und Aggregation-Layer implementiert und L3 IP zwischen Aggregation- und Core-Layer. Die Access-Switches sind
dafr verantwortlich, Konnektivitten fr Hosts bereitzustellen und Pakete zwischen Hosts in gleichem VLAN zu bermitteln. Die Aggregation-Switches sorgen
dafr, den Datenverkehr zwischen VLANs zu verteilen und diesen zu Core-Switches weiterzuleiten, wenn es sich zu anderen Netzmodulen richtet. Der Datenverkehr in dieser Architektur fliet mehrheitlich vom Norden zu Sden und umgekehrt.
Zur Eliminierung von Schleifen in redundanten Datenpfaden bestehen in konventionellen Rechenzentren einigen Methoden, die dieses Kapitel beschreibt, zwar die
Protokolle STP und MLAG. Die in der heutigen Rechenzentren zur Erhhung von
Bisektionsbandbreite hufig verwendete Topologie wird auch in diesem Kapitel
vorgestellt.
2.1 Spanning Tree Protocol
Fr schleifenlose Netze im L2 ist das Protokoll STP [5] erforderlich. Mit STP
werden die schleifenlosen Datenpfaden erzeugt, indem ein Link in der Schleife
blockiert wird. STP bildet einen Baum mit dem sogenannten Root-Bridge als
Wurzel, das nach einem Wahl-Prozess spezifiziert wird, und allen Switches als
Zwischen- und Blattknoten. Anfnglich beteiligen sich alle Switches am WahlProzess, wobei die Switches Bridge Protocol Data Unit (BPDU) Pakete austauschen. Diese BPDUs enthalten die fr den Wahl-Prozess relevanten Parameter.
Ein davon ist Bridge-ID, welche aus der vorkonfigurierten Prioritt und der MACAdresse des Switchs besteht. Wer die kleinste Bridge-ID besitzt, wird als RootBridge gewhlt. Alle Links, die sich mit Root-Bridge verbinden, bilden einen Baum
und die mit diesen Links assoziierten Ports befinden sich in Forwarding-Zustand.
Die Links, die nicht zum Baum gehren, werden abgeschaltet und die zugehrigen
Ports werden blockiert. Die Daten strmen lediglich durch die Pfade im Baum.
Beim Ausfall eines Links wird der in Block-Zustand befindliche Port freigeschaltet

und bernimmt die Verteilung des Datenverkehrs. Mit diesem Verfahren kann
STP wesentlich die Schleifen, die bei der Bereitstellung mehrerer physikalischen
Links und Switches entstehen, verhindern, whrend 50 Prozent der Bandbreite
vergeudet werden und die Frage, wie alle bereitgestellten physikalischen Ressourcen ausgebeutet werden, steht noch aus. Zusammengefasst bestehen die folgenden
Probleme bei STP in konventionellen Rechenzentren:
Limitierte Bandbreitennutzung: mit STP wird nur ein Datenpfad in
STP-Baum fr mehrere Kommunikationen zwischen Hosts genutzt. Da die
Kommunikation in modernen Rechenzentren hauptschlich zwischen Servern
erfolgt, limitiert STP die Bisektionsbandbreite, bedingt die Verschlechterung
von Oversubscription [2] und folglich die Kongestion auf geteilte Links. Mul1
tiple Vlan Spanning Tree (MVSTP) kann die Bandbreitennutzung zum Teil
optimieren, indem es fr eine Gruppe von VLAN eine Instanz von STP-Baum
kalkuliert. Die unterschiedlichen Kalkulierung ergeben sich unterschiedlichen
STP-Bume und verbessert daher die Effizient von Linknutzung. Jedoch erhht MVSTP den Konfigurationsaufwand und verlangt einen sorgfltigen
Plan fr die Zuweisung von VLANs zu jeder Instanz.
Nicht optimale Paketweiterleitung: alle Pakete mssen durch RootBridge als Extra-Hop durchflieen. Das ruft die Steigerung von Kommunikationslatenz ab, die fr zeitkritische Anwendungen vermieden werden soll. Bei
den Kommunikationen ber gleiche Root-Bridges kann es zum Stau auf den
Links zwischen diesen Root-Bridges kommen.
Kostenaufwndiges Scale-Up: in 3-Tier-Architektur sind AggregationSwitches Root-Bridges in einer STP-Domne. Je mehr Kommunikationen
stattfinden, desto hheren Backplane-Durchsatz sollen Root-Bridges aufweisen. Das Scale-Up der Aggregation-Switches ist aus kostenaufwndigem
Grund problematisch [2].
Langsame Konvergenz: Die Konvergenzzeit von STP hngt von der L2Topologie ab. Eine kleine Vernderung kann eine intensive Wiederberechnung der ganzen Topologie verursachen. Im schlechten Fall, dass das RootBrige ausfllt, muss ein neues Root-Bridge selektiert und die Berechnung des
Baums erneut durchgefhrt werden. Die Konvergenzzeit bei STP beluft sich
bei der Vernderung auf circa 15 Sekunden und bei der erneuten Berechnung

Siehe IEEE 802.1s

circa 50 Sekunden. Rapid Spanning Tree Protocol verbringt circa 2 Sekunden abhngig von der Topologie mit der Konvergenz. Jedoch bentigt RSTP
in komplexer Topologie eventuell bis zu 30 Sekunden zur Konvergenz [6].
Mit dieser Problematik ist STP fr SKDC nicht mehr geeignet. Eine alternative
Lsung fr L2MP ber Ethernet bietet das Protokoll MLAG an, das im folgenden
Unterkapitel beschrieben wird.
2.2 Multi Chassis Link Aggregation Protocol
MLAG ist zu diesem Zeitpunkt noch nicht standardisiert, sondern firmeneigen.
Das Verhalten von MLAG bei unterschiedlichen Firmen sieht zwar unterschiedlich
aus, aber beruht auf dem Standard IEEE 802.1AX 2008 (vorher 802.3ad) Link
Aggregation Control Protocol (LACP). LACP ermglicht es, eine Gruppe physischer Links zwischen zwei einzelnen Switches zu einem logischen Link, sogenannten LAG, zusammenzufassen. Durch diesen Ersatz wird Schleife zwischen miteinander ber mehr als zwei Links verbundenen zwei Switches ausgeschlossen. Die
Pakete werden mit einem Hashverfahren unter den Links in LAG verteilt. Auf
diese Art und Weise knnen bis zu acht physischen Links ohne Blockierung effizienter genutzt werden. MLAG macht sich LACP zunutze, so dass ein LAG zwischen einem physischen Switch und einem virtuellen System, welches sich aus einer
Gruppe vertrglicher Switches zusammensetzt, erstellt wird. Wie in Abbildung 1
gezeigt wird, kommunizieren AG1 und AG2 mit einander ber Inter-Switch-Link
3
(ISL) und bauen eine Domne auf, so dass Access-Switches AC1, AC2, AC3 zwei
Uplinks zu zwei Aggregation-Switches als die einem Switch gehrigen Links ansehen, weshalb die Bildung von LAG zwischen mehr als zwei Switches mglich ist.
Die Switches in einer MLAG-Domne werden als MLAG-Peer bezeichnet, ihre
Ports als Member-Ports, die sich an dem Aufbau von LAG mit dem Dritten beteiligen. Zwischen diesen Peers werden die Nachrichten ber ISL ausgetauscht, die
einen schleifenlosen Datenpfad gewhrleistet, indem die Informationen ber den
Abgleich von Konfigurationen, MAC-Adressen, Zustnden von Member-Ports von
MLAGs, usw. synchronisiert werden.
Die Verteilung der Pakete von Host A lsst sich in Abbildung 1 durch die gelben
und roten Pfeilen verdeutlichen. Hierbei findet ein Hashverfahren zur Bestimmung
des Links zur Paketweiterleitung statt. Datenverkehr zum anderen Modul wird an

Siehe IEEE 802.1w


ISL ist ein spezielles Link zwischen dedizierten Ports von Switches fr MLAG/Virtual Switching
Fabric
3

mit AG1 verbundenes Link bermittelt, whrend Pakete zu Host A in der Richtung zu AG2 flieen. Die beiden Links und Switches befinden sich deswegen in
Active-Active-Modus statt Active-Standby bei STP. Wenn ein von zwei Links
oder ein von zwei MLAG Peer versagt, werden die Pakete ber das restliche
Link/Switch weitergeleitet.
An das angegebene Prinzip halten sich die meisten Firmen bei dem Einsatz von
MLAG. Dabei handelt es sich um die Trennung von Control-Plane von MLAG
Peer, wie zB Cisco Virtual PortChannels (vPC) [10] und Arista Multi-Chassis
Link Aggregation (MLAG) [11]. Als Variante werden die Bildung und das Verhalten einiger MLAGs durch ein einheitliches Control-Plane kontrolliert, wie zB
Cisco Virtual Switching System (VSS) [7], HP Intelligent Resilient Framework
(IRF) [8] und Juniper Virtual Chassis (VC) [9]. In dieser Variante schlieen sich
physische Switches aneinander ber spezielle Links an und bilden dadurch ein
Virtual Switching Fabric (VSF). Ein Switch in VSF wird als Master ausgewhlt
und bernimmt die Kontrolle von Control-Plane und der Bildung von MLAG
zwischen den Mitgliedern von VSF und dem Dritten. Management wird aufgrund
des einheitlichen Control-Planes erleichtert.
Core
CO1

CO2

MC-LAG
Peer

Inter Switch
Link

Aggregation

Layer 3

AG1

AG2

MC-LAG
Member-Port

Access

Layer 2

AG1 AG2

MC-LAG
Domne

LAG
LACP

AC1

AC2

AC3

AC4
AC3

Host A

Host B

Abbildung 1: Konventionelle Netzinfrastruktur mit MLAG und STP


(angepasst aus der Abbildung von Cisco [11])

Problematisch bei MLAG sind:

Skalierbarkeit: Die Anzahl von MLAG Peer in einer Domne ist abhngig
von verwendeter Variante limitiert. Cisco vPC und Arista MLAG erlaubt nur
zwei Peers in einer Domne, whrend HP IRF die Anzahl von Peers auf vier
beschrnkt, Juniper VC auf 10. Fr die Skalierung ohne Schleife ist STP
notwendig, welches wiederum ineffiziente Bandbreitenutzung hervorruft.
Konfigurationsaufwand: Die Konfiguration von MLAG ist nicht automatisch, fehlerbehaftet und nicht trivial.
Managementaufwand von L2 MAC-Adressen: Alle Switches in MLAGDomne sowie Access-Switches mssen die Informationen ber MAC-Adressen aller Hosts im Rechnernetz bewahren. Mit der Verwendung von ServerVirtualisierung betrgt die Anzahl virtueller Maschinen (VM) mglicherweise
bis zu 100,000+. Die Verwaltung durch alle Switches in L2 Fabric ist dabei
unpraktisch.
Nicht vollstndige Bandbreitenutzung aufgrund von Hashverfahren: Die Verteilung des Datenverkehrs ist flussbasiert. Bei einem schlechten
Design dominiert ein Fluss mit groem Volumen wie zB periodischer BackupDatenverkehr ein Link. Das fhrt zur Erhhung von Ratio des Paketverwurfs
auf diesem Link.
Die 3-Tier-Architektur mit STP oder MLAG erweist sich wegen der gezeigten
Mankos als nicht effizient fr SKDC. Ein Ersatz fr 3-Tier-Architektur erbringt
eine neue Topologie Clos, die meistens in SKDCs verwendet wird [2, 3, 13, 14].
2.3 Clos-Netze
Die 3-Tier-Topologie traditioneller Rechenzentren stellt sich heraus, dass es lediglich fr Rechenzentren verwendbar ist, wenn die Mehrheit von Datenverkehr in
und aus diesen Rechenzentren hinein- und herausflieen. Die weiteren Nachteile
liegen darin, dass nicht nur geringe Bisektionsbandbreite zur Verfgung steht,
sondern es auch anfllig fr Netz-Zusammenbruch aufgrund des Ausfalls der Switches auf Aggregation-/ Core-Layer ist. Auch wenn Kapazitt von Switches und
Links vergrert wird, knnen die genannten Mankos radikal beseitigt werden, wie
bereits in 2.1 erwhnt wird. Daher sollen sich SKDCs auf Scale-Out-Paradigmen
konzentrieren, d.h., das moderne Netzwerk bietet durch die Kooperation der hohen
Anzahl simpler und gnstiger Switches hohe Kapazitt [14]. Solche Paradigmen
stellt Clos-Netze [12] dar, deren Topologie auf einer simplen Regel basiert: ein
Switch auf Tier x verbindet sich lediglich mit den auf Tier x 1 oder x + 1, aber
nicht mit den auf gleichem Tier, wie in Abbildung 2 illustriert wird. In dieser
Abbildung verbinden sich 32 Aggregations-Switches, die sogenannte Spines, mit

256 48-Port Access-Switches, die sogenannte Leafs und bilden ein Clos-Fabric,
welches bis zu 12,288 Server ohne Oversubscription bedienen. Ost-zu-West-Datenverkehr wird auf 32 Wege verteilt und die Bisektionsbandbreite erhht sich
dadurch.
Die Vorteile von Clos-Netze bestehen darin, dass diese sowohl einen hohen Redundanzgrad zur schnellen Resilienz, effektiven Fehlertoleranz und Lastverteilung liefern, als auch die effiziente Nutzung der Netzressourcen dank einer hohen Anzahl
redundanter Datenpfade ermglichen. Auerdem wird der hohen Bisektionsbandbreite zur Verfgung gestellt und ist gleich auf jedem Tier, so dass keine Oversubscription vorkommt. Allerdings existieren in dieser Topologie Schleifen, die durch
STP und MLAG ineffizient beseitigt werden, aber wirkungsvoll durch TRILL. Mit
dem Einsatz von TRILL steht Clos-basierte Architektur trotzdem in modernen
Rechenzentren hoch im Kurs und wird in dieser Arbeit verwendet.
Spine-Layer

32 Spines

Leaf-Layer

.
48-Port

256 Leafs
12288 Ports fr Server

Abbildung 1: Clos-basierte Architektur moderner Rechenzentren

3 Verwandte Arbeiten
4 Anforderungen fr L2MP im modernen Netzwerk
Zur Kompensierung angegebener Mankos konventioneller Rechenzentren stellt
L2MP in modernen Netzwerk von SKDC die nachstehenden Anforderungen.
A1 - Effizientere Bandbreitenutzung: infolge der intensiv internen Kommunikationen muss die Oversubscription minimiert bzh. Bisektionsbandbreite maximiert werden. Es soll mehrere schleifenlose L2 Datenpfade fr die

Kommunikation eines beliebigen Paars von End-Host bestehen. Fllt ein Datenpfad aus, knnen die anderen unmittelbar zur Verfgung stehen. Fr
bandbreitenintensive Applikationen soll das Netz so gestaltet, dass deren Datenverkehr nicht das geteilte Datenpfad dominiert. Es ist auch mglichst zu
vermeiden, dass nur auf einem Datenpfad oder einer Gruppe davon die Datenbertragungen erfolgen und die anderen inaktiv sind.
A2 - Optimale Paketweiterleitung: Der Datenverkehr vom beliebigen
Host zum Ziel soll ber optimalen Datenpfad flieen, um die Kommunikationslatenz zu verringern.
A3 - Fehlertoleranz und Skalierbarkeit: die Skalierung soll aufgrund der
Protokollspezifikationen oder technischer Einschrnkung minimal limitiert
werden. Es ist auch sinvoll, das Paradigma Scale-Out statt von Scale-Up
sin modernen Netzwerk mit minimalem Aufwand umzusetzen. Mit anderen
Worten sollen Netzwerk-Designer mehr Wert auf den Ersatz von 1+1 Architektur von Aggregation-/Core-Layer durch 1+n legen, um effektive Resilienz
und Fehlertoleranz zu gewinnen. Weiterhin soll die Fehlererkennung mglichst schnell, effektiv und zuverlssig sein und die fehlerhaften Komponenten
haben minimale Wirkung auf den Rest des Netzwerks.
A4 - Verwaltbarkeit: In der 1+n Architektur soll der Administrator von
der Konfiguration mglichst entlastet werden. Beim Auftreten von Fehler
knnen die fehlgeschlagenen Komponenten schnell und zuverlssig lokalisiert
werden. Mit der Inbetriebnahme zahlreicher Server bzw. virtueller Maschinen
sind das Lernen und die Speicherung von MAC-Adressen auf alle Switches
nahezu unmglich. Deshalb ist es idealer, sich die Verwaltung von MACAdressen auf der mglichst geringen Anzahl von Switches zu beschrnken.
Es ist zu erkennen, dass die Integration von L3 Routing auf L2 den meisten oberen
Anforderungen gerecht wird. Durch Routing-Protokoll verfgt jedes L2 Switch
ber eine umfassende Sicht auf die Topologie und kann die optimale Route zum
Ziel selektieren, whrend ECMP in L2 effizient vorhandene Multi-Path ausnutzen
kann. Die Motivation, sich L3 Routing in L2 zu integrieren, legt den Grundstein
fr die Entwicklung des Protokoll TRILL, welches die Schlsselvorteile der beiden
Layers unter einen Hut bringt. Kapitel 5 beschftigt sich tiefer mit diesem Protokoll.

5 Transparent Interconnection of Lots of Links


TRILL wird durch die IETF TRILL Arbeitsgruppe aus Huawei, Cisco und Brocade standardisiert und bereits von mehreren Firmen in die Tat umgesetzt, zwar
Broadcom, Cisco, IBM, Huawei, Mellanox, ZTE. Es vererbt die Vorteile von L2
Switching (Einfachheit, Flexibilitt) und L3 Routing (Skalierbarkeit, Stabilitt,
schnelle Konvergenz, effizientes Multi-Pathing), die TRILL zu einem idealen Protokoll fr das massiv skalierbare flache L2-Netwerk in Rechenzentren mit dem
intensiven Volumen Ost-zu-West-Datenverkehr befhigt. TRILL luft direkt auf
dem L2 und gehrt im Prinzip zur Overlay-basierten Architektur. Ein Overlay
wird als einen dynamischen Tunnel zwischen zwei beliebigen Leaf-Switches A und
B verstanden, ber den Ethernet-Frames von den sich mit A verbundenen Hosts
zu den sich mit B assoziierten Hosts und umgekehrt transportiert werden. Dabei
sind Spine-Switches eine Komponente des Tunnels und sorgen lediglich fr die
Weiterleitung von Frame, ohne die Anwesenheit von Host in Rechenzentren bercksichtigen zu mssen. Dazu wird die Methode MAC-in-MAC-Verkapselung auf
TRILL angewendet. Die weiteren Unterkapitel beschreiben ausfhrlicher den Konzept und die auf TRILL angewendeten Mechanismen.
5.1 Konzept und Mechanismus
TRILL verwendet das Intermediate Systems-Intermediate Systems (IS-IS) [16]
Routing-Protokoll als Control-Plane zum Austausch der Informationen ber die
Erreichbarkeit aller TRILL realisierten Switches, die als RBridges (Routing Bridges) genannt werden. Der Grund fr die Auswahl von IS-IS liegt darin, dass IS-IS
direkt auf dem L2 operiert und keine L3 IP-Adresse wie die anderen RoutingProtokolle bentigt werden. Daneben ist IS-IS simple durch die Definition vom
neuen Type-Length-Value (TLV) oder Sub-TLV die Informationen ber TRILL zu
bertragen. Die RBridges vernetzen sich miteinander und bilden dadurch ein
TRILL-Netz, welches sich mit den regulren Ethernet-Netzen ber Ingress- und
Egress-RBridges verbinden kann. Abhngig von der Richtung von Datenfluss fgt
das RBridge dem nativen Frame ein TRILL-Header hinzu und dieses Frame an
das TRILL-Netz weiterleitet, oder entfernt das TRILL-Header aus dem Frame,
bevor es dieses an das Nicht-TRILL-Netz sendet. Der erste Fall bezieht sich auf
die Ingress-Switches und der letztere auf die Egress-Switches. Die Core-RBridges
schlieen sich nur mit den anderen RBridges an und nicht mit den Nicht-TRILLNetzen.
Im TRILL-Netz wird jedes RBridge durch einen 16-Bit Nicknamen und eine System-ID fr den IS-IS-Prozess identifiziert. Die Nicknamen lassen sich manuell oder

automatisch vergeben. Zur Minimierung des Verwaltung- bzw. Konfigurationsaufwands wird die zweite Option oftmals bevorzugt, kann allerdings zur Kollision von
Nicknamen fhren. Diese Situation lsst sich vermeiden, indem die anderen ber
seinen Nicknamen in Nickname-Sub-TLV von IS-IS mit einer Prioritt informiert.
Bei der Kollision ist der Besitzer dieses Namens dasjenige, das die hhere Prioritt
aufweist. Falls zwei Switches ber die gleiche Prioritt verfgen, werden ihren ISIS System-ID betrachtet. Auerdem ist ein eindeutiger Nickname dadurch sicherzustellen, dass es aus der System-ID, dem Datum und den anderen systemspezifischen Parametern wie zB Temperatur generiert wird. Die Nicknamen sind flache
Adressen im Vergleich zu Ethernet-MAC-Adressen und dienen als ein Ma fr die
Erreichbarkeit zu allen RBridges. Mit anderen Worten treffen RBridges die Entscheidung fr Pakete-Routing basierend auf den Nicknamen, wie es sich bei L3 IPRouting verhlt. Bei der Routing-Entscheidung betrachten die RBridge die Nicknamen-Felder in TRILL-Header, dessen Format in Abbildung 3 dargestellt wird.
Inner DA
(6B)

Inner SA
(6B)

Optional

Outer DA
(6B)

Outer SA
(6B)

Outer VLAN
(4B)
16 bits

Payload

FCS

Payload

New
FCS

Original Ethernet Frame

TRILL Header
(8B)
2, 2, 1, 5, 6 Bits

EtherType
0x22F3

Inner VLAN
(4B)

V, R, M, Optl,
Hop_Count

Inner DA
(6B)

16 bits

Egress
Nickname

Inner SA
(6B)

Inner VLAN
(4B)

16 bits

Ingress
Nickname

Abbildung 2: Format von TRILL-Frame

Die TRILL-Verkapselung ist grundstzlich eine MAC-in-MAC-Verkapselung mit


dem TRILL-Header in der Mitte des Frames. Die Hauptfelder im TRILL-Header
sind Egress Nickname, Ingress Nickname, das Mehrfachziel-Flag-Bit M und
Hop_Count. Die Outer DA (Destination MAC-Address) und Outer SA
(Source MAC-Address) entsprechen der MAC-Adresse von Next-Hop-Switch und
von Sender. Diese werden auf jedem TRILL-Hop umgeschrieben, whrend Egress
Nickname und Ingress Nickname unverndert bleiben und deshalb jeweilst mit
Ziel- und Quellen-IP-Adressen vergleichbar sind. In Unicast-Frames gehrt Egress
Nickname zum Egress Switch und in Merhfachziel-Frames wie Multicast/Broadcast- oder unbekannten Unicast-Frames zum RBridge, das der Wurzel eines
Verteilungsbaums fr Mehrfachziel-Frames ist und als Verteilungsbaum-Identifier
bezeichnet wird. Im letzten Fall wird das Bit im Feld M im TRILL-Header von
0 (Unicast) auf 1 (Multicast) gesetzt. Das Feld Ingress Nickname beinhaltet den
Nicknamen von Ingress Bridge. Das auffllige Feld im TRILL-Header stellen die
6 Bits von Hop_Count dar, dessen Funktionalitt similr zu Time-To-Live
(TTL) im IP-Header ist. Fr bekannte Unicast-Frames stellt das Ingress-RBridge

das Hop_Count so eingestellt, dass dessen Wert die Anzahl von Hops von sich
selbst zum Egress-Bridge als Emfnger berschreitet, damit die alternative Route
mit lngerem Weg beim Ausfall der besten Route in Verwendung sein kann. Fr
Mehrfachziel-Frames must dieser Wert grer als die Anzahl von Hops zum entferntesten Egress-RBridge sein. Im Gegenteil zu TTL reduzieren die Core-RBrid4
ges beim Emfang eines Frames den Wert vom Hop_Count um 1 . Ist der Wert
vom Hop_Count gleich 0, wird das entsprechende Frame verworfen und eine Benachrichtigung zum Sender gesendet. Mittels des Felds Hop_Count kann die unendliche Schleife im TRILL-Netz nicht mehr existieren. Die genaueren Informationen ber alle Felder im TRILL-Header sind in [15] anzufinden.
Analog zu Layer 3 Routing mssen die Informationen ber die Nicknamen aller
RBridges vor der Routing-Entscheidung in der Routing-Tabelle durch ein Routing-Protokoll vorhanden sein. Wie am Anfang des Kapitels erwhnt ist IS-IS dafr zustndig. IS-IS ist ein ISO Standard und wie Open Shortest Path First ein
Link-State Routing-Protokoll, wobei nur die Routing-Informationen in Bezug auf
Konnektivitt ausgetauscht und erst bei der Vernderung aktualisiert werden, anstatt periodisch die smtliche Routing-Tabelle wie im Distanzvektor-Routing-Protokollen zu teilen. Dis

5.2 L2MP durch TRILL


Data-Plane von TRILL
5.3 Bewertung und Alternative

Die Vermeidung von Schleifen und der Erbring eines robusten Mechanismus zur Schleifenerkennung

Die effiziente Linknutzung durch ECMP

Schnelle Konvergenz und Wiederherstellung nach Netzausfall

Plug-and-Play bei Konfiguration

Prvention von Lernen und Verwalten von MAC-Adressen auf Core-/Aggregation/Spine-Layer

Gewhrleistung einheitliches Control-Protokoll fr Unicast und Multicast, Lastverteilung nicht nur fr Unicast, sondern auch fr Multicast

Dieses Reduzierung-Verhalten ist fr die zuknftige Traceroute-hnliche Methode ausgelegt.

6 Fazit und Ausblick


7 Referenz
[1]

Cisco Global Cloud Index: Prognose und Methodik, 2012-2017, White Paper, 2013.

[2]

Al-Fares, Mohammad, Alexander Loukissas und Amin Vahdat. "A scalable, commodity data center network architecture." ACM SIGCOMM Computer Communication
Review. Vol. 38. No. 4. ACM, 2008.

[3]

Greenberg, Albert, et al. "Towards a next generation data center architecture: scalability and commoditization." Proceedings of the ACM workshop on Programmable
routers for extensible services of tomorrow. ACM, 2008.

[4]

Niranjan Mysore, Radhika, et al. "Portland: a scalable fault-tolerant L2 data center


network fabric." ACM SIGCOMM Computer Communication Review. Vol. 39. No. 4.
ACM, 2009.

[5]

R. Perlman. "An Algorithm for Distributed Computation of a Spanning Tree in an


Extended LAN". ACM SIGCOMM Computer Communication Review. Vol. 15. No.
4, 1985; S 44-53

[6]

Lapukhov,
Petr.
Unterstanding
STP
and
RSTP
Convergence,
http://blog.ine.com/wp-content/uploads/2011/11/understanding-stp-rstp-convergence.pdf, abgerufen am 20.12.2014; S 32

[7]

Cisco System. "Cisco Catalyst 6500 Series Virtual Switching System."


http://www.cisco.com/c/dam/en/us/products/collateral/interfaces-modules/network-modules/white_paper_c11_429338.pdf , abgerufen am 22.12.2014

[8]

Hewlett-Packward Company. "Reducing Network Complexity, Boosting Performance


with HP IRF Technology." http://h17007.www1.hp.com/docs/reports/irf.pdf, abgerufen am 22.12.1014.

[9]

Juniper Networks. "Network Simplification with Juniper Networks Virtual Chassis


Technology." http://www.juniper.net/us/en/local/pdf/whitepapers/2000427-en.pdf,
abgerufen am 22.12.2014.

[10] Arista. "Multi-Chassis Link Aggregation." https://www.arista.com/assets/data/pdf/AristaMLAG_tn.pdf, abgerufen am 22.12.2014.


[11] Cisco System. Cisco NX-OS Software Virtual PortChannel: Fundamental Concepts
5.0. http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-seriesswitches/design_guide_c07-625857.html, abgerufen am 22.12.2014
[12] Clos, Charles. "A Study of NonBlocking Switching Networks." Bell System Technical
Journal 32.2 (1953): 406-424.

[13] Cisco System. Virtualized Multiservice Data Center (VMDC) 3.0.1 Design Guide.
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/VMDC/3-0-1/DG/VMDC_3-0-1_DG.pdf, abgerufen am 25.12.2014
[14] Greenberg, Albert, et al. "VL2: a scalable and flexible data center network."ACM
SIGCOMM Computer Communication Review. Vol. 39. No. 4. ACM, 2009.
[15] Radia Perlman und et al. "RBridges: Base Protocol Specification." RFC 6325, 2010.
[16] Oran, David. "OSI IS-IS intra-domain routing protocol." RFC 1142, 1990.
[17] Radia Perlman und et al. "TRILL: Use of IS-IS." RFC 6325, 2011.
[18] Perlman, Radia. "Challenges and Opportunities in the Design of TRILL: a Routed L2
Technology." GLOBECOM Workshops, IEEE. 2009.