DE112016007055B4

DE112016007055B4 - Querverbindung von Switches auf der Basis eines hierarchischen Overlay-tunneling

Info

Publication number: DE112016007055B4
Application number: DE112016007055.1T
Authority: DE
Inventors: Phanidhar Koganti
Original assignee: Avago Technologies International Sales Pte Ltd
Current assignee: Avago Technologies International Sales Pte Ltd
Priority date: 2015-12-07
Filing date: 2016-11-18
Publication date: 2024-05-08
Anticipated expiration: 2036-11-19
Also published as: DE112016005600T5; WO2017099971A1; CN108476160A; US9912614B2; WO2017099971A4; US20170163569A1; DE112016005600B4; CN108476160B

Abstract

Switch (358, 700), der Folgendes aufweist:eine Tunnelverwaltungsvorrichtung (722), die dafür konfiguriert ist, einen lokalen Inter-Switch-Tunnel (118, 122, 507) und einen Inter-Fabric-Tunnel (120, 366, 630) aufrecht zu erhalten, wobei der lokale Inter-Switch-Tunnel (118, 122, 507) eine Kommunikation zwischen dem Switch (113, 121, 123) und einem zweiten Switch (113, 121, 123) in einem ersten Netzwerk (104, 106, 108, 140, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht, und wobei der Inter-Fabric-Tunnel (120, 366, 630) eine Kommunikation mit einem dritten Switch (113, 121, 123) in einem zweiten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht; undeine Paket-Header-Verwaltungsvorrichtung (720, 732), die dafür konfiguriert ist, einen ersten Tunnel-Header eines Pakets (332), das ausgehend von dem lokalen Inter-Switch-Tunnel (118, 122, 507) empfangen wird, zu entkapseln und das Paket (332) mit einem zweiten Tunnel-Header für die Übertragung über den Inter-Fabric-Tunnel (120, 366, 630) einzukapseln, wobeider Switch (358, 700) dafür konfiguriert ist, zu verhindern, dass ein Paket (332), das ausgehend von einem Inter-Fabric-Tunnel (120, 366, 630) empfangen wird, auf einem anderen Inter-Fabric-Tunnel (120, 366, 630) weitergeleitet wird, und das Paket (332) nur auf einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) weiterzuleiten, über den Switches (105, 111) innerhalb einer Netzwerks (104, 106, 108, 140) miteinander verbunden sind.

Description

HINTERGRUND
Gebiet
Die vorliegende Offenbarung bezieht sich auf Kommunikationsnetzwerke. Genauer gesagt bezieht sich die vorliegende Offenbarung auf ein System und ein Verfahren für den Aufbau eines skalierbaren Switching-Systems bzw. Vermittlungssystems auf der Basis eines hierarchischen Overlay-Tunneling.
Stand der Technik
Das exponentielle Wachstum des Internet hat dieses zu einem populären Übermittlungs- bzw. Liefermedium für eine Vielfalt von Anwendungen gemacht, die auf physikalischen bzw. physischen und virtuellen Geräten bzw. Vorrichtungen laufen. Solche Anwendungen haben eine gesteigerte Nachfrage nach Bandbreite mit sich gebracht. Als Folge davon wetteifern die Ausrüstungsanbieter darin, größere und schnellere Switches (Schalter, Netzschaltwerke, Vermittlungsstellen) mit vielfältigen Fähigkeiten, wie etwa Netzwerkvirtualisierung und Mandantenfähigkeit, zu bauen, um diverse Netzwerkanforderungen effizient zu befriedigen. Aber die Größe eines Switch kann nicht bis ins Unendliche wachsen. Diese ist durch den physischen Raum, den Stromverbrauch und durch die Design-Komplexität beschränkt, um nur ein paar Faktoren zu nennen. Des Weiteren sind Switches mit einer höheren Leistungsfähigkeit für Gewöhnlich viel komplexer und kostspieliger. Und was noch wichtiger ist, da ein allzu großes und komplexes System oftmals keine Wirtschaftlichkeit durch Massenproduktion vorsieht, kann sich das einfache Vergrößern der Größe und der Leistungsfähigkeit eines Switch aufgrund der erhöhten Kosten pro Port als wirtschaftlich unrentabel erweisen.
Eine Möglichkeit, den Durchsatz eines Switch-Systems zu steigern, ist die Verwendung eines Layer-2-Switch-Stacking (Schicht-2-Switch-Stapelung). Bei einem Switch-Stacking (Switch-Stapelung) werden mehrere kleinere identische Switches in einem speziellen Muster miteinander verbunden bzw. querverbunden, um einen grö-ßeren logischen Switch zu bilden. Aber das Switch-Stacking erfordert eine sorgfältige Konfiguration der Ports und der Inter-Switch-Links, also der Verbindungen zwischen den Switches. Der Umfang der benötigten manuellen Konfiguration wird äußerst komplex und mühsam, wenn der Stack bzw. Stapel eine gewisse Größe erreicht, was es ausschließt, dass das Switch-Stacking eine praktische Option beim Aufbauen eines großen Switching-Systems ist. Des Weiteren hat ein System, das auf gestapelten Switches basiert, aufgrund von Bandbreitenerwägungen oftmals Topologie-Beschränkungen, die die Skalierbarkeit des Systems einschränken.
Eine flexible Möglichkeit, die Skalierbarkeit eines Switch-Systems zu verbessern, liegt darin, eine Querverbindung von Switches aufzubauen, die in einer kohäsiven Weise gesteuert werden kann; diese Switches können sich oftmals ein einziges logisches Chassis oder eine einzige Steuerebene teilen (was als „Fabric Switch“ bezeichnet wird). Ein Fabric Switch ist eine Ansammlung von einzelnen Mitglieds-Switches (Member Switches). Diese Mitglieds-Switches bilden ein Netzwerk von miteinander verbundenen Switches, das eine beliebige Anzahl an Ports und eine beliebige Topologie haben kann. Wenn die Anforderungen steigen, können Kunden ein sogenanntes „Pay as you grow“-(Zahlen nach Wachstum)-Konzept wählen, um die Kapazität des Fabric Switch zu vergrößern.
Obwohl ein Fabric Switch wünschenswerte Eigenschaften bringt, bleiben einige Aspekte bei der effizienten Gestaltung und dem Datentransport eines skalierbaren Fabric Switch ungelöst.
Eine Herausforderung, die bestehen bleibt, liegt darin, dass, da Layer-2-Netzwerke immer allgegenwärtiger werden, erweiterte Layer-2-Broadcast-Domains eine zunehmende Anzahl an MAC-(Medium Access Control; Medienzugriffssteuerungs)-Adressen hosten. Außerdem verschärft das Aufkommen des Cloud Computing auf der Basis von virtuellen Maschinen das Wachstum der Anzahl an MAC-Adressen. Wie eine solche große Anzahl an MAC-Adressen verwaltet werden soll, während gleichzeitig die Fähigkeit zur Abwicklung einer großen Menge an Layer-2-Verkehr bereitgestellt wird, bleibt ein Hauptproblem für Netzwerkausrüstungsanbieter.
US 2015 / 0 333 967 beschreibt einen Switch mit einem Netzwerkerweiterungsmodul, das eine Zuordnung zwischen einer ersten Kennung eines virtuellen lokalen Netzwerks (VLAN) und einer ersten globalen VLAN-Kennung einer Netzwerkerweiterungsgruppe verwaltet.
US 2015 / 0 117 256 A1 beschreibt einen Switch mit einem Fabric-Switch-Modul, welches eine Mitgliedschaft in einem ersten Fabric-Switch beibehält, wobei das Fabric-Switch mehrere Switches umfasst und als einzelner Switch arbeitet.
EP 2 940 952 A1 beschreibt ein Verfahren und System zur Erleichterung der Switch-Virtualisierung in einem Netzwerk von miteinander verbundenen Switches.
US 2009 / 0 129 389 A1 beschreibt ein Verfahren zur Verwaltung von Datenübertragungsblöcken in einem globalen Kommunikationsnetz, das eine Vielzahl von Teilnetzen umfasst, die durch Tunnel miteinander verbunden sind, an deren Enden sich Tunnelendpunkte befinden..
KURZFASSUNG
Es ist eine Aufgabe der vorliegenden Erfindung, einen Switch, ein Verfahren und ein Datenverarbeitungssystem bereitzustellen, welche die beim Stand der Technik auftretenden Probleme lösen.
Diese Aufgabe wird erfindungsgemäß durch einen Switch mit den Merkmalen des Anspruchs 1, ein Verfahren mit den Merkmalen des Anspruchs 9 und ein Datenverarbeitungssystem mit den Merkmalen des Anspruchs 17 gelöst.
Vorteilhafte Weiterbildungen ergeben sich aus den abhängigen Unteransprüchen.
KURZE BESCHREIBUNG DER FIGUREN

1A veranschaulicht eine beispielhafte Fabric-Switch-Architektur in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
1B veranschaulicht eine beispielhafte Weiterleitungsmethode mit Gruppen von hierarchischen Overlay-Tunneln in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
1C veranschaulicht eine beispielhafte Switch-Kennungs-Mapping-Tabelle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
1D veranschaulicht eine beispielhafte VLAN-(Virtual Local Area Network; virtuelles lokales Netzwerk)-Mapping-Tabelle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
2A zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der Intra-Fabric-Tunnel in einem Fabric Switch herstellt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
2B zeigt ein Ablaufdiagram, das einen beispielhaften Prozess eines Switch, der Switch-Kennungen auf Weiterleitungsinformationen mappt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
2C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der Dialog-MAC-Adressen in der Weiterleitungs-Hardware aufrecht erhält bzw. bewahrt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
3A veranschaulicht eine beispielhafte Paket-Header-Konfiguration zum Übertragen einer Fabric-Switch-Kennung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
3B veranschaulicht eine beispielhafte Paket-Header-Konfiguration zum Übertragen einer Fabric-Switch-Kennung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
3C veranschaulicht einen beispielhaften Prozess für das Weiterleiten eines Pakets von einem Ende zum anderen Ende quer durch Fabric Switches in Übereinstimmung mit der vorliegenden Erfindung.
4A zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einem Edge Port empfangen wird, in Übereinstimmung mit der vorliegenden Erfindung veranschaulicht.
4B zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einem Tunnel empfangen wird, in Übereinstimmung mit der vorliegenden Erfindung veranschaulicht.
4C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Backbone Node (Backbone-Knoten), der ein Multi-Ziel-Paket weiterleitet, das ausgehend von einem Tunnel empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
5A veranschaulicht eine beispielhafte MLAG (Multi-chassis Link Aggregation Group) mit einem virtuellen Tunnel-Endpunkt in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
5B zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einer MLAG empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
5C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Backbone Node, der ein Paket mit einer MLAG-Kennung weiterleitet, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
6 veranschaulicht eine beispielhafte Konfiguration eines Fabric Switch auf der Basis von hierarchischen Overlay-Tunneln in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
7 veranschaulicht einen beispielhaften Mitglieds-Switch in einem IPbasierten Fabric Switch in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.

In den Figuren bezeichnen gleiche Bezugszeichen die gleichen Figurenelemente.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung wird vorgelegt, um einen Fachmann auf dem Gebiet in die Lage zu versetzen, die Erfindung auszuführen und diese verwenden zu können, und die Beschreibung wird in dem Kontext einer bestimmten Anwendung und deren Anforderungen vorgesehen. Verschiedene Modifikationen bei den offenbarten Ausführungsformen werden den Fachleuten auf dem Gebiet ohne Weiteres ersichtlich sein, und die allgemeinen Prinzipien, die hier definiert sind, können auf andere Ausführungsformen und Anwendungen angewendet werden, ohne dass von dem Erfindungsgedanken und dem Schutzumfang der vorliegenden Erfindung abgewichen wird. Somit ist die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt, sondern ihr soll der breiteste Schutzumfang, der mit den Ansprüchen vereinbar ist, zugesprochen werden.
Überblick
In Ausführungsformen der vorliegenden Erfindung ist das Problem des Aufbauens eines vielseitigen, kosteneffektiven und skalierbaren Layer-2-Switching-Systems dadurch gelöst, dass eine Topologie-agnostische Fabric Switch auf der Basis eines Underlay-Layer-3-Protokolls mit einem hierarchischen Overlay-Tunneling gebildet wird. Diese neue Fabric-Switch-Architektur kann einen oder mehrere Fabric Switches umfassen, die durch ein Underlay-Netzwerk miteinander verbunden bzw. querverbunden sind, das auf existierenden Layer-3- und Tunneling-Protokollen, wie etwa IP und VXLAN (Virtual Extensible LAN) sowie auch auf proprietären Protokollen basieren kann. Jeder Fabric Switch kann eine Anzahl an physischen Switches umfassen, die durch ein ähnliches Underlay-Netzwerk miteinander verbunden sind, das die gleichen Layer-3- und Tunneling-Protokolle verwendet. Wie in späteren Abschnitten der vorliegenden Offenbarung noch ausführlicher beschrieben werden wird, wird das Problem der Handhabung einer großen Anzahl an MAC-Adressen in einer erweiterten Layer-2-Broadcast-Domain dadurch gelöst, dass ein hierarchischer Tunneling-Mechanismus und ein Label-basierter Fabric-bezogener Adressenaggregationsmechanismus vorhanden sind.
Innerhalb eines Fabric Switch kann eine voll vermaschte logische Topologie zwischen allen Switches, die das Underlay-Tunneling-Protokoll verwenden, hergestellt werden. Mit anderen Worten, zwei beliebige Switches innerhalb einer Fabric können miteinander über einen direkten logischen Link, also eine direkte logische Verbindung, oder über einen Intra-Fabric-Tunnel auf der Grundlage dieser voll vermaschten logischen Topologie kommunizieren. Insbesondere dann, wenn diese Switches Layer-2-Funktionalitäten implementieren, können sie eine Ethernet Fabric bilden. Als Folge davon kann eine Ethernet-Broadcast-Domain jeden Switch innerhalb der Fabric auf der Basis dieser voll vermaschten logischen Topologie erreichen.
Wenn mehrere Fabric Switches miteinander verbunden sind und eine Layer-2-Broadcast-Domain quer über mehr als einen Fabric Switch ausgedehnt ist, können Inter-Fabric-Tunnel eingerichtet werden, um eine Inter-Fabric-Kommunikation zu ermöglichen. Pakete, die eine Fabric verlassen, können in diesen Inter-Fabric-Tunneln eingekapselt werden und zu der entfernten Fabric transportiert werden. Jede Fabric kann ein oder mehrere Inter-Fabric-Gateways haben, die für das Aufrechterhalten dieser Inter-Fabric-Tunnel zuständig sein können.
Eine Herausforderung beim Aufbauen einer großen Layer-2-Broadcast-Domain liegt darin, wie eine große Anzahl von MAC-Adressen, die erwartungsgemäß innerhalb der Broadcast-Domain erreichbar sind, und das zugehörige MAC-Adressen-Lernen gehandhabt werden sollen. Eine Möglichkeit zur Lösung dieses Problems ist, alle MAC-Adressen innerhalb eines Fabric Switch mit einem Label für diese Fabric zu verknüpfen, das auch als eine Kennung für die Fabric dienen kann. Wenn ein Ethernet-Paket eine Fabric betritt, wird dessen Zieladresse (DA; Destination Address) auf das entsprechende Label der Ziel-Fabric (Destination Fabric) gemappt bzw. abgebildet, und es wird zu der entfernten Fabric auf der Basis dieses Labels der Ziel-Fabric weitergeleitet. Wenn das Paket dann die Ziel-Fabric erreicht, wird es aus dem Inter-Fabric-Tunnel entkapselt und zu dem Ziel-Ausgangs-Switch unter Verwendung eines Intra-Fabric-Tunnels weitergeleitet.
Es gibt eine Anzahl von Möglichkeiten, die Mapping-Beziehung zwischen einer MAC DA und einer Fabric ID (d.h. dem Label der Fabric) herzustellen. Dieses Mapping kann in der Datenebene durch das Lernen aus einem anfänglichen Broadcast-Paket (Rundsendepaket) ausgeführt werden, wobei während dieses Prozesses eine MAC-Quelladresse (MAC SA (Source Address)) eines Pakets auf ihre Quell-Fabric ID (Source Fabric ID) gemappt wird. Diese Informationen können auch in der Steuerebene unter Verwendung eines Steuerprotokolls verbreitet werden, wenn eine oder mehrere MAC-Adressen mit einer entfernten Fabric assoziiert sind. Ein dritter Lösungsansatz ist, eine Kombination aus sowohl datenebenen- als auch steuerebenenbasierten Methoden zu verwenden, die es erlauben, dass eine lokale Fabric das MAC-auf-Fabric-ID-Mapping in einer entfernten Fabric auf der Basis eines lokalen Lernvorgangs und/oder einer Steuerebenennachricht erfährt.
Der oben erwähnte hierarchische Overlay-Tunneling-Mechanismus und der Label-basierte Adressenaggregationsmechanismus können eine vielseitige und skalierbare Fabric-Switching-Lösung bereitstellen, die viele der Probleme löst, die in den aktuellen Fabric-Architekturen vorhanden sind.
Es sollte angemerkt werden, dass ein Fabric Switch nicht das Gleiche ist wie ein herkömmliches Switch-Stacking. Beim Switch-Stacking werden mehrere Switches an einer gemeinsamen Stelle (oftmals innerhalb desselben Gestells) auf der Basis einer bestimmten Topologie miteinander verbunden und manuell auf eine bestimmte Weise konfiguriert. Diese gestapelten Switches teilen sich typischerweise eine gemeinsame Adresse, z.B. eine IP-Adresse, so dass sie extern als ein einziger Switch angesprochen werden können. Des Weiteren erfordert das Switch-Stacking einen beträchtlichen Umfang an manueller Konfiguration der Ports und Inter-Switch-Links. Der Bedarf an manueller Konfiguration verhindert, dass das Switch-Stacking eine brauchbare Option beim Aufbauen eines großen Switching-Systems ist. Die Topologie-Beschränkungen, die durch das Switch-Stacking auferlegt werden, begrenzen auch die Anzahl an Switches, die gestapelt werden können. Dies liegt daran, dass es sehr schwierig, wenn nicht unmöglich ist, eine Stapel- bzw. Stack-Topologie zu entwerfen, die eine adäquate Skalierung der Gesamt-Switch-Bandbreite mit der Anzahl an Switch-Einheiten erlaubt.
Im Gegensatz dazu kann ein Fabric Switch eine beliebige Anzahl an Switches mit individuellen Adressen umfassen, er kann auf einer beliebigen physikalischen Topologie basieren und er erfordert keine extensive manuelle Konfiguration. Die Switches können sich an derselben Stelle befinden oder sie können über verschiedene Stellen verteilt sein. Diese Merkmale überwinden die inhärenten Begrenzungen des Switch-Stacking und machen es möglich, eine große „Switch Farm“ aufzubauen, die als ein einziger logischer Switch behandelt werden kann. Aufgrund der automatischen Konfigurationsfähigkeiten der Fabric Switch kann sich ein individueller physischer Switch dem Fabric Switch dynamisch anschließen oder diesen verlassen, ohne dass Dienste bzw. Services zu dem Rest des Netzwerks unterbrochen werden.
Des Weiteren erlaubt es die automatische und dynamische Konfigurierbarkeit des Fabric Switch einem Netzwerkbetreiber, sein Switching-System in einer verteilten und „Pay as you grow“-Weise aufzubauen, ohne dass die Skalierbarkeit auf der Strecke bleibt. Die Fähigkeit des Fabric Switch, auf sich ändernde Netzwerkbedingungen zu reagieren, macht diesen zu einer idealen Lösung in einer virtuellen Datenverarbeitungsumgebung, in der sich Netzwerklasten mit der Zeit oftmals ändern.
Es sollte auch angemerkt werden, dass sich ein Fabric Switch von einem VLAN unterscheidet. Ein Fabric Switch kann eine Vielzahl von VLANs aufnehmen. Ein VLAN ist typischerweise durch einen VLAN-Tag (VLAN-Idenfizierungskennzeichen) identifiziert. Im Gegensatz dazu ist der Fabric Switch durch eine Fabric-Kennung (z.B. eine Cluster-Kennung) identifiziert, die dem Fabric Switch zugewiesen ist. Da ein Fabric Switch als ein logisches Chassis dargestellt werden kann, kann die Fabric-Kennung auch als eine logische Chassis-Kennung bezeichnet werden. Ein jeweiliger Mitglieds-Switch des Fabric Switch ist mit der Fabric-Kennung assoziiert. In einigen Ausführungsformen wird einem Mitglieds-Switch eine Fabric-Switch-Kennung vorab zugewiesen. Als Folge davon identifizieren dann, wenn sich der Switch einem Fabric Switch anschließt, andere Mitglieds-Switches den Switch als einen Mitglieds-Switch des Fabric Switch.
In der vorliegenden Offenbarung bezieht sich der Begriff „Fabric Switch“ auf eine Anzahl von miteinander verbundenen bzw. querverbundenen physischen Switches, die ein einziges, skalierbares Netzwerk von Switches bilden können. Die Mitglieds-Switches des Fabric Switch können als individuelle Switches arbeiten. Die Mitglieds-Switches des Fabric Switch können auch als ein einzelner logischer Switch in der Bereitstellungs- und Steuerebene, der Datenebene oder in beiden arbeiten. Der Begriff „Fabric Switch“ soll nicht als Ausführungsformen der vorliegenden Erfindung auf eine Vielzahl von Switches, die als ein einziger logischer Switch arbeiten, beschränkend interpretiert werden. In der vorliegenden Offenbarung werden die Begriffe „Fabric Switch“ und „Fabric“ austauschbar benutzt.
Obwohl die vorliegende Offenbarung unter Verwendung von Beispielen dargelegt wird, die auf einem Verkapselungsprotokoll bzw. Einkapselungsprotokoll basieren, sind Ausführungsformen der vorliegenden Erfindung nicht auf Netzwerke beschränkt, die unter Verwendung eines bestimmten Verkapselungsprotokolls definiert sind, das mit einer bestimmten OSI-Referenzmodell-Schicht (Open System Interconnection Reference Model layer) assoziiert ist. Ausführungsformen der vorliegenden Erfindung können zum Beispiel auch bei einem MPLS-(Multi-Protocol Label Switching)-Netzwerk angewendet werden. In der vorliegenden Offenbarung wird der Begriff „Verkapselung“ oder „Einkapselung“ in einem generischen Sinne verwendet und kann sich auf eine Verkapselung bzw. Einkapselung in jeglicher Networking-Schicht bzw. Vermittlungsschicht, Teilschicht oder in einer Kombination von Networking-Schichten beziehen.
Der Begriff „End Host“ kann sich auf jegliche Vorrichtung bzw. jegliches Gerät außerhalb eines Netzwerks beziehen (z.B. dieser führt keine Weiterleitung in diesem Netzwerk durch). Beispiele für einen End Host umfassen, ohne darauf beschränkt zu sein, eine physische oder virtuelle Maschine, einen herkömmlichen Layer-2-Switch, einen Layer-3-Router oder irgendeine andere Art von Netzwerkvorrichtung bzw. - gerät. Außerdem kann ein End Host an andere Switches oder Hosts gekoppelt sein, die sich weiter weg von einem Layer-2- oder Layer-3-Netzwerk befinden. Ein End Host kann auch ein Zusammenschlusspunkt bzw. Aggregationspunkt für eine Anzahl von Netzwerkgeräten für den Zutritt zum Netzwerk sein. Ein End Host, der eine oder mehrere virtuelle Maschinen hostet, kann als eine Host-Maschine bezeichnet werden. In der vorliegenden Offenbarung werden die Begriffe „End Host“ und „Host-Maschine“ austauschbar benutzt.
Der Begriff „VLAN“ wird in einem generischen Sinne verwendet und kann sich auf jegliches virtualisierte Netzwerk beziehen. Jedes virtualisierte Netzwerk, das ein Segment von physischen Networking-Vorrichtungen, Software-Netzwerkressourcen und eine Netzwerkfunktionalität aufweist, kann als ein „VLAN“ bezeichnet werden. Der Begriff „VLAN“ soll nicht als Ausführungsformen der vorliegenden Erfindung auf Layer-2-Netzwerke beschränkend interpretiert werden. Der Begriff „VLAN“ kann durch andere Terminologien ersetzt werden, die sich auf ein virtualisiertes Netzwerk oder Netzwerksegment beziehen, wie etwa durch „VPN“ (Virtual Private Network), „VPLS“ (Virtual Private LAN Service) oder „EVN“ (Easy Virtual Network).
Der Begriff „Paket“ bezieht sich auf eine Gruppe von Bits, die zusammen quer durch ein Netzwerk transportiert werden können. Der Begriff „Paket“ soll nicht als Ausführungsformen der vorliegenden Erfindung auf Layer-3-Netzwerke beschränkend interpretiert werden. Der Begriff „Paket“ kann durch andere Terminologien ersetzt werden, die sich auf eine Gruppe von Bits beziehen, wie etwa „Rahmen“ bzw. „Frame“, „Zelle“ oder „Datagramm“ oder „Datenpaket“.
Der Begriff „Switch“ (Schalter, Netzschaltwerk, Vermittlungsstelle) wird in einem generischen Sinne verwendet und kann sich auf jeden eigenständigen Switch oder Fabric Switch beziehen, der in irgendeiner Netzwerk-Schicht arbeitet. Ein „Switch“ kann eine physische Vorrichtung bzw. ein physisches Gerät oder eine Software sein, die auf einem Datenverarbeitungsgerät läuft. Der Begriff „Switch“ soll nicht als Ausführungsformen der vorliegenden Erfindung auf Layer-2-Netzwerke beschränkend interpretiert werden. Jegliche Vorrichtung bzw. jegliches Gerät, die bzw. das Verkehr zu einem externen Gerät bzw. einer externen Vorrichtung oder zu einem anderen Switch weiterleiten kann, kann als ein „Switch“ bezeichnet werden. Beispiele für einen „Switch“ umfassen, ohne darauf beschränkt zu sein, einen Layer-2-Switch, einen Layer-3-Router, eine TRILL RBridge oder einen Fabric Switch, der eine Vielzahl von ähnlichen oder heterogenen kleineren physischen Switches aufweist.
Der Begriff „Edge Port“ (Grenz-Port) bezieht sich auf einen Port an einem Netzwerk, der Datenrahmen mit einer Vorrichtung bzw. einem Gerät außerhalb des Netzwerks austauscht (d.h. ein Edge Port wird nicht für den Austausch von Datenrahmen mit einem anderen Mitglieds-Switch eines Netzwerks verwendet). Der Begriff „Inter-Switch-Port“ bezieht sich auf einen Port, der Datenrahmen zwischen Mitglieds-Switches des Netzwerks sendet und empfängt. Ein Link bzw. eine Verbindung zwischen Inter-Switch-Ports wird als ein „Inter-Switch-Link“ bezeichnet. Die Begriffe „Schnittstelle“ und „Port“ werden austauschbar verwendet.
Der Begriff „Switch-Kennung“ (Switch Identifier) bezieht sich auf eine Gruppe von Bits, die verwendet werden können, um einen Switch zu identifizieren. Beispiele für eine Switch-Kennung umfassen, ohne darauf beschränkt zu sein, eine MAC-(Media Access Control)-Adresse, eine IP-(Internet Protocol)-Adresse, eine RBridge-Kennung oder eine Kombination daraus. In der vorliegenden Offenbarung wird der Begriff „Switch-Kennung“ als ein generischer Begriff verwendet, ist nicht auf irgendein Bitformat beschränkt und kann sich auf jegliches Format beziehen, das einen Switch identifizieren kann.
Der Begriff „Tunnel“ bezieht sich auf eine Datenkommunikation, in der ein oder mehrere Networking-Protokolle bzw. Vermittlungsprotokolle unter Verwendung eines anderen Networking-Protokolls bzw. Vermittlungsprotokolls verkapselt werden bzw. sind. Obwohl die vorliegende Offenbarung unter Verwendung von Beispielen präsentiert wird, die auf einer Layer-3-Verkapselung eines Layer-2-Protokolls basieren, soll der Begriff „Tunnel“ nicht als Ausführungsformen der vorliegenden Erfindung auf Layer-2- oder Layer-3-Protokolle beschränkend interpretiert werden. Ein „Tunnel“ kann für jede und unter Verwendung von jeder Networking-Schicht, Teilschicht oder eine(r) Kombination aus Networking-Schichten hergestellt werden.
Ein „Intra-Fabric-Tunnel“ bezieht sich auf einen Tunnel, der zwischen Switches eingerichtet wird bzw. ist, die zu einem gemeinsamen Fabric Switch gehören. Ein „Inter-Fabric-Tunnel“ bezieht sich auf einen Tunnel, der zwischen zwei Fabric Switches eingerichtet wird bzw. ist, typischerweise zwischen zwei Backbone Nodes (Backbone-Knoten), die in jeweiligen Fabrics positioniert sind. Ein „Edge-Tunnel“ (Kantentunnel) ist ein Tunnel, der zwischen einem Switch und einem End Host hergestellt ist bzw. wird.
Netzwerkarchitektur
1A veranschaulicht eine beispielhafte Fabric-Switch-Architektur in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel umfasst die Architektur einen Fabric Switch 104, einen Backbone Fabric Switch 106 und einen Fabric Switch 108. Hier sind die Fabric Switches 104 und 108 mit End Hosts über Edge Ports gekoppelt, und somit können sie als Edge Fabric Switches bezeichnet werden.
Der Fabric Switch 104 umfasst eine Anzahl von Switches, wie etwa die Switches 105 und 107. In einer Ausführungsform kann jeder Switch innerhalb der Fabric 104 einen Intra-Fabric-Tunnel mit jedem anderen Switch innerhalb derselben Fabric bilden, wodurch eine voll vermaschte logische Topologie erzielt wird. Es können verschiedene Tunneling-Techniken verwendet werden. So kann zum Beispiel ein Tunnel unter Verwendung des VXLAN-Protokolls eingerichtet werden. Andere Tunneling-Protokolle, wie etwa GRE (Generic Routing Encapsulation), L2TP (Layer-2 Tunneling Protocol), MPLS (Multi-Protocol Label Switching), etc. können ebenfalls verwendet werden, um die Intra-Fabric-Tunnel einzurichten. Als eine Folge dieser voll vermaschten logischen Topologie kann jeder Switch innerhalb der Fabric 104 einen anderen Switch in derselben Fabric mit nur einem Sprung durch den entsprechenden Tunnel erreichen. In dem Fall, in dem VXLAN als ein Tunneling-Protokoll verwendet wird, kann ein Tunnel durch das Tupel {source_IP, destination_IP, source_port, destination_port} (Quell_IP, Ziel_IP, Quell_Port, Ziel_Port) identifiziert werden, wobei source_IP die IP-Adresse des Quell-Switch (Source Switch) ist, destination_IP die IP-Adresse des Ziel-Switch (Destination Switch) ist, source_port der UDP-Port des Quell-Switch ist und destination_port der UDP-Port des Ziel-Switch ist (da VXLAN UDP als ein Transportschichtprotokoll verwendet). Es sind aber auch andere Möglichkeiten zur Identifizierung der Tunnel möglich. In einigen Ausführungsformen wird der source_port aus einem Hash-Wert von einem der Felder in dem Tupel erzeugt.
Ein End Host 102 kann mit der Fabric 104 über eine MLAG (Multi-chassis Link Aggregation Group) 112 gekoppelt sein, die ein logischer Link (logische Verbindung) ist, der zwei physikalische Links umfasst, die jeweils die Switches 107 und 105 koppeln. Die MLAG 112 stellt eine Redundanz bei den physikalischen Links für den End Host 102 bereit. Wenn einer der zwei Links ausfällt, kann der andere Link betriebsfähig bleiben. Außerdem können der Switch 107 und 105 einen VTEP (Virtual Tunnel Endpoint; virtuellen Tunnel-Endpunkt) 114 bilden, der sich selbst als einen virtuellen Switch mit einer virtuellen IP-Adresse präsentieren kann. In einigen Ausführungsformen kann der End Host 102 einen Edge-Tunnel 116 mit dem VTEP 114 bilden. Für den End Host 102 kann der VTEP 114 wie jeder andere Switch in der Fabric 104 funktionieren, und die MLAG 112 kann wie ein regulärer Link für Zwecke der Weiterleitung von Verkehr vom und zum End Host 102 funktionieren.
Während des Betriebs kann der Edge-Tunnel 116 zwischen dem End Host 102 und dem Switch 107 hergestellt werden. Wenn es zu einem Ausfall kommt, dann kann der Tunnel 116 zu dem arbeitenden Link mit einer minimalen Unterbrechung bei der Übertragung bewegt werden. In ähnlicher Weise kann ein End Host 103 mit der Fabric 104 über eine MLAG 115 gekoppelt werden, die ein logischer Link ist, der zwei physikalische Links umfasst, die jeweils die Switches 107 und 105 koppeln. Der gleiche VTEP 114 kann Pakete über die MLAGs 112 und 115 empfangen und weiterleiten. Als eine Folge davon kann die virtuelle IP-Adresse des VTEP 114 als die VTEP-Adresse für beide MLAGs 112 und 115 dienen.
Es ist anzumerken, dass der Fabric Switch 104 als ein logischer Layer-2-Switch funktionieren kann, der es erlaubt, dass sich mehrere End Hosts, die mit der Fabric 104 verbunden sind, in einer gemeinsamen Ethernet-Broadcast-Domain befinden, solange diese End Hosts mit einem gemeinsamen VLAN konfiguriert sind. Es sei auch angemerkt, dass ein End Host ein physischer Host sein kann oder dass er eine Maschine sein kann, die mehrere virtuelle Maschinen hostet. Des Weiteren kann ein Hypervisor, der mehrere virtuelle Maschinen an einem physischen Host steuert, einen virtuellen Switch aufweisen. Dieser virtuelle Switch kann Teil des Fabric Switch 104 sein und kann Intra-Fabric-Tunnel mit jedem anderen Switch in der Fabric 104 einrichten, wodurch er Teil der voll vermaschten logischen Topologie ist.
Wie in dem Beispiel in 1A gezeigt ist, kann ein Backbone-Netzwerk 106 mehrere Fabric Switches, wie etwa die Fabric 104 und die Fabric 108, miteinander verbinden. Die Fabric 104 kann einen Switch 121 umfassen, der sowohl an der Fabric 104 als auch an der Backbone Fabric 106 (oder dem Backbone 106) teilnimmt. Ein solcher Switch kann als ein Backbone Node (Backbone-Knoten) bezeichnet werden. In ähnlicher Weise kann die Fabric 108 einen Backbone Node 123 umfassen, der sowohl an der Fabric 108 als auch an dem Backbone 106 teilnimmt. Für Verkehr zwischen der Fabric 104 und der Fabric 106 kann ein Inter-Fabric-Tunnel 120 zwischen dem Switch 121 und dem Switch 123 eingerichtet werden. Der Inter-Fabric-Tunnel 120 erlaubt es, dass die Ethernet-Broadcast-Domain in der Fabric 104 auf die Fabric 108 ausgeweitet werden kann. In diesem Beispiel ist ein End Host 110, ähnlich wie der End Host 102, mit der Fabric 108 unter Verwendung einer MLAG 112 gekoppelt. Die MLAG 112 kann zwischen dem End Host 110 und den Switches 111 und 113 gebildet sein. Die Switches 111 und 113 bilden gemeinsam einen VTEP 110. In einer Ausführungsform bildet ein End Host 110 einen Edge-Tunnel 124 mit dem VTEP 110.
In einem herkömmlichen Ethernet-Wählnetz bzw. vermittelten Ethernet-Netzwerk (switched Ethernet network) leitet ein Switch ein empfangenes Ethernet-Paket auf der Basis seiner MAC DA weiter, wobei vorausgesetzt wird, dass der Switch vorher gelernt hat, welchen Ausgangs-Port er für diese MAC DA verwenden soll, und zwar auf der Grundlage von früheren Paketen, die von dieser MAC DA stammten. Aber in einer erweiterten Ethernet-Broadcast-Domain, die sich über mehrere Fabric Switches erstreckt, wie etwa über die Fabrics 104 und 108, kann es für einen einzelnen Switch unmöglich sein, Erreichbarkeitsinformationen für alle MAC-Adressen aufrecht zu erhalten bzw. zu bewahren, die mit einer Broadcast Domain verknüpft sind, insbesondere dann, wenn ein End Host mehrere virtuelle Maschinen beherbergen kann. Das Weiterleiten auf der Basis von nur der MAC DA kann auch ein ähnliches Skalierbarkeitsproblem bedingt durch den großen MAC-Adressenraum haben.
Um diese Probleme zu lösen, ist in einigen Ausführungsformen der vorliegenden Erfindung jede Fabric durch ein eindeutiges Label oder eine eindeutige Kennung identifiziert. Ein Source Fabric Label (Quell-Fabric-Label) und ein Destination Fabric Label (Ziel-Fabric-Label) können in dem Tunnel-Verkapselungs-Header enthalten sein bzw. aufgenommen werden. Für einen Intra-Fabric-Verkehr, d.h. Pakete, deren MAC SA und MAC DA beide in derselben Fabric liegen, sind das Source Fabric Label und das Destination Fabric Label des Pakets die gleichen. Wenn ein Switch ein Paket von einem Intra-Fabric-Tunnel empfängt, kann der Switch das Destination Fabric Label inspizieren. Wenn das Label identisch zu dem Label der lokalen Fabric ist, kann der Switch das Paket aus dem Tunnel-Header entkapseln und das Ethernet-Paket auf der Basis seiner MAC DA weiterleiten. Wenn das Destination Fabric Label des Pakets nicht das Label der lokalen Fabric ist, kann der Switch das Paket entkapseln, das Paket in einem Inter-Fabric-Tunnel-Header erneut verkapseln und das Paket über den geeigneten Inter-Fabric-Tunnel übertragen.
Es sei zum Beispiel angenommen, dass der End Host 102 ein Paket an den End Host 110 sendet. Es sei auch angenommen, das der End Host 102 keinen virtuellen Switch enthält, der an der Fabric 104 beteiligt ist. Der End Host 102 würde ein Ethernet-Paket erzeugen, das ein inneres IP-Paket für den End Host 110 enthalten kann, mit der MAC-Adresse des End Host 110 als seiner MAC DA, und er sendet das Paket über den Edge-Tunnel 116. Es ist anzumerken, dass an diesem Punkt das Paket keinerlei Fabric-Label-Informationen enthält. Wenn das Paket an dem Switch 107 ankommt, der als ein Eingangs-Switch für die Fabric 104 dient, entkapselt der Switch 107 das Paket und inspiziert dessen MAC DA. Der Switch 107 entscheidet dann, dass die MAC DA zu der Fabric 108 passt (Mechanismen zum Verbreiten der MAC-auf-Fabric-Label-Mapping-Informationen werden ausführlicher in späteren Abschnitten der vorliegenden Offenbarung beschrieben).
Dementsprechend ermittelt der Switch 107, dass das Paket zu dem Backbone Node 121 gesendet werden müsste, da das Paket für eine entfernte Fabric bestimmt ist. Der Switch 107 verkapselt dann das Paket mit einem Tunnel-Header, der das Label der Fabric 104 als dessen Source Fabric Label umfasst und das Label der Fabric 108 als dessen Destination Label umfasst, und er sendet das Paket auf dem Intra-Fabric-Tunnel 118, der zu dem Backbone Node 121 führt. Die Fabric 104 kann auch die Trennung von Kundenverkehr ermöglichen. Wenn zum Beispiel die End Hosts 102 und 103 zu zwei verschiedenen Kunden gehören, dann kann die Fabric 104 separate Tunnelsegmente des Tunnels 118 für den Verkehr von den End Hosts 102 und 103 zuweisen. Die Switches 105 und 107 können Service- und Customer- bzw. Dienst- und Kunden-VLAN-Kennungen der End Hosts 102 und 103 auf jeweilige Tunnelsegmentkennungen mappen. In einigen Ausführungsformen ist der Tunnel 118 ein VXLAN-Tunnel und ist eine Tunnelsegmentkennung eine VXLAN-Netzwerkkennung (VNI; VXLAN Network Identifier).
Nach dem Empfangen des Pakets inspiziert der Switch 121 zuerst den Tunnel-Header des Pakets, um das Destination Fabric Label zu ermitteln. Da das Destination Fabric Label nicht das gleiche wie das Label der Fabric 104 ist, entkapselt der Switch 121 das Paket aus dem Header für einen Intra-Fabric-Tunnel 118 und verkapselt das Paket in einen neuen Tunnel-Header für den Inter-Fabric-Tunnel 120, der zu dem Backbone Node 123 für die Fabric 108 führt. Es ist anzumerken, dass der neue Tunnel-Header auch das Label der Fabric 104 als das Destination Fabric Label angibt. Der Switch 121 sendet dann das Paket auf dem Inter-Fabric-Tunnel 120.
Wenn der Switch 123 das Paket empfängt, inspiziert der Switch 123 das Destination Fabric Label des Pakets, das das gleiche ist wie das Label der Fabric 108. Der Switch 123 ermittelt dann, dass das Paket für eine MAC-Adresse innerhalb der Fabric 108 bestimmt ist. Dementsprechend entkapselt der Switch 123 das Paket und inspiziert die MAC DA des inneren Ethernet, welche die MAC-Adresse für den End Host 110 ist. Auf der Basis dieser MAC DA entscheidet der Switch, dass das Paket zu dem Ausgangs-Switch 113 gesendet werden soll. Dementsprechend verkapselt der Switch 123 das Paket mit einem Tunnel-Header, der dem Intra-Fabric-Tunnel 112 entspricht, und sendet das Paket auf dem Tunnel 122.
Danach ermittelt der Switch 113 dann, wenn das Paket an dem Switch 113 ankommt, dass das Destination Fabric Label das gleiche Label wie für die Fabric 108 ist. Infolgedessen entkapselt der Switch 113 das Paket und schlägt die MAC DA des inneren Ethernet-Pakets nach. Als eine Folge des Nachschlagens ermittelt der Switch 113, dass das Paket für den End Host 110 bestimmt ist, der mit dem VTEP 110 über den Tunnel 124 gekoppelt ist. Dementsprechend verkapselt der Switch 113 das Paket mit einem Tunnel-Header, der dem Tunnel 124 entspricht, und liefert das Paket an den End Host 110. Wenn das Paket für den End Host 101 bestimmt wäre, der mit der Fabric 108 über einen Edge Port ohne einen Tunnel (z.B. den Tunnel 124) gekoppelt ist, hätte der Switch 113 das Paket zu dem End Host 101 über den Edge Port auf der Grundlage der MAC DA ohne Verkapselung des Pakets weitergeleitet.
In einigen Ausführungsformen kann der Switch 113 als das IP-Gateway für den End Host 101 arbeiten (z.B. die Gateway-Adresse, die von einem DHCP-(Dynamic Host Configuration Protocol)-Server bereitgestellt wird). Als eine Folge davon können Ethernet-Rahmen von dem End Host 101 für den Switch 113 bestimmt sein. Es sei angenommen, dass der End Host 101 ein Paket an den End Host 102 sendet. Der End Host 101 verkapselt das Paket in einem Ethernet Header und sendet den Ethernet-Rahmen zu dem Switch 113. Nach dem Empfangen des Rahmens entfernt der Switch 113 den Ethernet Header und fördert die Nutzlast, die sich in dem IP-Paket befindet, für die Layer-3-Verarbeitung. Ein Switch in einem Fabric Switch kann Weiterleitungsinformationen, die auf eine IP-Adresse eines End Host gemappt wurden, sowie auch die MAC-Adresse aufrecht erhalten bzw. bewahren. Somit kann der Switch 113 das Paket zu dem End Host 102 über den Tunnel 122 auf der Basis der Weiterleitungsinformationen, die auf die IP-Adresse des End Host 102 gemappt wurden, weiterleiten.
Es ist anzumerken, dass in dem obigen beispielhaften Verwendungsfall die Backbone Nodes individuelle Switches sind. In einigen Ausführungsformen kann der Backbone Node auch ein verteilter virtueller Switch sein, ähnlich zu VTEP 114 und VTEP 110. Außerdem kann es mehrere Backbone Nodes in einer Fabric geben. Ein Backbone Node kann für das Weiterleiten von Verkehr zu einer Untergruppe von entfernten Fabrics zuständig sein, und ein anderer Backbone Node kann für das Weiterleiten von Verkehr zu einer anderen Untergruppe von entfernten Fabrics zuständig sein. Des Weiteren
Verbreitung von Erreichbarkeitsinformationen und Schleifenvermeidung
Wie oben erwähnt worden ist, kann es im Allgemeinen drei Hierarchien von Overlay-Tunneln oberhalb des Underlay-Netzwerks geben, nämlich Edge-Tunnel, Intra-Fabric-Tunnel und Inter-Fabric-Tunnel. Außerdem wird ein Paket, sobald das Paket in eine Fabric eintritt, durch Tunnel transportiert, wobei sein Tunnel-Header ein Source Fabric Label und ein Destination Fabric Label trägt. Das Weiterleiten der Fabric zwischen Tunneln kann auf der Basis des Destination Fabric Label ausgeführt werden.
Wenn ein Paket eine Fabric über einen Eingangs-Switch betritt, ist dieser Eingangs-Switch zuständig für das Erzeugen des Tunnel-Header des Pakets, der die Source und Destination Fabric Labels enthält. Infolgedessen kann der Eingangs-Switch idealerweise einen Satz von Mapping-Informationen aufrecht erhalten bzw. bewahren, die eine MAC DA auf ein Fabric Label mappen (das Fabric Label kann das Label der lokalen Fabric sein oder es kann das Label einer fernen Fabric sein).
Für alle MAC-Adressen innerhalb der lokalen Fabric können diese MAC-auf-Fabric-Label-Mapping-Informationen durch das Lernen von MAC-Adressen erlangt werden. Das heißt, wenn ein End Host ein Ethernet-Paket an die Fabric sendet, kann der Eingangs-Switch eine Mapping-Beziehung zwischen der Ethernet MAC SA und dem Label der lokalen Fabric herstellen. Diese Mapping-Informationen können dann von allen Switches in der lokalen Fabric gemeinsam genutzt werden, wodurch erlaubt wird, dass zukünftige Pakete mit der gleichen MAC als ihre DA zu dem End Host weitergeleitet werden.
Bei einer MAC-Adresse, die mit einer entfernten Fabric assoziiert ist, ist ein Lösungsansatz für das Herstellen des MAC-auf-Fabric-Label-Mapping, das Mapping in der Datenebene zu lernen, ähnlich wie bei dem Intra-Fabric-MAC-Lernen. Dieses Verfahren kann aber langsam und nicht skalierbar sein, weil es von dem vorher beobachteten Verkehr abhängt. Bevor die vollständigen Mapping-Informationen eingerichtet werden können, müssten Pakete mit unbekannten MAC DAs zu der gesamten Broadcast-Domain (die sowohl die lokalen als auch die entfernten Fabrics einschließen kann) rundgesendet werden. Als eine Folge davon könnte eine große Menge an Verkehrsüberflutung bzw. Verkehrsfülle auftreten.
Ein zweiter Lösungsansatz für die Verbreitung der MAC-auf-Fabric-Label-Mapping-Informationen für MAC-Adressen, die sich in einer entfernten Fabric befinden, ist, ein Verbreitungsprotokoll in der Steuerebene zu verwenden. Wenn zum Beispiel unter Bezugnahme auf 1A eine Anzahl von MAC-Adressen in der Fabric 108 zugeordnet werden (z.B. mit dem Einsatz einer Anzahl von virtuellen Maschinen), können diese MAC-Adressen und das Label der Fabric 108 an alle Switches in der Fabric 104 über ein Steuerinformations-Verbreitungsprotokoll verbreitet werden. Dieses Verbreitungsverfahren kann den Betrag an Überflutung bzw. Fülle, der für das Lernen von unbekannten MAC-Adressen benötigt wird, reduzieren. In einer Ausführungsform kann das MPBGP-EVPN-(Multiprotocol Border Gateway Protocol Ethernet Virtual Private Network)-Protokoll verwendet werden, um die MAC-auf-Fabric-Label-Mapping-Informationen für eine Gruppe von MAC-Adressen in einer entfernten Fabric zu verbreiten. Einzelheiten zu dem MPBGP-EVPN sind unter https://tools.ietf.org/html/rfc7432 zu finden, wobei die Offenbarung davon in ihrer Gesamtheit hier aufgenommen wird. Es ist anzumerken, dass die Mapping-Verbreitungsnachrichten regelmäßig oder je nach Bedarf gesendet werden können. Wenn zum Beispiel eine neue MAC-Adresse zu der Fabric 108 hinzugefügt wird, kann eine neue Verbreitungsnachricht zu der Fabric 104 gesendet werden, um diese neue MAC zu der Datenstruktur hinzuzufügen, die das Mapping zwischen MAC-Adressen und dem Label der Fabric 108 speichert.
Es ist auch möglich, die Datenebenen- und Steuerebenen-Lösungsansätze zu kombinieren. So kann zum Beispiel ein anfänglicher Satz von MAC-auf-Fabric-Label-Mapping-Informationen für alle MAC-Adressen in der Fabric 108 durch die Switches in der Fabric 104 über die Steuerebene erhalten werden. Wenn ein Switch in der Fabric 104 ein Paket mit dem Label der Fabric 108 als dessen Source Fabric Label und eine MAC SA, die momentan nicht in der Mapping-Informationen-Datenstruktur gespeichert ist, feststellt, dann kann der Switch diese neue MAC-Adresse zu der existierenden Gruppe von MAC-Adressen, die auf die Fabric 108 gemappt sind, hinzufügen und diese Informationen mit allen Switches in der Fabric 104 teilen.
Ein wichtiger Aspekt bei der Gestaltung einer Fabric-Architektur liegt darin, Schleifen zu verhindern. Schleifen treten dann auf, wenn eine Weiterleitungsentscheidung dazu führt, dass das Paket zu einem Switch gesendet wird, den es vorher bereits schon besucht hat. In einigen Ausführungsformen der vorliegenden Erfindung können Schleifen verhindert werden, indem das Weiterleitungsverhalten eines Switch eingeschränkt wird. Insbesondere innerhalb eines Fabric Switch wird ein Switch am Weiterleiten eines Pakets von einem Intra-Fabric-Tunnel zu einem anderen Intra-Fabric-Tunnel oder von einem Inter-Fabric-Tunnel zu einem anderen Inter-Fabric-Tunnel gehindert. Ein Switch darf Pakete zwischen einem Inter-Fabric-Tunnel und einem Intra-Fabric-Tunnel, zwischen einem Intra-Fabric-Tunnel und einem Edge-Tunnel und zwischen einem Inter-Fabric-Tunnel und einem Edge-Tunnel weiterleiten. Ein Switch darf Pakete auch zwischen zwei Edge-Tunneln weiterleiten, da der Switch mit zwei End Hosts gekoppelt sein kann, und ein solches Weiterleiten kann die Kommunikation zwischen diesen zwei End Hosts ermöglichen.
Es ist anzumerken, dass, da erwartet wird, dass innerhalb einer Fabric ein Switch jeden anderen Switch mit einem direkten Intra-Fabric-Tunnel erreichen kann, kein Bedarf daran besteht, Pakete zwischen Intra-Fabric-Tunneln weiterzuleiten. In ähnlicher Weise wird erwartet, dass ein Inter-Fabric-Tunnel zwei Backbone Nodes direkt verbindet und dass kein Bedarf daran besteht, Pakete von einem Inter-Fabric-Tunnel zu einem anderen weiterzuleiten.
1B veranschaulicht eine beispielhafte Weiterleitungsmethode mit Gruppen von hierarchischen Overlay-Tunneln in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel kann der Switch 107 ein Paket, das von einem End Host 102 empfangen wird, zu einem Intra-Fabric-Tunnel, wie etwa zu dem Intra-Fabric-Tunnel 118, der zu dem Backbone Node 121 führt, weiterleiten. Der Switch 107 kann das Paket auch zu einem End Host 130 über einen anderen Edge-Tunnel 131 weiterleiten. Es sollte angemerkt werden, dass ein Backbone Node an einer Vielzahl von Edge Fabrics und einer Backbone Fabric teilnehmen kann. So kann zum Beispiel der Backbone Node 121 auch an einer anderen Edge Fabric 140 teilnehmen.
Nach dem Empfangen des Pakets in einem Intra-Fabric-Tunnel kann der Backbone Node 121 das Paket auf einem Inter-Fabric-Tunnel 120 weiterleiten. Hier wird der Backbone Node 121 daran gehindert, das Paket auf Intra-Fabric-Tunneln der Fabric 104 weiterzuleiten, was zur Bildung von Schleifen führen könnte. Aber wenn das Paket ein Multi-Ziel-Paket ist, leitet der Backbone Node 121, obwohl der Backbone Node 121 das Paket nicht auf Intra-Fabric-Tunneln der Fabric 104 weiterleitet, das Paket auf Intra-Fabric-Tunneln der Fabric 140 weiter (z.B. auf dem Intra-Fabric-Tunnel 142 zwischen dem Backbone Node 121 und dem Switch 145 der Fabric 140).
In ähnlicher Weise kann der Backbone Node 123 dann, wenn er das Paket empfängt, das Paket nur auf einem Intra-Fabric-Switch weiterleiten, und er wird daran gehindert, das Paket zu einem anderen Inter-Fabric-Switch zu senden.
Weiterleitungsinformationen
Wenn ein Paket dann eine Fabric betritt, kann angenommen werden, dass das Paket für Gewöhnlich entlang eines Links wandert, während es in einem Tunnel-Header verkapselt bzw. eingekapselt ist. Dieser Tunnel-Header kann ein Source Fabric Label und ein Destination Fabric Label umfassen. In einer Ausführungsform werden diese Fabric-Label-Informationen in einem Network Service Header (NSH) (Netzwerk-Service-Header oder Netzwerk-Dienst-Header) getragen. Aber ein Switch in einem Fabric Switch muss ermitteln, welches Label benutzt werden soll, während ein Paket weitergeleitet wird.
Während des Betriebs empfängt ein Switch, wie etwa der Switch 107 in 1A, Weiterleitungsinformationen von der Fabric 104 über die Steuerebene (z.B. von einer Verwaltungsvorrichtung). Solche Informationen können eine Liste von MAC-Adressen von End Hosts (z.B. virtuelle Maschinen und physische Server), die mit der Fabric 104 gekoppelt sind, umfassen. Die Informationen umfassen auch, welche MAC-Adresse über welchen Switch in der Fabric 104 zu erreichen ist. In ähnlicher Weise kann der Switch 107 auch Weiterleitungsinformationen von End Hosts empfangen, die mit entfernten Fabrics gekoppelt sind und die über eine Backbone Fabric 106 (z.B. die Fabric 108) gekoppelt sind. Aber die Weiterleitungsinformationen, die mit der Fabric 108 in dem Switch 107 assoziiert sind, geben nur an, dass diese End Hosts über die Backbone Fabric 106 erreichbar sind. Der Switch 107 speichert die Weiterleitungsinformationen in einer Switch-Kennungs-Mapping-Tabelle.
1C veranschaulicht eine beispielhafte Switch-Kennungs-Mapping-Tabelle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel mappt ein Eintrag in der Switch-Kennungs-Mapping-Tabelle 150 eine Switch-Kennung (Switch Identifier) 152 mit einem Fabric Label 154 und einer Tunnel-Kennung (Tunnel Identifier) 156. Die Switch-Kennung 152 kann eine MAC-Adresse, eine IP-Adresse oder beides sein. Die IP-Adresse kann aus einer ARP-(Address Resolution Protocol; Adressauflösungsprotokoll)-Antwortnachricht erhalten werden. Die Tunnel-Kennung 156 kann eine interne und lokale Nummer der Switch-Speichertabelle 150 sein, wie etwa ein ganzzahliger Wert, der in der Weiterleitungs-Hardware des Switch gespeichert ist. In einigen Ausführungsformen sendet ein jeweiliger Backbone Node eine Benachrichtigungsnachricht an andere Switches in einer Edge Fabric, die angibt, dass der Backbone Node mit der Backbone Fabric gekoppelt ist. Der Switch 107 assoziiert zum Beispiel nach dem Empfangen der Benachrichtigungsnachricht von dem Backbone Node 121 ein Fabric Label des Backbone 106 mit der Tunnel-Kennung des Tunnels 118.
Wenn die Switch-Kennung 152 dem End Host 102 zugeordnet ist und sich die Tabelle 150 in dem Switch 111 befindet, entspricht das Fabric Label 154 der Fabric 108, und die Tunnel-Kennung 156 identifiziert einen Intra-Fabric-Tunnel zwischen den Switches 111 und 113. Andererseits hat der Backbone Node 121 den Switch 170 darüber informiert, dass das Backbone 106 über den Backbone Node 121 erreichbar ist. Infolgedessen entspricht dann, wenn die Switch-Kennung 152 dem End Host 101 zugeordnet ist und sich die Tabelle 150 in dem Switch 107 befindet, das Fabric Label 154 der Backbone Fabric 107, und die Tunnel-Kennung 156 identifiziert einen Intra-Fabric-Tunnel 118 zwischen dem Switch 107 und dem Backbone Node 121.
In einigen Ausführungsformen weist die Tunnel-Kennung 156 auf eine Weiterleitungsdatenstruktur 160 hin (z.B. funktioniert die Tunnel-Kennung 156 als der Index einer Datenstruktur 160). Die Weiterleitungsdatenstruktur 160 umfasst alle Informationen, die verwendet werden können, um ein Paket in einem Tunnel-Verkapselungs-Header zu verkapseln und das verkapselte Paket über den Tunnel, der durch die Tunnel-Kennung 156 identifiziert ist, weiterzuleiten. Informationen in der Weiterleitungsdatenstruktur 160 umfassen, ohne darauf beschränkt zu sein, eine Zielkennung (Destination Identifier) (z.B. eine VTEP IP-Adresse des anderen Endes des Tunnels), einen IP DHCP-Wert, eine Liste von VNI, die von dem Tunnel unterstützt werden, ein oder mehrere VLANs, die auf eine jeweilige VNI gemappt sind, eine ARP-Antwortinformation und einen Ethernet-Prioritätswert.
In einigen Ausführungsformen werden die VLANs, die auf eine VNI gemappt sind, in einer separaten Tabelle gespeichert. 1D veranschaulicht eine beispielhafte VLAN-Mapping-Tabelle in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Die VLAN-Mapping-Tabelle 170 umfasst einen Eintrag, der ein Mapping zwischen einem Kunden-VLAN (Customer VLAN) 172 und einer VNI 178 aufweist. In einigen Ausführungsformen kann die VLAN-Mapping-Tabelle 170 des Weiteren ein Service-VLAN bzw. Dienst-VLAN (Service VLAN) 174 auf die VNI 178 mappen. Die VLAN-Mapping-Tabelle 170 kann für einen jeweiligen Tunnel und die VNIs, die von dem Tunnel unterstützt werden, aufrecht erhalten bzw. bewahrt werden. Die VNI 178 kann auf ein oder mehrere Kunden-VLANs und/oder ein oder mehrere Service-VLANs gemappt werden. Dies erlaubt es, dass ein Switch einen Verkehr von verschiedenen Clients bzw. Kunden oder verschiedenen VLANs in dem Tunnel trennen kann.
Fabric-Bildung und MAC-Adressen-Verwaltung
In dem Beispiel von 1A kann die Fabric 104 ein IP-Netzwerk sein und ein jeweiliger Switch der Fabric 104 führt das BGP (oder dessen Variation) aus, um Routen zwischen den Switches zu bestimmen. Wenn das Netzwerk konvergiert, haben Switches in der Fabric 104 Routen zwischen den Switches, und infolgedessen errichten sie Intra-Fabric-Tunnel in der Fabric 104. 2A zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der Intra-Fabric-Tunnel in einem Fabric Switch herstellt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs ermittelt der Switch die Konvergenz der Fabric (Vorgang 202). Der Switch empfängt dann die VNIs, die für einen jeweiligen Switch konfiguriert sind (Vorgang 204). Der Switch kann diese Informationen aus Benachrichtigungsnachrichten von anderen Switches oder von einer administrativen Vorrichtung (z.B. einer Workstation eines Netzwerkadministrators) empfangen.
Der Switch identifiziert einen Switch mit wenigstens einer gemeinsamen VNI (Vorgang 206) und stellt einen Intra-Fabric-Tunnel mit dem identifizierten Switch her (Vorgang 208). Der Tunnel kann durch die Switch-IP-Adresse des identifizierten Switch repräsentiert werden (d.h. die VTEP-Kennung ist die Switch-IP-Adresse). Der Switch kann des Weiteren eine lokale und interne Tunnelkennung erzeugen (oder empfangen), um den Tunnel zu identifizieren. Der Switch ermöglicht eine jeweilige gemeinsame VNI für den eingerichteten Tunnel (Vorgang 210). Auf diese Weise kann derselbe Tunnel für mehrere VNIs verwendet werden. Der Switch überprüft dann, ob alle Switches in Bezug auf eine gemeinsame VNI überprüft worden sind (Vorgang 212). Falls nicht, dann wird der Switch fortfahren, einen anderen Switch mit wenigstens einer gemeinsamen VNI zu identifizieren (Vorgang 206) und einen Intra-Fabric-Tunnel mit dem identifizierten Switch herzustellen (Vorgang 208).
2B zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der Switch-Kennungen auf Weiterleitungsinformationen mappt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs empfängt der Switch MAC-Adressen und ihre zugehörigen Zielinformationen (Vorgang 252), wie dies in Verbindung mit 1C beschrieben worden ist. Der Switch identifiziert die MAC-Adressen, die über eine entfernte Fabric erreichbar sind, und mappt die identifizierten MAC-Adressen mit dem Fabric Label der Backbone Fabric (Vorgang 254). Der Switch mappt die identifizierten MAC-Adressen mit der/den Tunnel-Kennung(en) von (einem) Intra-Fabric-Tunnel(n) auf Backbone Node(s) einer lokalen und Backbone Fabric (Vorgang 256). Wenn der Switch eine ARP-Antwort für eine MAC-Adresse empfängt, nimmt der Switch die IP-Adresse, die mit der MAC-Adresse assoziiert ist, in das Mapping auf.
Der Switch identifiziert dann die MAC-Adressen, die über die Switches der lokalen Fabric erreichbar sind, und mappt identifizierte MAC-Adressen mit dem Fabric Label der lokalen Fabric (Vorgang 258). Der Switch mappt eine jeweilige identifizierte MAC-Adresse mit der Tunnel-Kennung des Tunnels auf den Ausgangs-Switch für die MAC-Adresse (d.h. des Tunnels, über den die MAC-Adresse erreichbar ist) (Vorgang 260). Der Switch speichert dann die Weiterleitungsinformationen (z.B. Weiterleitungsinformationen in der Weiterleitungsdatenstruktur 160) einer jeweiligen MAC-Adresse in Verbindung mit der entsprechenden Tunnel-Kennung (Vorgang 262). Der Switch verwendet zum Beispiel die Tunnel-Kennung als einen Index auf die Weiterleitungsinformationen, wie dies in Verbindung mit 1C beschrieben worden ist.
Da ein Switch Weiterleitungsinformationen von MAC-Adressen speichern kann, die über sowohl lokale als auch entfernte Fabric Switches erreichbar sind, kann die Anzahl an solchen MAC-Adressen beträchtlich sein. Als Folge davon ist es praktisch nicht möglich, eine solche große Anzahl an MAC-Adressen in der Weiterleitungs-Hardware (z.B. CAM (Content-Addressable Memory; Assoziativspeicher)) des Switch zu speichern. Um dieses Problem zu lösen, kann der Switch die Weiterleitungsinformationen in einer Speichereinrichtung des Switch speichern und die Weiterleitungsinformationen in die Weiterleitungs-Hardware nur dann laden, wenn sich der Switch in einer Kommunikation mit der MAC-Adresse befindet. Diese MAC-Adressen können als Dialog-MAC-Adressen bezeichnet werden.
2C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der Dialog-MAC-Adressen in der Weiterleitungs-Hardware aufrecht erhält bzw. bewahrt, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs identifiziert der Switch eine MAC-Adresse in einem empfangenen Rahmen (Vorgang 252) und überprüft, ob die MAC-Adresse in der Weiterleitungs-Hardware des Switch vorhanden ist (Vorgang 254). Wenn sich die MAC-Adresse nicht in der Weiterleitungs-Hardware befindet, beschafft sich der Switch die Weiterleitungsinformationen, die mit der MAC-Adresse assoziiert sind, von der Speichereinrichtung des Switch (Vorgang 256) und lädt die Weiterleitungsinformationen in die Weiterleitungs-Hardware des Switch (Vorgang 258).
Weiterleitungsinformationen und Fabric Label
3A veranschaulicht eine beispielhafte Paket-Header-Konfiguration für das Übertragen einer Fabric-Switch-Kennung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel wird angenommen, dass das Paket in einem VXLAN-Tunnel-Header verkapselt ist. Wie in 3A veranschaulicht ist, weist ein Paket 300 eine Payload (Nutzlast) 302 auf, die in einem Ethernet-Paket mit einem Ethernet Header 304 getragen wird. Dieses Ethernet-Paket ist in einem VXLAN Header 306 verkapselt bzw. eingekapselt, der einen Network Service Header (Netzwerk-Service-Header) 307 umfasst.
Außerhalb des VXLAN Header 306 befindet sich ein UDP Header 308, da VXLAN UDB als ein Transportschichtprotokoll verwendet. Außerhalb des UDP Header 308 befindet sich ein IP Header 301. Es ist anzumerken, dass die Quell- und Ziel-UDP-Ports und die Quell- und Ziel-IP-Adressen einen VXLAN-Tunnel eindeutig identifizieren können. Ein Switch kann eine Datenstruktur aufrecht erhalten bzw. bewahren, die Intra-Fabric-MAC-Adressen auf unterschiedliche Intra-Fabric-Tunnel unter Verwendung dieser Tupel als eindeutige Tunnel-Kennungen mappt.
Der IP Header 310 wird von einem Outer Ethernet Header bzw. äußeren Ethernet Header 311, der als das aktuelle Data Link Layer-(Sicherungsschicht)-Protokoll dient, eingekapselt. Es ist anzumerken, dass ein Inner Ethernet Header bzw. innerer Ethernet Header 304 einem anderen Zweck dient als ein Outer Ethernet Header 311. Der Inner Ethernet Header 304 gibt den Ethernet-Weiterleitungspfad von einem Ende zum anderen Ende an, wohingegen der Outer Ethernet Header 311 als ein Hop-by-Hop Data Link Layer Protocol (Sprung-um-Sprung-Sicherungsschicht-Protokoll) verwendet wird.
Ein Network Service Header 307 hat typischerweise eine Breite von 32 Bit und kann eine Anzahl von Feldern umfassen, wie etwa Version and Mandatory Bits' (Versions- und Pflicht-Bits) 312, ein' Service Path ID and Service Index'-(Service-Pfad-ID und Service-Index)-Feld 314, ein Network Platform Context'-(Netzwerkplattform-Kontext)-Feld 316, ein Network Shared Context'-(Netzwerk-Gemeinschaft-Kontext)-Feld 318, ein Service Platform Context'-(Serviceplattform-Kontext)-Feld 316 und ein Service Shared Context'-(Service-Gemeinschaft-Kontext)-Feld 322. In einer Ausführungsform kann das ,Network Platform Context'-Feld 316 ein Source Fabric Label und ein Destination Fabric Label umfassen, die jeweils 16 Bit lang sein können.
Es ist anzumerken, dass das Fabric-Label-Konzept auch in einer Fabric-Architektur verwendet werden kann, die andere Tunneling-Protokolle verwendet oder keine Tunnel-Overlays verwendet. So kann ein Fabric Switch zum Beispiel auf einer IP-Weiterleitung ohne Tunnel aufgebaut sein und beruht nicht auf irgendeinem Tunneling-Protokoll. In diesem Fall können die Fabric-Label-Informationen ohne irgendeinen Tunneling-Header übertragen werden. 3B veranschaulicht eine beispielhafte Paket-Header-Konfiguration zum Übertragen einer Fabric-Switch-Kennung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel umfasst ein Paket 332 eine Payload (Nutzlast) 322, die in einem Ethernet-Paket mit einem Ethernet Header 324 übertragen wird. Dieses Ethernet-Paket ist einer IP-Verkapselung mit einem IP Header 326 unterzogen. Ein Network Service Header 328 wird dann außerhalb des IP Header 326 platziert, um die Source und Destination Fabric Labels zu übertragen. Ein Outer Ethernet Header (äußerer Ethernet Header) 330 wird verwendet, um das gesamte Paket einzukapseln, und er dient als ein Data Link Layer Header (Sicherungsschicht-Header).
3C veranschaulicht einen exemplarischen Prozess für das Weiterleiten eines Pakets von einem Ende zum anderen Ende quer durch Fabric Switches in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel sendet ein End Host 352 ein Ethernet-Paket über zwei Fabrics an einen End Host 360. Während des Betriebs sendet der End Host 352 das Paket über einen Edge-Tunnel 362 zu einem Eingangs-Fabric Switch 354. Das Paket ist mit einem VXLAN Header 372 verkapselt, während es in dem Edge-Tunnel 312 transportiert wird. Es ist anzumerken, dass der VXLAN Header 372 nicht die Source und Destination Fabric Labels einschließt, weil der End Host 352 nicht Teil einer Fabric ist.
Nach dem Empfangen und Entkapseln des Pakets schlägt der Switch 354 die MAC DA des inneren Ethernet Header nach und ermittelt auf der Basis der MAC DA das Destination Fabric Label. Der Switch 354 verkapselt wiederum das Paket mit einem neuen Tunnel-Header, der einen IP Header, einen UDP Header und einen VXLAN Header 374 umfasst. Der VXLAN Header 374 enthält einen Network Service Header (Netzwerk-Service-Header), der das Source Fabric Label und das Destination Fabric Label angibt. Der Switch 354 sendet dann das verkapselte Paket zu einem Backbone Node 306 über einen Intra-Fabric-Tunnel 364. Es ist anzumerken, dass der VXLAN Header 374 die gleiche VXLAN-Netzwerkkennung (VNI; VXLAN Network Identifier) wie der VXLAN Header 372 gemeinsam nutzen kann.
Nach dem Empfangen und Entkapseln des Pakets von dem Intra-Fabric-Tunnel 364 ermittelt der Backbone Node 356 auf der Grundlage des Destination Fabric Label des Pakets, dass das Paket für eine entfernte Fabric bestimmt ist. Als Folge davon verkapselt der Switch 356 das Paket mit einem neuen Tunnel-Header (z.B. IP und UDP Headers) entsprechend dem Inter-Fabric-Tunnel 366, während er den gleichen VXLAN Header 304 beibehält, einschließlich des Network Service Header als Teil des VXLAN Header 374. Es ist anzumerken, dass durch das Beibehalten desselben VXLAN Header 374 das Paket dieselben Source und Destination Fabric Labels beibehält, was es erlaubt, dass das Paket durch die Fabrics weitergeleitet werden kann.
Der Switch 356 sendet dann das Paket auf einem Inter-Fabric-Tunnel 366. Nach dem Empfangen und Entkapseln des Pakets ermittelt der entfernte Backbone Node 358 auf der Basis des Destination Fabric Label des Pakets, dass das Paket für die Fabric bestimmt ist, in der sich der Switch 358 befindet. Als Folge davon schlägt der Switch die MAC DA in dem inneren Ethernet Header des Pakets nach. Unter der Annahme, dass der Ziel-End Host 360, der der MAC DA des Pakets entspricht, mit dem Switch 358 gekoppelt ist, kann der Switch 358 das Paket mit einem neuen Tunnel-Header (d.h. IP/UDP Headers, die dem End Host 360 entsprechen) verkapseln, der einen neuen VXLAN Header 376 einschließt. Es ist anzumerken, dass der VXLAN Header 376 die gleiche VNI wie der VXLAN Header 374 haben kann, aber ohne einen Network Service Header (Netzwerk-Service-Header), da der End Host 310 nicht Teil der Fabric ist, zu der der Switch 358 gehört. Nach dem Empfangen dieses Pakets kann der End Host 360 das Paket aus dem Tunnel-Header entkapseln und das innere Ethernet-Paket verarbeiten.
Weiterleitungsinformationen und Fabric Label
4A zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einem Edge Port empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs empfängt der Switch ein Paket von einem End Host (Vorgang 402). Der Switch kann dieses Paket von einem Edge Port oder einem Edge-Tunnel empfangen. Der Switch überprüft, ob der Switch das Paket von einem Edge-Tunnel empfangen hat (Vorgang 404). Wenn der Switch das Paket von einem Edge-Tunnel empfangen hat, dann entkapselt der Switch den Edge-Tunnel-Verkapselungs-Header (Vorgang 406). Wenn der Switch das Paket nicht von einem Edge-Tunnel empfangen hat oder den Edge-Tunnel-Verkapselungs-Header entkapselt hat, dann überprüft der Switch, ob das Paket für den lokalen Switch bestimmt ist (Vorgang 408).
Wenn der Switch als ein IP-Gateway für einen End Host arbeitet, kann der Switch das Ziel für das Paket sein. Der Switch entfernt dann den Header des Pakets (z.B. den Ethernet Header) und fördert die Payload (Nutzlast) (z.B. ein inneres IP-Paket) zu der oberen Schicht (z.B. für die IP-Verarbeitung) (Vorgang 410). Die Payload wird somit zu dem Paket. Wenn das Paket nicht für den lokalen Switch bestimmt ist oder bei der Förderung zu der oberen Schicht erhält der Switch das Fabric Label und die Tunnel-Kennung, die auf die Zieladresse des Pakets gemappt sind (Vorgang 412), wie in Verbindung mit 1 C beschrieben worden ist. Der Switch bringt einen NSH an dem Paket an und nimmt das erhaltene Fabric Label in den NSH als das Destination Label bzw. Ziel-Label auf (Vorgang 414). Der Switch nimmt auch das lokale Fabric Label in den NSH als das Source Label bzw. Quell-Label auf (Vorgang 416).
Der Switch erhält dann die Weiterleitungsinformationen, die durch die Tunnel-Kennung indexiert sind (Vorgang 418), und verkapselt das Paket in einem Tunnel-Verkapselungs-Header, der auf der Grundlage der erhaltenen Weiterleitungsinformationen erzeugt worden ist (Vorgang 420), wie dies in Verbindung mit 1C beschrieben worden ist. Diese Weiterleitungsinformationen können die Source- und Destination-VTEP-IP-Adressen (Quell- und Ziel-VTEP-IP-Adressen) des Tunnels und eine MAC-Adresse des Next-Hop Switch (Folgesprung-Switch) enthalten. Der Switch leitet dann das verkapselte Paket über den Inter-Fabric-Tunnel, der durch die Tunnel-Kennung identifiziert ist, weiter (Vorgang 422).
Wenn das Paket für einen End Host bestimmt ist, der über eine entfernte Fabric erreichbar ist, leitet der Switch das Paket zu einem Backbone Node weiter. 4B zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einem Tunnel empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs empfängt der Switch ein Paket über einen Tunnel (Vorgang 432) und entkapselt den Verkapselungs-Header, um auf den NSH des Pakets zuzugreifen (Vorgang 434). Der Switch überprüft, ob das Destination Label (Ziel-Label) des NSH das Label der lokalen Fabric ist (Vorgang 436).
Wenn das Destination Label des NSH das Label der lokalen Fabric ist, überprüft der Switch, ob die Zieladresse des Pakets lokal erreichbar ist (Vorgang 446). Wenn die Zieladresse nicht lokal erreichbar ist, identifiziert der Switch einen Intra-Fabric-Tunnel (d.h. die VTEP-IP-Adresse) und dessen Tunnel-Kennung, die mit der Zieladresse des Pakets assoziiert sind (Vorgang 448). Andererseits identifiziert der Switch dann, wenn das Destination Label des NSH nicht das Label der lokalen Fabric ist, einen Inter-Fabric-Tunnel und dessen Tunnel-Kennung, die mit dem Destination Fabric Label assoziiert sind (Vorgang 438).
Nach dem identifizieren eines Inter-Fabric- oder Intra-Fabric-Tunnels für das Paket (Vorgang 438 oder 448) erhält der Switch die Weiterleitungsinformationen, die durch die Tunnel-Kennung des identifizierten Tunnels indexiert sind (Vorgang 440). Der Switch verkapselt das Paket in einem Tunnel-Verkapselungs-Header, der auf der Basis der erhaltenen Weiterleitungsinformationen erzeugt worden ist (Vorgang 442), und leitet das verkapselte Paket über den durch die Tunnel-Kennung identifizierten Tunnel weiter (Vorgang 444).
Wenn die Zieladresse lokal erreichbar ist, entfernt der Switch den an dem Paket angebrachten NSH (Vorgang 450) und überprüft, ob die Zieladresse des Pakets über einen Edge-Tunnel erreichbar ist (Vorgang 452). Wenn die Zieladresse über einen Edge-Tunnel erreichbar ist, verkapselt der Switch das Paket und leitet das verkapselte Paket über den Edge-Tunnel weiter (Vorgang 454). Wenn andererseits das Ziel nicht über einen Edge-Tunnel erreichbar ist, leitet der Switch das Paket über den Edge Port weiter, der mit der Zieladresse des Pakets assoziiert ist (Vorgang 456).
4C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Backbone Node (Backbone-Knoten), der ein Multi-Ziel-Paket weiterleitet, das ausgehend von einem Tunnel empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Ein Multi-Ziel-Paket kann ein Rundsende- bzw. Broadcast-Paket, ein Multicast-Paket oder ein unbekanntes Unicast-Paket sein. Während des Betriebs empfängt der Node (Knoten) ein Multi-Ziel-Paket über einen Eingangstunnel (Vorgang 462) und identifiziert eine Intra-Fabric-Tunnel-Gruppe, die mit dem Eingangstunnel assoziiert ist (Vorgang 464). Der Node verhindert dann, dass der lokale Switch die Weiterleitung über die identifizierte Intra-Fabric-Tunnel-Gruppe ausführt (Vorgang 466). Der Node ermittelt, ob sich der Node in anderen Edge Fabrics befindet (d.h. der Node ermittelt, ob sich der Node in anderen Intra-Fabric-Tunnel-Gruppen befindet) (Vorgang 468).
Wenn sich der Node in anderen Edge Fabrics befindet, erhält der Node die Weiterleitungsinformationen, die mit einem jeweiligen Tunnel in der Intra-Fabric-Tunnel-Gruppe der Edge Fabric assoziiert sind (Vorgang 470). Der Node verkapselt das Paket in einem Tunnel-Verkapselungs-Header für einen jeweiligen Tunnel in der Intra-Fabric-Tunnel-Gruppe (Vorgang 472) und leitet das verkapselte Paket über den Tunnel in der Intra-Fabric-Tunnel-Gruppe weiter (Vorgang 474). Der Node fährt dann damit fort, zu ermitteln, ob sich der Node in anderen Edge Fabrics befindet (Vorgang 468).
Wenn sich der Node nicht in anderen Edge Fabrics befindet, erhält der Node die Weiterleitungsinformationen, die mit einem jeweiligen Tunnel in der Inter-Fabric-Tunnel-Gruppe der Backbone Fabric assoziiert sind (Vorgang 476). Der Node verkapselt das Paket in einem Tunnel-Verkapselungs-Header für einen jeweiligen Tunnel in der Inter-Fabric-Tunnel-Gruppe (Vorgang 478) und leitet das verkapselte Paket über den Tunnel in der Inter-Fabric-Tunnel-Gruppe weiter (Vorgang 480).
MLAG (Multi-Chassis Link Aggregation Group)
5A veranschaulicht eine beispielhafte MLAG mit einem virtuellen Tunnel-Endpunkt in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel ist ein End Host 502 mit zwei separaten Switches gekoppelt, die Mitglieder einer Fabric sind. Die zwei separaten physikalischen Links bilden eine MLAG 504. Aus der Perspektive des End Host 502 verhält sich die MLAG 504 wie eine herkömmliche LAG (Link Aggregation Group), und der End Host 502 kann beide physikalischen Links in der MLAG 504 so verwenden, als ob diese mit demselben Switch verbunden sind. Die Switches in der MLAG 504 können als Partner-Switches bezeichnet werden.
Außerdem bilden die zwei physischen Switches einen VTEP 506, der optional durch eine virtuelle IP-Adresse identifiziert werden kann. Ein Inter-Switch-Link 507 kann von diesen beiden Switches verwendet werden, um Zustandsinformationen auszutauschen, so dass in einem Fall eines Link-Ausfalls ein Switch den Verkehr, der vorher von dem ausgefallenen Link übertragen worden ist, übernehmen kann. Während des Betriebs kann der End Host 502 einen Edge-VXLAN-Tunnel 503 mit einem VTEP 506 einrichten. Des Weiteren kann der VTEP 506 einen Intra-Fabric-Tunnel 508 mit jedem anderen Switch innerhalb derselben Fabric einrichten. Es ist anzumerken, dass sowohl der Edge-Tunnel 503 als auch der Intra-Fabric-Tunnel 508 die virtuelle IP-Adresse des VTEP 506 als ihre Quell-IP verwenden können. Mit anderen Worten, der VTEP 506 kann sich selbst wie ein anderer Switch in der Fabric präsentieren.
Wenn Switches in dem VTEP 506 einen NSH an ein Paket anfügen, das über die MLAG 504 empfangen wird, nimmt der Switch eine MLAG-Kennung der MLAG 504 als das Source Label in den NSH auf. Dies erlaubt das Empfangen des VTEP des Tunnels 508, um zu ermitteln, dass das Paket ursprünglich über die MLAG 504 empfangen worden ist. Wenn zum Beispiel ein Backbone Node ein Paket empfängt, dann kann der Node auf der Basis des Source Label in dem NSH ermitteln, dass das Paket ausgehend von der MLAG 504 empfangen wird. Der Node ersetzt dann die MLAG-Kennung durch das Fabric Label der Eingangs-Edge Fabric und leitet das Paket über einen Inter-Fabric-Tunnel weiter.
In einigen Ausführungsformen sind die Fabric Labels und die MLAG-Kennungen von unterschiedlichen Bereichen zugeordnet. Als Folge davon kann der Node ermittelt, dass das Source Label eine MLAG-Kennung ist. In einigen weiteren Ausführungsformen bewahrt ein Backbone Node ein Mapping zwischen der virtuellen IP-Adresse des VTEP 506 und der MLAG-Kennung. Wenn der Node die virtuelle IP-Adresse als die Source- bzw. Quell-IP-Adresse des Verkapselungs-Header eines Pakets identifiziert, ermittelt der Node, das das Source Label des NSH des Pakets eine MLAG-Kennung ist.
5B zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Switch, der ein Paket weiterleitet, das ausgehend von einer MLAG empfangen wird, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs empfängt der Switch ein Paket von dem End Host über die MLAG (Vorgang 522) und überprüft, ob das Paket für einen Partner-Switch bestimmt ist (Vorgang 524). Wenn das Paket für den Partner-Switch bestimmt ist, leitet der Switch das Paket zu dem Partner-Switch weiter (Vorgang 538), wie dies in Verbindung mit 4A beschrieben worden ist. Wenn das Paket nicht für den Partner-Switch bestimmt ist, erhält der Switch das Fabric Label und die Tunnel-Kennung, die auf die Zieladresse des Pakets gemappt sind (Vorgang 526), wie dies in Verbindung mit 4A beschrieben worden ist. Der Switch bringt einen NSH an dem Paket an und nimmt das erhaltene Fabric Label in den NSH als das Destination Label auf (Vorgang 528).
Der Switch nimmt auch die MLAG-Kennung in den NSH als das Source Label auf (Vorgang 530). Der Switch erhält dann die Weiterleitungsinformationen, die durch die Tunnel-Kennung indexiert sind (Vorgang 532), und verkapselt das Paket in einem Tunnel-Verkapselungs-Header, der auf der Basis der erhaltenen Weiterleitungsinformationen erzeugt worden ist (Vorgang 534), wie dies in Verbindung mit 1C beschrieben worden ist. Diese Weiterleitungsinformationen können die Quell- und Ziel- bzw. Source- und Destination-VTEP-IP-Adressen des Tunnels und eine MAC-Adresse des Next-Hop Switch enthalten. Der Switch leitet dann das verkapselte Paket über den Inter-Fabric-Tunnel, der durch die Tunnel-Kennung identifiziert ist, weiter (Vorgang 536).
5C zeigt ein Ablaufdiagramm, das einen beispielhaften Prozess eines Backbone Node, der ein Paket mit einer MLAG-Kennung weiterleitet, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Während des Betriebs empfängt der Switch ein Paket von einem Intra-Fabric-Tunnel (Vorgang 552) und identifiziert eine MLAG-Kennung als das Source Label in dem NSH (Vorgang 554). Der Switch ersetzt dann die MLAG-Kennung in dem NSH durch das Fabric Label des Eingangs-Fabric Switch (Vorgang 556). Der Switch verkapselt das Paket und leitet das verkapselte Paket über einen Tunnel weiter (Vorgang 558), wie dies in Verbindung mit 4B beschrieben worden ist.
Hierarchische Overlay-Tunnel
6 veranschaulicht eine beispielhafte Konfiguration eines Fabric Switch auf der Basis von hierarchischen Overlay-Tunneln in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel umfasst eine Fabric drei VTEPs 607, 611 und 615. Der VTEP 607 ist durch die Switches 604 und 606 gebildet, der VTEP 611 ist durch die Switches 608 und 610 gebildet, und der VTEP 615 ist durch die Switches 612 und 614 gebildet. Ein End Host 602 ist mit dem VTEP 607 über eine MLAG 603 gekoppelt, was auf Links zu den Switches 604 und 606 basiert. Im Allgemeinen kann ein End Host 602 mit dem VTEP 607 über einen Edge-Tunnel 632 kommunizieren. In ähnlicher Weise ist ein End Host 603 mit dem VTEP 611 über eine MLAG 607 gekoppelt, was auf Links zu den Switches 608 und 610 basiert. Der End Host 603 kann mit dem VTEP 611 über einen Edge-Tunnel 634 kommunizieren. In diesem Beispiel können die VTEPs 607, 611 und 615 als logische Einheiten betrachtet werden, die die Fabric bilden.
Innerhalb der Fabric können alle VTEPs eine voll vermaschte logische Topologie unter Verwendung von Intra-Fabric-Tunneln bilden. Insbesondere ist ein Intra-Fabric-Tunnel 626 zwischen den VTEPs 607 und 615 gebildet; ein Intra-Fabric-Tunnel 622 ist zwischen den VTEPs 607 und 611 gebildet; und ein Intra-Fabric-Tunnel 624 ist zwischen den VTEPs 611 und 615 gebildet. Außerdem dient der VTEP 615 auch als ein Gateway-VTEP zu dem Backbone-Netzwerk, und er kann einen oder mehrere Inter-Fabric-Tunnel aufrecht erhalten bzw. unterhalten, wie etwa den Inter-Fabric-Tunnel 630.
Beispielhafter Switch
7 veranschaulicht einen beispielhaften Mitglieds-Switch in einem IPbasierten Fabric Switch in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. In diesem Beispiel kann ein Switch 700 eine Anzahl von Kommunikationsports 702, einen Paketprozessor 710 aufweisen. Der Switch 700 weist auch einen Prozessor 749, eine Speichereinrichtung 750, eine Switch-Steuervorrichtung 730, die eine Fabric-Label-Verwaltungsvorrichtung 732 einschließt, auf. Der Switch 700 weist des Weiteren eine VTEP-Verwaltungsvorrichtung 720, eine Tunnelverwaltungsvorrichtung 722, eine Link-Aggregations-Vorrichtung 724 und eine Paketweiterleitungsvorrichtung 726 auf.
Während des Betriebs ist die Fabric-Label-Verwaltungsvorrichtung für die Aufrechterhaltung des Mapping zwischen der MAC in einer entfernten Fabric und dem Label der entsprechenden entfernten Fabric zuständig. Außerdem ist die Switch-Steuervorrichtung 730 auch für die Aufrechterhaltung eines lokalen MAC-auf-VTEP-Mapping in der lokalen Fabric zuständig. Die VTEP-Verwaltungsvorrichtung ist für die Aufrechterhaltung des lokalen VTEP-Zustands zuständig, wie etwa für das Erhalten und das Bewahren der virtuellen IP, die dem VTEP zugewiesen ist, und des Mapping der virtuellen IP des VTEP auf die eigene IP des Switch 700. Die Tunnelverwaltungsvorrichtung 722 ist für das Aufrechterhalten des Zustands von allen Edge-Tunneln, Intra-Fabric-Tunneln und optional Inter-Fabric-Tunneln zuständig. Insbesondere kann die Tunnelverwaltungsvorrichtung 722 eine Datenstruktur aufrecht erhalten, die die IP/UDP-Tupel-Informationen jedes Tunnels speichert, und sie speichert diese Datenstruktur in der Speichereinrichtung 750.
Die Link-Aggregations-Vorrichtung 724 ist für das Aufrechterhalten der MLAGs mit den End Hosts zuständig. Der Paketprozessor 710 ist für das Entkapseln und Verkapseln bzw. Einkapseln von Paketen zuständig. Die Paketweiterleitungsvorrichtung 726 ist für das Ermitteln zuständig, welcher Tunnel verwendet werden soll, wenn ein Paket weitergeleitet wird, und welche Headers verwendet werden sollen, bevor das Paket auf einem geeigneten Tunnel weitergeleitet wird.
Es ist anzumerken, dass die oben genannten Vorrichtungen als Anweisungen implementiert sein können, die in der Speichereinrichtung 750 gespeichert sind. Wenn diese Anweisungen von dem Prozessor 749 ausgeführt werden, können sie bewirken, dass der Prozessor eines oder mehrere der oben erwähnten Verfahren durchführt.
Zusammenfassend ist in den Ausführungsformen der vorliegenden Erfindung das Problem des Aufbauens eines vielseitigen, kosteneffektiven und skalierbaren Layer-2-Switching-Systems dadurch gelöst, dass eine Topologie-agnostische Fabric Switch auf der Basis eines Underlay-Layer-3-Protokolls mit einem hierarchischen Overlay-Tunneling gebildet wird. Diese Fabric-Switch-Architektur kann einen oder mehrere Fabric Switches einschließen, die miteinander durch ein Underlay-Netzwerk verbunden sind, das auf existierenden Layer-3- und Tunneling-Protokollen, wie etwa IP und VXLAN, basieren kann. Jeder Fabric Switch kann eine Anzahl an physischen Switches enthalten, die durch ein ähnliches Underlay-Netzwerk unter Verwendung der gleichen Layer-3- und Tunneling-Protokolle miteinander verbunden sind. Das Problem der Handhabung einer großen Anzahl an MAC-Adressen in einer erweiterten Layer-2-Broadcast-Domain ist dadurch gelöst, dass ein hierarchischer Tunneling-Mechanismus und ein Label-basierter Fabric-bezogener Adressenaggregationsmechanismus vorgesehen sind.
Die hier beschriebenen Verfahren und Prozesse können als Code und/oder Daten verkörpert sein, der bzw. die in einem computerlesbaren permanenten Speichermedium gespeichert sein kann bzw. können. Wenn ein Computersystem den Code und/oder die Daten, der bzw. die in dem computerlesbaren permanenten Speichermedium gespeichert ist bzw. sind, liest und ausführt, führt das Computersystem die Verfahren und Prozesse durch, die als Datenstrukturen und Code verkörpert sind und in dem Medium gespeichert sind.
Die hier beschriebenen Verfahren und Prozesse können durch Hardware-Module oder -Vorrichtungen ausgeführt werden und/oder in diesen enthalten sein. Diese Module oder Vorrichtungen können einen ASIC-(Application-Specific Integrated Circuit; anwendungsspezifischen integrierten Schaltungs)-Chip, ein FPGA (Field-Programmable Gate Array; vom Anwender programmierbares Gate-Array), einen dedizierten oder gemeinsam benutzten Prozessor, der ein bestimmtes Software-Modul oder einen Teil eines Codes zu einer bestimmten Zeit ausführt, und/oder andere programmierbare Logikgeräte, die jetzt bekannt sind oder später entwickelt werden, einschließen, ohne darauf beschränkt zu sein. Wenn die Hardware-Module oder -Vorrichtungen aktiviert werden, führen sie die in ihnen enthaltenen Verfahren und Prozesse durch.
Die obigen Beschreibungen von Ausführungsformen der vorliegenden Erfindung sind nur zu Zwecken der Veranschaulichung und der Beschreibung präsentiert worden. Sie sind nicht dazu gedacht, die vorliegende Offenbarung zu erschöpfen oder zu beschränken. Dementsprechend werden den Fachleuten bzw. Anwendern auf dem Gebiet viele Modifikationen und Variationen offensichtlich sein. Der Schutzumfang der vorliegenden Erfindung ist durch die angehängten Ansprüche definiert.

Claims

Switch (358, 700), der Folgendes aufweist: eine Tunnelverwaltungsvorrichtung (722), die dafür konfiguriert ist, einen lokalen Inter-Switch-Tunnel (118, 122, 507) und einen Inter-Fabric-Tunnel (120, 366, 630) aufrecht zu erhalten, wobei der lokale Inter-Switch-Tunnel (118, 122, 507) eine Kommunikation zwischen dem Switch (113, 121, 123) und einem zweiten Switch (113, 121, 123) in einem ersten Netzwerk (104, 106, 108, 140, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht, und wobei der Inter-Fabric-Tunnel (120, 366, 630) eine Kommunikation mit einem dritten Switch (113, 121, 123) in einem zweiten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht; und eine Paket-Header-Verwaltungsvorrichtung (720, 732), die dafür konfiguriert ist, einen ersten Tunnel-Header eines Pakets (332), das ausgehend von dem lokalen Inter-Switch-Tunnel (118, 122, 507) empfangen wird, zu entkapseln und das Paket (332) mit einem zweiten Tunnel-Header für die Übertragung über den Inter-Fabric-Tunnel (120, 366, 630) einzukapseln, wobei der Switch (358, 700) dafür konfiguriert ist, zu verhindern, dass ein Paket (332), das ausgehend von einem Inter-Fabric-Tunnel (120, 366, 630) empfangen wird, auf einem anderen Inter-Fabric-Tunnel (120, 366, 630) weitergeleitet wird, und das Paket (332) nur auf einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) weiterzuleiten, über den Switches (105, 111) innerhalb einer Netzwerks (104, 106, 108, 140) miteinander verbunden sind.
Switch nach Anspruch 1, wobei die Tunnelverwaltungsvorrichtung (722) des Weiteren dafür konfiguriert ist, einen Edge-Tunnel (116, 124, 131, 312, 362, 503, 632, 634) zu verwalten, der eine Kommunikation mit einem End Host (101, 102, 103, 110, 130, 352, 360, 502, 602, 603) ermöglicht.
Switch nach Anspruch 1, wobei der zweite Tunnel-Header eine Kennung für das zweite Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) enthält.
Switch nach Anspruch 1, wobei der zweite Tunnel-Header einen Network Service Header (Netzwerk-Service-Header) enthält.
Switch nach Anspruch 1, der des Weiteren eine Datenstruktur aufweist, die ein Mapping zwischen einer MAC-(Medium Access Control)-Adresse und einem virtuellen Tunnel-Endpunkt (114) speichert.
Switch nach Anspruch 1, der des Weiteren eine Datenstruktur aufweist, die ein Mapping zwischen einer MAC-Adresse und einer Kennung des zweiten Netzwerks (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) speichert.
Switch nach Anspruch 1, der des Weiteren eine Paketweiterleitungsvorrichtung aufweist, die dafür konfiguriert ist, zu verhindern, dass ein Paket (332), das ausgehend von einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) empfangen wird, auf einem anderen Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) weitergeleitet wird.
Switch nach Anspruch 1, der des Weiteren eine Paketweiterleitungsvorrichtung aufweist, die dafür konfiguriert ist, eine MAC-Adresse in eine Weiterleitungs-Hardware des Switch (113, 121, 123) in Reaktion auf die Identifizierung der MAC-Adresse in einem Paket (332) zu laden.
Verfahren, das die folgenden Schritte umfasst: Aufrechterhalten eines lokalen Inter-Switch-Tunnels (118, 122, 507) und eines Inter-Fabric-Tunnels (120, 366, 630), wobei der lokale Inter-Switch-Tunnel (118, 122, 507) eine Kommunikation zwischen einem Switch (113, 121, 123) in einem lokalen Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) und einem zweiten Switch (113, 121, 123) in einem ersten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht, und wobei der Inter-Fabric-Tunnel (120, 366, 630) eine Kommunikation mit einem dritten Switch (113, 121, 123) in einem zweiten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht; Entkapseln eines ersten Tunnel-Headers eines Pakets (332), das ausgehend von dem lokalen Inter-Switch-Tunnel (118, 122, 507) empfangen wird; Verkapseln des Pakets (332) mit einem zweiten Tunnel-Header für eine Übertragung über den Inter-Fabric-Tunnel (120, 366, 630); Verhindern, dass ein Paket (332), das von einem Inter-Fabric-Tunnel (120, 366, 630) empfangen wird, auf einem anderen Inter-Fabric-Tunnel (120, 366, 630) weitergeleitet wird; und Weiterleiten des Pakets (332) auf einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624), über den Switches (105, 111) innerhalb einer Netzwerks (104, 106, 108, 140) miteinander verbunden sind.
Verfahren nach Anspruch 9, das des Weiteren das Verwalten eines Edge-Tunnels (116, 124, 131, 312, 362, 503, 632, 634) umfasst, der eine Kommunikation zwischen dem Switch (113, 121, 123) mit einem End Host (101, 102, 103, 110, 130, 352, 360, 502, 602, 603) ermöglicht.
Verfahren nach Anspruch 9, wobei der zweite Tunnel-Header eine Kennung für das zweite Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) enthält.
Verfahren nach Anspruch 9, wobei der zweite Tunnel-Header einen Network Service Header (Netzwerk-Service-Header) enthält.
Verfahren nach Anspruch 9, das des Weiteren das Speichern eines Mapping zwischen einer MAC-(Medium Access Control)-Adresse und einem virtuellen Tunnel-Endpunkt (114) umfasst.
Verfahren nach Anspruch 9, das des Weiteren das Speichern eines Mapping zwischen einer MAC-Adresse und einer Kennung einer entfernten Fabric umfasst.
Verfahren nach Anspruch 9, das des Weiteren das Verhindern, dass ein Paket (332), das ausgehend von einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) empfangen wird, auf einem anderen Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) weitergeleitet wird, umfasst.
Verfahren nach Anspruch 9, das des Weiteren das Laden einer MAC-Adresse in eine Weiterleitungs-Hardware des Switch (113, 121, 123) in Reaktion auf die Identifizierung der MAC-Adresse in einem Paket (332) umfasst.
Datenverarbeitungssystem, das einen Prozessor und eine Speichereinrichtung aufweist, wobei die Speichereinrichtung Anweisungen speichert, die dann, wenn sie von dem Prozessor ausgeführt werden, bewirken, dass der Prozessor ein Verfahren ausführt, wobei das Verfahren die folgenden Schritte umfasst: Aufrechterhalten eines lokalen Inter-Switch-Tunnels (118, 122, 507) und eines Inter-Fabric-Tunnels (120, 366, 630), wobei der lokale Inter-Switch-Tunnel (118, 122, 507) eine Kommunikation zwischen einem Switch (113, 121, 123) in einem lokalen Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) und einem Switch (113, 121, 123) in einem ersten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht, und wobei der Inter-Fabric-Tunnel (120, 366, 630) eine Kommunikation mit einem dritten Switch (113, 121, 123) in einem zweiten Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) ermöglicht; Entkapseln eines Pakets (332), das ausgehend von dem lokalen Inter-Switch-Tunnel (118, 122, 507) empfangen wird; und Verkapseln des Pakets (332) mit einem zweiten Tunnel-Header für eine Übertragung über den Inter-Fabric-Tunnel (120, 366, 630); wobei der Switch (358, 700) dafür konfiguriert ist, zu verhindern, dass ein Paket (332), das ausgehend von einem Inter-Fabric-Tunnel (120, 366, 630) empfangen wird, auf einem anderen Inter-Fabric-Tunnel (120, 366, 630) weitergeleitet wird, und das Paket (332) nur auf einem Intra-Fabric-Tunnel (118, 122, 124, 364, 508, 626, 624) weiterzuleiten, über den Switches (105, 111) innerhalb einer Netzwerks (104, 106, 108, 140) miteinander verbunden sind.
Datenverarbeitungssystem nach Anspruch 17, wobei das Verfahren des Weiteren das Verwalten eines Edge-Tunnels (116, 124, 131, 312, 362, 503, 632, 634) umfasst, der eine Kommunikation mit einem End Host (101, 102, 103, 110, 130, 352, 360, 502, 602, 603) ermöglicht.
Datenverarbeitungssystem nach Anspruch 17, wobei der zweite Tunnel-Header eine Kennung für das zweite Netzwerk (104, 106, 108, 140) von miteinander verbundenen Switchen (105, 111) enthält.
Datenverarbeitungssystem nach Anspruch 17, wobei der zweite Tunnel-Header einen Network Service Header (Netzwerk-Service-Header) enthält.