DE102022126662A1

DE102022126662A1 - Effiziente Verkehrsumleitung für einen MCLAG für kontrollierte Nichtverfügbarkeitsereignisse

Info

Publication number: DE102022126662A1
Application number: DE102022126662.1A
Authority: DE
Inventors: Venkatachalam Swaminathan; Venkatavaradhan Devarajan
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2022-04-12
Filing date: 2022-10-13
Publication date: 2023-10-12
Also published as: CN116962284A; US20230327981A1

Abstract

Ein System zur Erleichterung der Verkehrsumleitung für eine Multi-Chassis Link Aggregation Group (MCLAG) wird bereitgestellt. Während des Betriebs kann das System unter Verwendung einer ersten Schnittstelle eines ersten Switches an einer MCLAG teilnehmen. Die MCLAG kann auch eine zweite Schnittstelle eines zweiten Switches umfassen. Auf der Grundlage einer vorbestimmten Nichtverfügbarkeit des ersten Switches kann das System eine Abfolge von Anwendungen für eine Vielzahl von Verkehrsweiterleitungskonfigurationen bestimmen. Eine entsprechende Konfiguration kann die Schleifenvermeidung für den über den MCLAG weitergeleiteten Verkehr erleichtern. Das System kann dann die Vielzahl von Konfigurationen auf den ersten Switch anwenden, basierend auf der Sequenz von Anwendungen, um Unicast-Verkehr vom ersten Switch zum zweiten Switch umzuleiten. Dabei kann das Anwenden einer jeweiligen Konfiguration das Programmieren der entsprechenden Switch-Hardware mit der Konfiguration beinhalten. Anschließend kann das System eine Reihe von Operationen auf dem ersten Switch durchführen, die die vorbestimmte Nichtverfügbarkeit auslösen.

Description

HINTERGRUND
Feld
Die vorliegende Offenbarung bezieht sich auf Kommunikationsnetze. Genauer gesagt bezieht sich die vorliegende Offenbarung auf ein Verfahren und ein System zur effizienten Umleitung des Verkehrs für eine Multi-Chassis-Link-Aggregationsgruppe (MCLAG) bei kontrollierten Nichtverfügbarkeitsereignissen.
KURZBESCHREIBUNG DER Zeichungen

1A zeigt ein Beispiel für ein Netz, das eine effiziente Verkehrsumleitung für MCLAGs bei kontrollierter Nichtverfügbarkeit unterstützt, gemäß einem Aspekt der vorliegenden Anwendung.
1 B zeigt ein Beispiel für eine Reihe von Konfigurationen, die eine effiziente Verkehrsumleitung für MCLAGs bei kontrollierter Nichtverfügbarkeit gemäß einem Aspekt der vorliegenden Anwendung ermöglichen.
2A zeigt ein Beispiel für sequenzielle Konfigurationen, die den Verkehr für eine MCLAG bei kontrollierter Nichtverfügbarkeit eines teilnehmenden Geräts der MCLAG effizient umleiten, gemäß einem Aspekt der vorliegenden Anwendung.
2B zeigt ein Beispiel für sequenzielle Konfigurationen, die den Verkehr für eine MCLAG zur Wiederherstellung nach einem kontrollierten Ereignis eines teilnehmenden Geräts der MCLAG gemäß einem Aspekt der vorliegenden Anwendung effizient wiederherstellen.
3 zeigt ein Beispiel für die Verkehrsweiterleitung für eine MCLAG während der sequenziellen Konfigurationen für die kontrollierte Nichtverfügbarkeit eines teilnehmenden Geräts der MCLAG gemäß einem Aspekt der vorliegenden Anwendung.
4A zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das sequenzielle Konfigurationen anwendet, die den Verkehr von dem Gerät effizient umleiten, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
4B zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das lokal eine Konfiguration anwendet, die den Verkehr von einem entfernten teilnehmenden Gerät effizient umleitet, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
4C zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das eine entsprechende Konfiguration zur effizienten Umleitung des Datenverkehrs von dem Gerät anwendet, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
5A zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das sequenzielle Konfigurationen anwendet, die den Verkehr zum Gerät effizient wiederherstellen, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
5B zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das lokal eine Konfiguration anwendet, die den Verkehr zu einem entfernten teilnehmenden Gerät effizient wiederherstellt, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
6 zeigt ein Beispiel für einen Switch, der eine effiziente Verkehrsumleitung für MCLAGs bei kontrollierten Nichtverfügbarkeitsereignissen unterstützt, gemäß einer Ausführungsform der vorliegenden Anwendung.

In den Abbildungen beziehen sich gleiche Ziffern auf die gleichen Elemente der Abbildung.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung soll den Fachmann in die Lage versetzen, die Erfindung herzustellen und zu verwenden, und wird im Zusammenhang mit einer bestimmten Anwendung und deren Anforderungen gegeben. Verschiedene Modifikationen an den offengelegten Beispielen werden für den Fachmann leicht ersichtlich sein, und die hierin definierten allgemeinen Grundsätze können auf andere Beispiele und Anwendungen angewendet werden, ohne vom Geist und Umfang der vorliegenden Erfindung abzuweichen. Daher ist die vorliegende Erfindung nicht auf die gezeigten Beispiele beschränkt, sondern hat den weitestgehenden Anwendungsbereich, der mit den Ansprüchen vereinbar ist.
Das Internet kann als Übertragungsmedium für eine Vielzahl von Anwendungen dienen, die auf physischen und virtuellen Geräten laufen. Solche Anwendungen haben eine steigende Nachfrage nach Bandbreite mit sich gebracht. Aus diesem Grund versuchen die Gerätehersteller, größere Switches mit erheblichen Übertragungsmöglichkeiten zu bauen. Um die Übertragungskapazität zwischen zwei Geräten zu erhöhen, können mehrere Links zwischen den Geräten zu einer Link Aggregation Group (LAG) zusammengeschlossen werden. Ein Benutzer (z. B. ein Netzwerkadministrator) kann zwei oder mehr Ports auf jedem der Geräte konfigurieren, um sie für die LAG zu kombinieren. Die kombinierten Ports können als virtuelle Schnittstelle dargestellt werden, die die Summe der Bandbreiten der einzelnen Ports aufweist.
Eine LAG kann weiter verbessert werden, wenn ein Gerät mit mehreren Geräten verbunden werden kann und die Verbindungen, die die Geräte verbinden, zu einer einzigen Verbindung zusammengefasst werden können. Solche aggregierten Verbindungen, die über mehrere Geräte verteilt sind, können als Multi-Chassis Link Aggregation Group (MCLAG) bezeichnet werden. Die an der MCLAG beteiligten Geräte können als teilnehmende Geräte bezeichnet werden. Typischerweise kann ein entsprechendes Paar teilnehmender Geräte über einen Inter-Switch-Link (ISL) miteinander gekoppelt werden. Wenn eines der teilnehmenden Geräte nicht mehr verfügbar ist, kann der Verkehr über die ISL an ein anderes teilnehmendes Gerät umgeleitet werden. Das andere teilnehmende Gerät kann dann den Verkehr zum und vom MCLAG weiterleiten. Auf diese Weise können sich die teilnehmenden Geräte des MCLAG gegenseitig eine hohe Verfügbarkeit ermöglichen.
Ein Aspekt der vorliegenden Technologie kann ein System zur Erleichterung der Verkehrsumleitung für eine MCLAG bereitstellen. Während des Betriebs kann das System an einer MCLAG teilnehmen, indem es eine erste Schnittstelle eines ersten Switches eines Netzwerks verwendet. Die MCLAG kann auch eine zweite Schnittstelle eines zweiten Switches des Netzwerks umfassen. Basierend auf einer vorbestimmten Nichtverfügbarkeit des ersten Switches kann das System eine Abfolge von Anwendungen für eine Vielzahl von Verkehrsweiterleitungskonfigurationen bestimmen. Eine entsprechende Verkehrsweiterleitungskonfiguration kann die Schleifenvermeidung für über den MCLAG weitergeleiteten Verkehr erleichtern. Das System kann dann die Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch anwenden, basierend auf der Abfolge von Anwendungen, um Unicast-Verkehr vom ersten Switch zum zweiten Switch umzuleiten. Dabei kann das Anwenden einer jeweiligen Verkehrsweiterleitungskonfiguration das Programmieren der entsprechenden Switch-Hardware mit der Verkehrsweiterleitungskonfiguration beinhalten. Anschließend kann das System eine Reihe von Operationen auf dem ersten Switch durchführen, die die vorbestimmte Nichtverfügbarkeit auslösen.
In einer Variante dieses Aspekts kann das System nach der Wiederherstellung der vorbestimmten Nichtverfügbarkeit eine zweite Sequenz von Anwendungen für die Mehrzahl von Verkehrsweiterleitungskonfigurationen bestimmen. Das System kann dann die Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch anwenden, basierend auf der zweiten Sequenz von Anwendungen, um den Unicast-Verkehr für den MCLAG wiederherzustellen.
In einer weiteren Variante kann die zweite Abfolge von Anwendungen eine umgekehrte Abfolge von Anwendungen sein.
In einer Variante dieses Aspekts kann der MCLAG in einer Vielzahl von MCLAGs enthalten sein, die für den ersten und zweiten Switch konfiguriert sind. Das System kann dann die Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch für eine entsprechende MCLAG der Vielzahl von MCLAGs anwenden.
In einer weiteren Variante kann das System den Satz von Operationen auf dem ersten Switch als Reaktion auf die Anwendung der Vielzahl von Verkehrsweiterleitungskonfigurationen auf die Vielzahl von MCLAGs durchführen.
In einer Variante dieses Aspekts kann das System, um die entsprechende Switch-Hardware mit der Verkehrsweiterleitungskonfiguration zu konfigurieren, eine Bestätigung empfangen, die anzeigt, dass die Verkehrsweiterleitungskonfiguration an der entsprechenden Switch-Hardware programmiert ist, ferner umfasst. Das System kann dann mit der Anwendung einer nachfolgenden Verkehrsweiterleitungskonfiguration in der Sequenz in Reaktion auf den Empfang der Bestätigung fortfahren.
In einer Variante dieses Aspekts kann die Anwendungssequenz auch eine externe Verkehrsweiterleitungskonfiguration für den zweiten Switch enthalten. Das System kann dann den zweiten Switch auffordern, die externe Verkehrsweiterleitungskonfiguration anzuwenden, und eine Bestätigung erhalten, die anzeigt, dass die externe Verkehrsweiterleitungskonfiguration in der Switch-Hardware des zweiten Switches programmiert ist.
In einer Variante dieses Aspekts kann die Reihenfolge der Anwendungen auf den gegenseitigen Abhängigkeiten der mehreren Konfigurationen für die Verkehrsumleitung beruhen, so dass die Verkehrsumleitung vor der Deaktivierung einer lokalen Instanz des MCLAG aktiviert werden kann.
In einer Variante dieses Aspekts kann die Vielzahl der Verkehrsweiterleitungskonfigurationen das Blockieren des Flutens von Multidestinationsverkehr über den MCLAG, das Umleiten von für den MCLAG bestimmten Verkehr zum zweiten Switch und das Deaktivieren der lokalen Kommunikation für den MCLAG umfassen. Die Abfolge von Anwendungen kann auch eine externe Verkehrsweiterleitungskonfiguration enthalten, die die Weiterleitung des umgeleiteten Verkehrs über den MCLAG ermöglicht.
In einer Variante dieses Aspekts kann das System eine Benachrichtigung an einen dritten Switch des Netzes senden. Die Benachrichtigungsnachricht kann die Nichtverfügbarkeit einer Verbindung des ersten Switches im MCLAG anzeigen. Auf diese Weise kann die Benachrichtigungsnachricht es dem dritten Switch ermöglichen, sich von der Verbindung zurückzuziehen...
Die hier beschriebenen Beispiele lösen das Problem der Erleichterung der Verkehrsumleitung für einen MCLAG mit geringer zeitlicher Nichtverfügbarkeit für ein kontrolliertes Ereignis durch (i) Anwendung eines Satzes von Konfigurationen, die die Verkehrsweiterleitung über den MCLAG in einer schrittweise verriegelnden Sequenz vorschreiben, und (ii) Festschreibung einer jeweiligen Konfiguration nach Erhalt einer Bestätigung von einem entsprechenden Teil der Hardware. In einem jeweiligen Schritt der Sequenz wird eine Art der Verkehrsweiterleitung für den MCLAG von mindestens einem der beteiligten Geräte unterstützt, bevor eine andere Art der Verkehrsweiterleitung abgeschaltet wird. Auf diese Weise kann der Verkehr von einem teilnehmenden Gerät bei einer kontrollierten Nichtverfügbarkeit, z. B. bei einer Firmware-Aktualisierung, ordnungsgemäß umgeleitet werden.
Eine Veränderung in einem Netz kann durch verschiedene Ereignisse ausgelöst werden. Diese Ereignisse können in zwei Gruppen eingeteilt werden: kontrollierte (oder vorbestimmte) Ereignisse und unkontrollierte Ereignisse. Beispielsweise können vom Benutzer initiierte Ereignisse wie Neustart, Firmware-Upgrade und Link-Toggle als kontrollierte oder vorbestimmte Ereignisse bezeichnet werden, da die Auslösung solcher Ereignisse vom Benutzer vorbestimmt und kontrolliert werden kann. Andererseits können ausfall-, unfall- und katastrophenbedingte Ereignisse, wie z. B. Stromausfall, Hardwarefehler und menschliches Versagen, als unkontrollierte Ereignisse bezeichnet werden, da der Benutzer nicht kontrollieren kann, wie diese Ereignisse ausgelöst werden. Unabhängig von der Art kann ein Ereignis ein oder mehrere Elemente im Netz betreffen und den Datenverkehr im Netz beeinträchtigen.
Ein teilnehmendes Gerät kann eine oder mehrere Konfigurationen anwenden, um den Verkehrsfluss für den MCLAG zu verwalten. Beispielsweise kann das Gerät eine Konfiguration anwenden, um den Schicht-2-ISL-Verkehr (d. h. den über die ISL empfangenen Verkehr) von der Weiterleitung an den MCLAG abzuhalten. Andererseits kann das Gerät, wenn der MCLAG im Gerät nicht verfügbar ist (z. B. wenn der aktuelle Status des MCLAG nicht verfügbar ist), eine Konfiguration anwenden, um den für den MCLAG bestimmten Verkehr über die ISL an ein entferntes teilnehmendes Gerät umzuleiten. Wenn jedoch der MCLAG im Gerät verfügbar wird, kann das Gerät eine Neukonfiguration vornehmen, um die Umleitung des Verkehrs über die ISL aufzuheben. Darüber hinaus kann das Gerät eine Konfiguration anwenden, die das Fluten von Mehrzielverkehr, wie Broadcast-, unbekannten Unicast- und Multicast-Verkehr (BUM), blockiert, wenn der MCLAG nicht verfügbar ist.
Bei bestehenden Technologien kann das Gerät eine oder mehrere Konfigurationen als Reaktion auf ein Ereignis anwenden, unabhängig von dessen Typ. Selbst wenn es sich bei dem Ereignis um ein kontrolliertes Ereignis handelt, kann das Gerät die Konfigurationen anwenden, um den Datenverkehr an ein gleichrangiges teilnehmendes Gerät umzuleiten, ohne die Auswirkungen der Anwendung zu berücksichtigen. Folglich kann das Gerät ohne koordinierte Anwendung der Konfigurationen, selbst bei protokollgesteuerten Verfahren, für die Weiterleitung des Verkehrs für die MCLAG über einen längeren Zeitraum nicht verfügbar sein und eine Unterbrechung des Verkehrs verursachen. Das Problem kann noch verschärft werden, da die Anwendung der Konfigurationen von verschiedenen Daemons einer Verwaltungsanwendung (z. B. eines Betriebssystems) des Geräts verwaltet werden kann. Insbesondere können verschiedene Daemons die mit der Konfiguration verbundenen Operationen zu unterschiedlichen Zeiten durchführen.
Ein MCLAG-Daemon, der für die Verwaltung eines MCLAG zuständig sein kann, kann die Konfiguration verarbeiten und einen Programmier-Daemon benachrichtigen, um die Hardware entsprechend zu konfigurieren. Der MCLAG-Daemon kann jedoch nicht warten, bis die Hardwarekonfiguration abgeschlossen ist. In Szenarien mit hoher Auslastung kann es vorkommen, dass die Hardware die Konfigurationsanfragen des Programmier-Daemons nicht in der gleichen Geschwindigkeit wie der MCLAG-Daemon verarbeitet. Während die Hardware programmiert wird, kann der MCLAG-Daemon zusätzliche Konfigurationen verarbeiten und den Programmier-Daemon um weitere Konfigurationen bitten. Dies kann zu einer Warteschlange von Anforderungen führen und dazu, dass sich die Dämonen und die Hardware in unsynchronisierten Zuständen befinden, die mit verschiedenen Konfigurationen verbunden sind. Da einige der Konfigurationen nicht nebeneinander bestehen können (z. B. Verkehrsumleitung und Egress-Blockierung), kann es beim MCLAG aufgrund der unsynchronisierten Zustände zu weiteren Verkehrsverlusten kommen.
Außerdem kann die Leistung der Dämonen je nach der Belastung des Geräts variieren. Nimmt das Gerät an mehreren MCLAGs mit unterschiedlicher Verkehrslast teil, kann sich die Zustandsänderung einer MCLAG auf die Hardwareprogrammierung für eine andere MCLAG auswirken. Wenn beispielsweise mehrere MCLAGs in Betrieb genommen werden, kann die Hardwarefreigabe für die andere MCLAG während der Hardwareprogrammierung der MCLAG warten, je nachdem, in welcher Reihenfolge die Hardware die Konfigurationsanforderungen erhält. Darüber hinaus können die Zustandsänderungen für einen MCLAG anzeigen, ob der MCLAG betriebsbereit oder nicht verfügbar geworden ist. Andere Geräte im Netz können sich auf der Grundlage der Zustandsänderung bei der MCLAG anmelden bzw. abmelden. Es kann jedoch sein, dass nicht alle teilnehmenden Geräte bereit sind, Verkehr für die MCLAG anzunehmen oder zurückzuziehen. Die unsynchronisierten Zustände zwischen den teilnehmenden Geräten können zu weiteren Verkehrsverlusten im Netz führen.
Um dieses Problem zu lösen, kann ein teilnehmendes Gerät der MCLAG bei einem kontrollierten (oder vorher festgelegten) Nichtverfügbarkeitsereignis die Konfigurationen in einer orchestrierten Sequenz anwenden, die den Dämonen des Geräts vorschreibt, einer Ausführungsreihenfolge zu folgen, die eine geordnete Umleitung des Verkehrs gewährleistet. Die orchestrierte Abfolge kann die nachteiligen Auswirkungen des Übergangs oder der Umleitung des Datenverkehrs vom Gerät zu einem anderen teilnehmenden Gerät der MCLAG, wie z. B. den Verlust von Datenverkehr aufgrund von Nichtverfügbarkeit, verringern. Die Zustandsübergänge der mit der MCLAG verbundenen Dämonen können so geordnet werden, dass die Verbindungen zur Annahme und Weiterleitung des Verkehrs bereit sind. Die schrittweise Verriegelungssequenz kann es den Geräten der MCLAG ermöglichen, in verschiedenen Übergangszuständen zu arbeiten und den Verkehr weiterzuleiten. Bei einem entsprechenden Schritt wird ein neuer Weg für den Verkehrsfluss über den MCLAG geöffnet, bevor der Übergang von einem anderen weg erfolgt (z. B. durch Abschalten), wodurch ein „Make-before-break-Modell“ der Verkehrsumleitung für den MCLAG erleichtert wird.
Wenn der MCLAG-Daemon die Anwendung einer Konfiguration der Sequenz auf die Hardware des Geräts anfordert, kann der Daemon auf eine Bestätigung der Hardware warten, bevor er mit der nächsten Konfiguration der Sequenz fortfährt. Dadurch können der Daemon und die Hardware im gleichen Zustand arbeiten. Darüber hinaus kann die Umleitung des Datenverkehrs auch Konfigurationsaktualisierungen bei einem Peer-Gerät erfordern. Eine solche Konfiguration kann als externe Konfiguration bezeichnet werden.
Dementsprechend kann der Daemon die Anwendung der Konfiguration von einem Peer-Gerät anfordern. Der entsprechende MCLAG-Daemon des Peer-Geräts, der als Peer-Daemon bezeichnet werden kann, kann die Anforderung empfangen und die Hardware des Peer-Geräts konfigurieren. Wenn die Hardware des Peer-Geräts konfiguriert ist, kann der Peer-Daemon eine Bestätigung von der lokalen Hardware empfangen und die entsprechende Bestätigung an den anfordernden Daemon senden. Der Daemon kann dann mit der weiteren Konfiguration der Sequenz fortfahren.
Um ein kontrolliertes Nichtverfügbarkeitsereignis am Gerät auszulösen, sollte der für den MCLAG bestimmte Verkehr (d. h. der über den MCLAG weiterzuleitende Verkehr) über die ISL an das Peer-Gerät umgeleitet werden. Die Aktivierung der Verkehrsumleitung würde jedoch die Deaktivierung der Egress-Blockierung am Peer-Gerät erfordern, was zu einer Schleife im Netz führen kann. Um die Bildung einer Schleife über den MCLAG zu vermeiden, umfasst die anfängliche (oder erste) Konfiguration der Sequenz daher die Aktivierung von Flood-Blocking für den MCLAG. Das Flood-Blocking verhindert, dass Multidestinationsverkehr das Netz überflutet. Folglich kann während der Anwendung der Sequenz die Verkehrsweiterleitung auf Unicast-Verkehr beschränkt werden.
Mit anderen Worten: Während der Anwendung der nachfolgenden Konfigurationen der Sequenz kann die Weiterleitung des Mehrzielverkehrs eingeschränkt bleiben. Nach der Blockierung der Überflutung des Mehrzielverkehrs kann das Gerät die Umleitung des Verkehrs über die ISL einleiten, ohne Schleifen zu verursachen. Daher kann das Gerät das Peer-Gerät benachrichtigen, die Egress-Blockierung für den MCLAG zu deaktivieren. Dabei kann der MCLAG in diesem Zustand bleiben, bis das Gerät eine Bestätigung vom Peer-Gerät erhält. Mit anderen Worten: Bis zum Erhalt der Quittung kann der Zustand gesperrt bleiben.
Das Peer-Gerät kann dann seine lokalen Schnittstellen des MCLAG so konfigurieren, dass von der ISL empfangener Verkehr an den MCLAG weitergeleitet werden kann. Das Peer-Gerät kann das Gerät über die Konfiguration informieren. Daraufhin kann das Gerät die mit der ISL verbundene Schnittstelle so konfigurieren, dass der Verkehr an das Peer-Gerät umgeleitet wird. Dementsprechend kann der Verkehr zum MCLAG über die ISL umgeleitet werden. Wenn die Umleitung abgeschlossen ist, kann das Gerät ein Verbindungsaggregationsprotokoll wie das Link Aggregation Control Protocol (LACP) verwenden, um andere Geräte des Netzes zu benachrichtigen, den Verkehr für die mit dem Gerät verbundenen MCLAG-Verbindungen zurückzuziehen. Somit können die teilnehmenden Geräte eine anfällige Verkehrsumleitung herstellerunabhängig anwenden.
In dieser Offenlegung wird der Begriff „Switch“ in einem allgemeinen Sinne verwendet und kann sich auf jeden eigenständigen oder Fabric-Switch beziehen, der in einer beliebigen Netzwerkschicht arbeitet. Der Begriff „Switch“ ist nicht als Beschränkung der Beispiele der vorliegenden Erfindung auf Netze der Schicht 2 zu verstehen. Jedes Gerät, das Datenverkehr an ein externes Gerät oder einen anderen Switch weiterleiten kann, kann als „Switch“ bezeichnet werden. Jedes physische oder virtuelle Gerät (z. B. eine virtuelle Maschine oder ein Switch, der auf einem Computer arbeitet), das Datenverkehr an ein Endgerät weiterleiten kann, kann als „Switch“ bezeichnet werden. Beispiele für einen „Switch“ sind u. a. ein Layer-2-Switch, ein Layer-3-Router, ein Routing-Switch, eine Komponente eines Gen-Z- oder Compute Express Link (CXL)-Netzwerks, ein Prozessorgerät oder ein Fabric-Switch, der eine Vielzahl ähnlicher oder heterogener kleinerer physischer und/oder virtueller Switches umfasst.
Ein Ausdruck, der ein Gerät bezeichnet, wie „Knoten“, „Maschine“, „Einheit“ oder „Gerät“, kann einen Switch und einen End-Host, wie ein Benutzergerät, bezeichnen. Der Begriff „Nachricht“ bezieht sich auf eine Gruppe von Bits, die gemeinsam über ein Netz transportiert werden können. Der Begriff „Nachricht“ ist nicht so zu verstehen, dass die Beispiele der vorliegenden Beispiele auf eine bestimmte Schicht eines Netzes beschränkt sind. Der Begriff „Nachricht“ kann durch andere Begriffe ersetzt werden, die sich auf eine Gruppe von Bits beziehen, wie z. B. „Information“, „Daten“, „Anfrage“, „Antwort“, „Paket“, „Rahmen“, „Zelle“, „Datagramm“ oder „Transaktion“. “Außerdem kann sich der Begriff „Port“ auf den Port beziehen, der Daten empfangen, speichern oder senden kann. Der Begriff „Anschluss“ kann sich auch auf die Hardware-, Software- und/oder Firmware-Logik beziehen, die den Betrieb dieses Anschlusses erleichtern kann.
1A zeigt ein Beispiel für ein Netzwerk, das eine effiziente Verkehrsumleitung für MCLAGs für kontrollierte Nichtverfügbarkeitsereignisse unterstützt, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Ein Netzwerk 100 kann eine Vielzahl von Geräten, wie z. B. Switches und Endgeräte, umfassen. Das Netzwerk 100 kann die Switches 101, 102, 103, 104 und 105 umfassen. In einigen Beispielen kann das Netzwerk 100 ein Ethernet-, InfiniBand-, PCIe-, Gen-Z-, CXL- oder ein anderes Netzwerk sein und ein entsprechendes Kommunikationsprotokoll verwenden, wie z. B. Internet Protocol (IP), FibreChannel over Ethernet (FCoE) oder ein anderes Protokoll.
Eine oder mehrere Verbindungen im Netzwerk 100 können Tunnel sein. Beispiele für einen Tunnel sind unter anderem VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), Internet Protocol Security (IPsec). Ein VPN, wie z. B. ein EVPN, kann über das Netzwerk 100 bereitgestellt werden. Das Netzwerk 100 kann einen virtuellen Gateway-Switch (VGS) 106 enthalten, der das Netzwerk 100 mit externen Netzwerken und Geräten verbinden kann. Hier können die Switches 101 und 102 als ein einziger Switch in Verbindung miteinander arbeiten, um VGS 106 zu ermöglichen. VGS 106 kann mit einer oder mehreren virtuellen Adressen (z. B. einer virtuellen IP-Adresse und/oder einer virtuellen MAC-Adresse) verbunden sein.
Eine entsprechende Verbindung oder ein Tunnel, der an VGS 106 gebildet wird, kann die virtuelle Adresse verwenden, um den Verbindungs- oder Tunnelendpunkt zu bilden. Infolgedessen können die Switches 103, 104 und 105 des Netzwerks 100 VGS 106 als den anderen Verbindungs- oder Tunnelendpunkt für einen Tunnel anstelle der Switches 101 und 102 betrachten. Um den Verkehr in Richtung VGS 106 weiterzuleiten, kann ein Switch im Netzwerk 100, wie z. B. Switch 105, einen Lastausgleichsvorgang durchführen und einen der Switches 101 und 102 als Ziel auswählen. VGS 106 kann mit den Geräten 112 und 114 über MCLAGs 122 bzw. 124 gekoppelt werden.
Die Geräte 112 und 114 können mit entsprechenden Gruppen von Endgeräten 116 bzw. 118 verbunden werden. Beispiele für ein solches Gerät sind unter anderem ein Desktop- oder Laptop-Computer, ein Server-Computer, ein Gerät, ein Gerät zur Erbringung von Diensten (z. B. ein Mobilfunkmast oder ein Zugangspunkt), eine virtuelle Maschine (VM), eine Anwendung, ein Container, ein zellulares Gerät, ein Tablet, ein tragbares Gerät, eine stationäre oder tragbare Spielkonsole, ein Projektionsgerät, ein Netzwerkgerät (z. B. ein Switch), ein ansteckbarer Dongle, ein Gerät der erweiterten oder virtuellen Realität und ein Fahrzeuggerät.
Die Verknüpfung der Kopplungsvorrichtung 112 mit den Schaltern 101 und 102 kann MCLAG 122 bilden. Daher können die Schalter 101 und 102 als die beteiligten Schalter für MCLAG 122 bezeichnet werden. In ähnlicher Weise können die Schalter 101 und 102 als die teilnehmenden Schalter für MCLAG 124 bezeichnet werden. Dementsprechend können die Schalter 101 und 102 teilnehmende Schalter für die MCLAGs 122 und 124 sein. Die Vermittlungsstellen 101 und 102 können eine ISL 107 zwischen sich unterhalten, um Multicast-Steuer- und/oder Datenpakete auszutauschen. Schalter 101 und 102 können über die I SL 107 Steuernachrichten zur Synchronisierung der Zustände der MCLAGs 122 und 124 austauschen.
Während des Betriebs kann an einem der beteiligten Schalter, z. B. dem Schalter 101, eine Änderung auftreten. Die Änderung kann aufgrund eines kontrollierten oder unkontrollierten Ereignisses erfolgen. Beispielsweise kann der Benutzer ein kontrolliertes Ereignis (z. B. einen Neustart, eine Firmware-Aktualisierung oder ein Umschalten der Verbindung) für Schalter 101 auslösen. Andererseits kann der Schalter 101 auch von einem unkontrollierten Ereignis (z. B. einem Ausfall, Unfall oder einer Katastrophe) betroffen sein. Unabhängig von der Art des Ereignisses kann sich dieses auf die Vermittlungsstelle 101 auswirken und den Fluss des Datenverkehrs über die MCLAGs 122 und 124 beeinträchtigen. Bei bestehenden Technologien kann der Switch 101 eine oder mehrere Konfigurationen als Reaktion auf das Ereignis anwenden, unabhängig von dessen Typ. Doch selbst wenn das Ereignis kontrolliert (oder vorherbestimmt) ist, kann der Switch 101 die Konfigurationen anwenden, um den Verkehr zum Switch 102 umzuleiten, ohne die Auswirkungen der Anwendung der Konfigurationen zu berücksichtigen.
Folglich kann der Switch 101 ohne koordinierte Anwendung der Konfigurationen am Switch 101, selbst mit graceful-Prozeduren auf Protokollebene, für die Weiterleitung des Datenverkehrs für einen entsprechenden MCLAG über einen längeren Zeitraum nicht verfügbar sein und eine Unterbrechung des Datenverkehrs verursachen. Das Problem kann noch verschärft werden, weil die Anwendung der Konfigurationen von verschiedenen Daemons einer Verwaltungsanwendung (z. B. einem Betriebssystem) des Switches 101 verwaltet werden kann. Insbesondere können verschiedene Daemons, wie ein Protokoll-Daemon 134 und ein Programmier-Daemon 138, die mit der Konfiguration verbundenen Operationen zu unterschiedlichen Zeiten durchführen.
Der Protokoll-Daemon 134 kann für die Verwaltung des mit den MCLAGs 122 und 124 verbundenen Protokolls, wie z. B. LACP, verantwortlich sein und eine Konfiguration auf der Grundlage des aktuellen Status eines MCLAG, wie z. B. MCLAG 122, verarbeiten. Der Protokolldämon 134 kann dann den Programmierdämon 138 benachrichtigen, um die Hardware 130 des Schalters 101 entsprechend zu konfigurieren. Der Protokoll-Daemon 134 kann jedoch nicht warten, bis die Konfiguration der Hardware 130 abgeschlossen ist. In Szenarien mit hoher Auslastung kann es vorkommen, dass die Hardware 130 die Konfigurationsanforderungen des Programmier-Daemons 138 nicht mit der gleichen Geschwindigkeit wie die des Protokoll-Daemons 134 erfüllt. Daher kann der Protokoll-Daemon 134, während die Hardware 130 programmiert wird, zusätzliche Konfigurationen verarbeiten und den Programmier-Daemon 138 für weitere Konfigurationen anfordern.
Das ungleichmäßige Tempo der Konfiguration der Protokolldomäne 134 und der Hardware 130 kann zu einer Warteschlange von Anfragen führen und die Dämonen und die Hardware 130 in unsynchronisierte Zustände versetzen, die mit unterschiedlichen Konfigurationen verbunden sind. Da einige der Konfigurationen nicht nebeneinander bestehen können (z. B. die Umleitung des Verkehrs über 107 und die Blockierung des Ausgangs über MCLAG 122), kann MCLAG 122 aufgrund der unsynchronisierten Zustände weitere Verkehrsverluste erleiden. Darüber hinaus kann die Leistung der Dämonen 134 und 138 je nach der Belastung des Switches 101 variieren. Wenn die MCLAGs 122 und 124 unterschiedlich ausgelastet sind, kann sich die Zustandsänderung von MCLAG 122 auf die Hardwareprogrammierung für einen anderen MCLAG 124 auswirken. Wenn beispielsweise die MCLAGs 122 und 124 in Betrieb genommen werden, kann die Hardwarefreigabe für MCLAG 124 während der Hardwareprogrammierung von MCLAG 122 warten, je nachdem, in welcher Reihenfolge die Hardware 130 die Konfigurationsanforderungen vom Programmierdämon 138 erhält.
Darüber hinaus können die Zustandsänderungen für MCLAG 122 anzeigen, ob MCLAG 122 betriebsbereit oder nicht verfügbar geworden ist. Andere Geräte im Netz 100, z. B. Switch 105, können sich auf der Grundlage der Zustandsänderung bei MCLAG 122 anmelden bzw. abmelden. Wenn der Switch 105 den MCLAG 122 abonnieren kann, kann der Switch 105 mehrere Pfade zu den teilnehmenden Switches 101 und 102 aufrechterhalten (z. B. mehrere Pfade mit gleichen Kosten (ECMP)). Auf der Grundlage einer Lastausgleichsrichtlinie kann der Switch 105 den Verkehr über beide Switches 101 und 102 an MCLAG 122 (z. B. an Gerät 112) senden. Es kann jedoch sein, dass beide Switches 101 und 102 zu diesem Zeitpunkt nicht bereit sind, Datenverkehr für MCLAG 122 anzunehmen. Die unsynchronisierten Zustände zwischen den Switches 101 und 102 können zu weiteren Verkehrsverlusten im Netz 100 führen.
Um dieses Problem zu lösen, kann der Switch 101 bei einer kontrollierten (oder vorbestimmten) Nichtverfügbarkeit des Switches 101 die Konfigurationen in einer orchestrierten Step-Locking-Sequenz 150 anwenden, die den Daemons des Switches 101 eine Ausführungsreihenfolge vorschreibt, die eine geordnete Umleitung des Datenverkehrs zum Switch 102 gewährleistet. Um die Sequenz 150 der Konfigurationen anzuwenden, kann der Switch 101 einen MCLAG-Daemon 132 ausführen. Der MCLAG-Daemon 132 kann durch den Protokoll-Daemon 134 und einen VGS-Daemon 136 unterstützt werden. Der VGS-Daemon 136 kann die Vorgänge zur Konfiguration und Wartung von VGS 106 bereitstellen. MCLAG-Daemon 132 kann VGS-Daemon 136 nutzen, um Operationen mit Switch 102 zu synchronisieren. Insbesondere, wenn eine Konfiguration der Sequenz 150 eine Anwendung am Schalter 101 erfordert, kann der VGS-Daemon 136 die Synchronisierung der Anwendung der Konfiguration am Schalter 102 erleichtern.
Die orchestrierte Sequenz 150 kann die nachteiligen Auswirkungen des Übergangs des Datenverkehrs von Switch 101 zu Switch 102, wie z. B. Verkehrsverluste aufgrund von Nichtverfügbarkeit, verringern. In der Sequenz 150 können die Zustandsübergänge des MCLAG-Daemons 132 so geordnet werden, dass die Verbindungen des MCLAG 122 während und nach dem Übergang zur Annahme und Weiterleitung von Verkehr bereit sind. Die schrittweise Verriegelung der Sequenz 150 kann es ermöglichen, dass die Switches 101 und 102 in verschiedenen Übergangszuständen arbeiten und den Verkehr weiterleiten. Bei einem entsprechenden Schritt wird ein neuer Weg für den Verkehrsfluss geöffnet, damit dieser über MCLAG 122 fortgesetzt werden kann, bevor der Übergang von einem anderen erfolgt (z. B. Abschaltung), wodurch ein „Make-before-break-Modell“ der Verkehrsumleitung für MCLAG 122 erleichtert wird. Der MCLAG-Daemon 132 kann die gleiche orchestrierte Sequenz 150 von Konfigurationen auf MCLAG 124 für die kontrollierte Nichtverfügbarkeit anwenden.
Wenn der MCLAG-Daemon 132 den Programmier-Daemon 138 auffordert, eine Konfiguration auf die Hardware 130 anzuwenden, kann der MCLAG-Daemon 132 auf eine Bestätigung von der Hardware 130 über den Programmier-Daemon 138 warten, bevor er mit der nächsten Konfiguration der Sequenz 150 fortfährt. Folglich können der MCLAG-Daemon 132 und die Hardware 130 im gleichen Zustand arbeiten. Darüber hinaus kann die Umleitung des Datenverkehrs auch Konfigurationsaktualisierungen am Schalter 102 erfordern. Dementsprechend kann der MCLAG-Daemon 132 die Anwendung der Konfiguration vom Switch 102 anfordern. Wenn die Hardware von Switch 102 konfiguriert ist, kann MCLAG-Daemon 132 eine Bestätigung von Switch 102 erhalten. MCLAG-Daemon 132 kann dann mit der nachfolgenden Konfiguration der Sequenz 150 fortfahren. Auf diese Weise kann der MCLAG-Daemon 132 nach der Feststellung der Einleitung der kontrollierten Nichtverfügbarkeit von Schalter 101 eine effiziente Verkehrsumleitung von Schalter 101 zu Schalter 102 für die MCLAGs 122 und 124 ermöglichen.
1 B zeigt ein Beispiel für eine Reihe von Konfigurationen, die eine effiziente Verkehrsumleitung für MCLAGs bei kontrollierten Nichtverfügbarkeitsereignissen in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung ermöglichen. Der Switch 101 kann eine oder mehrere Konfigurationen anwenden, um den Verkehrsfluss für MCLAG 122 (und MCLAG 124) zu verwalten. Beispielsweise kann der Switch 101 eine Konfiguration anwenden, um ISL-Verkehr (d. h. über den ISL empfangenen Verkehr) einzurichten, der über MCLAG 122 blockiert wird (Konfiguration 152). Wenn andererseits der MCLAG 122 am Schalter 101 aufgrund eines Ereignisses 120 nicht verfügbar ist, kann der Schalter 101 eine Konfiguration anwenden, um den für den MCLAG 122 bestimmten Verkehr über die ISL 107 zum Schalter 102 umzuleiten (Konfiguration 154). Der Switch 102 kann jedoch auch die Konfiguration 152 anwenden, um die Weiterleitung von ISL-Verkehr an MCLAG 122 zu blockieren. Darüber hinaus kann Switch 101 eine Konfiguration anwenden, die das Fluten von Multidestinationsverkehr, wie z. B. BUM-Verkehr, blockieren kann, wenn MCLAG 122 aufgrund des Ereignisses 120 nicht verfügbar ist (Konfiguration 156). Wenn andererseits MCLAG 122 am Switch 101 verfügbar wird, kann der Switch 101 eine Konfiguration anwenden, um die Blockierung des ISL-Verkehrs über MCLAG 122 wiederherzustellen (Konfiguration 158).
Angenommen, das Ereignis 120 ist ein kontrolliertes Nichtverfügbarkeitsereignis bei Schalter 101. Da das Auftreten eines solchen Ereignisses vom Benutzer gesteuert werden kann, muss der Schalter 101 den Verkehr nicht an den Schalter 102 umleiten. Stattdessen kann der MCLAG-Daemon 132 den Datenverkehr schrittweise umleiten, indem er die Sequenz 150 befolgt. Dabei kann der MCLAG-Daemon 132 die Sequenz 150 von Konfigurationen seriell oder parallel auf die MCLAGs 122 und 124 anwenden. Vor dem Ereignis der kontrollierten Nichtverfügbarkeit von Switch 101 sollte der Verkehr zu MCLAG 122 (und MCLAG 124) über ISL 107 zu Switch 102 umgeleitet werden. Die Aktivierung der Verkehrsumleitung würde jedoch die Deaktivierung des Egress-Blocks am Switch 102 erfordern. Wird die Weiterleitung von ISL-Verkehr über MCLAG 122 zugelassen, kann dies zu einer Schleife im Netz 100 führen.
Um eine über MCLAG 122 erzeugte Schleife zu vermeiden, umfasst die anfängliche (oder erste) Konfiguration von Sequenz 150 daher die Aktivierung von Flood-Blocking für MCLAG 122 (Konfiguration 156). Das Flood-Blocking verhindert das Fluten des Mehrzielverkehrs im Netz 100. Folglich kann während der Anwendung von Sequenz 150 die Verkehrsweiterleitung auf Unicast-Verkehr beschränkt sein. Mit anderen Worten, während der Anwendung der nachfolgenden Konfigurationen der Sequenz 150 kann die Weiterleitung von Multidestinationsverkehr eingeschränkt bleiben. Nach dem Blockieren der Überflutung von Multidestinationsverkehr kann der Switch 101 eine Verkehrsumleitung über ISL 107 einleiten, ohne Schleifen zu verursachen. Daher kann der MCLAG-Daemon 132 den entsprechenden MCLAG-Daemon 142 des Schalters 102 benachrichtigen, die Egress-Blockierung für MCLAG 122 zu deaktivieren (Konfiguration 152). In diesem Fall kann MCLAG 122 in diesem Zustand verbleiben, bis Schalter 101 eine Bestätigung von Schalter 102 erhält. Mit anderen Worten: Bis zum Erhalt der Quittung kann der Zustand von MCLAG 122 gesperrt bleiben. Der VGS-Daemon 146 des MCLAG-Daemons 142 kann die Anfrage empfangen.
Der Protokoll-Daemon 144 kann dann eine entsprechende Anfrage an den Programmier-Daemon 148 stellen, um die Hardware 140 des Schalters 102 zu konfigurieren. Der MCLAG-Daemon 142 kann dann die lokalen Schnittstellen von MCLAG 122 so konfigurieren, dass die Egress-Blockierung des von Switch 101 empfangenen ISL-Verkehrs deaktiviert wird. Dadurch kann der von ISL 107 empfangene Verkehr an MCLAG 122 weitergeleitet werden. Wenn die Hardware 140 konfiguriert ist (Konfiguration 152), kann der Programmierdämon 148 eine Bestätigung von der Hardware 140 erhalten. Der VGS-Daemon 146 kann dann die entsprechende Bestätigung an den VGS-Daemon 136 senden. Auf der Grundlage der Bestätigung kann der MCLAG-Daemon 132 mit der nachfolgenden Konfiguration der Sequenz 150 fortfahren. MCLAG-Daemon 132 kann die mit ISL 107 verbundene Schnittstelle so konfigurieren, dass der Verkehr zum Switch 102 umgeleitet wird (Konfiguration 154).
Wenn die Umleitung abgeschlossen ist, kann der Protokoll-Daemon 134 andere Geräte des Netzes 100 benachrichtigen, den Verkehr für MCLAG-122-Verbindungen, die dem Switch 101 zugeordnet sind, zurückzuziehen. Beispielsweise kann der Protokoll-Daemon 134 das Synchronisierungsbit in einer LACP-Benachrichtigungsnachricht auf „false“ setzen und an die Switches 103, 104 und 105 senden. Nach Erhalt der Benachrichtigungsnachricht können die Switches 103, 104 und 105 davon ausgehen, dass der Switch 101 nicht mehr synchronisiert ist. Dementsprechend können die Switches 103, 104 und 105 die Verbindungen von Switch 101 in MCLAG 122 aus dem Lastausgleichsbetrieb herausnehmen und den Verkehr an die Verbindungen von Switch 102 in MCLAG 122 weiterleiten. Zu diesem Zeitpunkt wird sowohl der eingehende als auch der ausgehende Verkehr zu Schalter 101 gestoppt. Da der Verkehr zu Switch 102 umgeleitet wird, kann das Ereignis der kontrollierten Nichtverfügbarkeit für Switch 101 ohne nennenswerte Auswirkungen auf den Verkehr durch den VGS-Dämon 136 eingeleitet werden.
2A zeigt ein Beispiel für sequenzielle Konfigurationen, die den Verkehr für eine MCLAG bei kontrollierter Nichtverfügbarkeit eines teilnehmenden Geräts der MCLAG gemäß einem Aspekt der vorliegenden Anwendung effizient umleiten. Während des Betriebs kann der MCLAG-Daemon 132 des Schalters 101 die Einleitung eines Ereignisses der kontrollierten Nichtverfügbarkeit feststellen (Vorgang 210). Der MCLAG-Daemon 132 kann eine Benachrichtigung (z. B. einen Interprozessaufruf oder IPC) von der Verwaltungsanwendung empfangen und die Auslösung des kontrollierten Ereignisses bestimmen. Der MCLAG-Daemon 132 kann dann die Sequenz 150 von Konfigurationen für einen entsprechenden, dem Schalter 101 zugeordneten MCLAG einleiten. Die Verwaltungsanwendung kann auf den Abschluss der Sequenz 150 warten, um das Ereignis der kontrollierten Nichtverfügbarkeit auszuführen (z. B. Neustart des Schalters 101).
Dementsprechend kann der MCLAG-Daemon 132 das Flood-Blocking für Multidestinationsverkehr für den MCLAG aktivieren (Vorgang 212). Der MCLAG-Daemon 132 kann eine Anforderung an den Programmier-Daemon 138 senden, um die Konfiguration in der Hardware 130 des Schalters 101 zu programmieren. Der MCLAG-Daemon 132 kann dann auf eine Bestätigung von der Hardware 130 warten, wodurch sichergestellt wird, dass der MCLAG-Daemon 132 und die Hardware 130 mit demselben Zustand des MCLAG arbeiten. Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der Programmierdämon 138 eine Bestätigung übermitteln, die anzeigt, dass die Flutblockierung aktiviert ist (Vorgang 214).
Der MCLAG-Daemon 132 kann dann eine Anforderung zur Deaktivierung der Egress-Blockierung für ISL-Verkehr auf dem Peer-Gerät, d. h. Switch 102, ausgeben (Vorgang 216). Eine solche Konfiguration kann als externe Konfiguration für Schalter 101 bezeichnet werden. Der MCLAG-Dämon 142 von Schalter 102 kann die Anforderung empfangen und die Egress-Blockierung in der Hardware 140 von Schalter 102 deaktivieren (Vorgang 218). Durch die Deaktivierung der Egress-Blockierung kann der Switch 102 die Weiterleitung des vom Switch 101 empfangenen ISL-Verkehrs über den MCLAG erlauben. Der MCLAG-Dämon 142 kann dann eine Bestätigung an den MCLAG-Dämon 132 weiterleiten, die anzeigt, dass die Hardware 140 des Schalters 102 die Egress-Blockierung deaktiviert hat (Vorgang 220). Der MCLAG-Daemon 132 kann in diesem Zustand verbleiben, bis der Switch 102 die Egress-Blockierung aufhebt.
Anschließend kann der MCLAG-Daemon 132 die ISL-Umleitung aktivieren, die den für den MCLAG bestimmten Verkehr über ISL 107 zum Switch 102 umleitet (Vorgang 222). Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der Programmierdämon 138 eine Bestätigung weiterleiten, die anzeigt, dass die ISL-Umleitung aktiviert ist (Vorgang 224). Der MCLAG-Dämon 132 kann dann die Kommunikation für den MCLAG deaktivieren (z. B. LACP deaktivieren) (Vorgang 226). Durch die Deaktivierung der Kommunikation kann sowohl der eingehende als auch der ausgehende Verkehr zum MCLAG gestoppt werden. Zu diesem Zweck kann der MCLAG-Dämon 132 eine Benachrichtigung (z. B. eine LACP-Nachricht) an andere Geräte des Netzes 100 senden, die den MCLAG abonnieren (Vorgang 228). Die Teilnehmergeräte kennen möglicherweise den MCLAG und können einen Lastausgleich zwischen den Switches 101 und 102 durchführen, um den Verkehr an den MCLAG weiterzuleiten.
Nach Erhalt der Benachrichtigung können die Teilnehmergeräte das Abonnement für die Verbindungen zurückziehen, die vom Switch 101 ausgehen und sich im MCLAG befinden. Der Entzug kann die Teilnehmergeräte veranlassen, diese Verbindungen aus dem Lastausgleichsprozess zu entfernen. Dementsprechend können die Teilnehmergeräte die Weiterleitung des Datenverkehrs an den Switch 101 einstellen. Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der MCLAG-Daemon 132 eine Bestätigung empfangen, die anzeigt, dass die Kommunikation für den MCLAG deaktiviert ist (Vorgang 230). Der MCLAG-Daemon 132 kann dann die Verwaltungsanwendung über den Abschluss der Sequenz 150 (z. B. unter Verwendung eines IPC) informieren (Vorgang 232).
2B zeigt ein Beispiel für sequenzielle Konfigurationen, die den Verkehr für eine MCLAG zur Wiederherstellung nach einem kontrollierten Ereignis eines teilnehmenden Geräts der MCLAG gemäß einem Aspekt der vorliegenden Anwendung effizient wiederherstellen. Während des Betriebs kann der MCLAG-Daemon 132 des Schalters 101 die Wiederherstellung nach einem kontrollierten Nichtverfügbarkeitsereignis bestimmen (Vorgang 250). MCLAG-Daemon 132 kann eine Benachrichtigung (z. B. einen IPC) von der Verwaltungsanwendung empfangen und die Wiederherstellung nach dem kontrollierten Ereignis bestimmen. Der MCLAG-Daemon 132 kann dann eine Sequenz 200 von Konfigurationen für einen entsprechenden MCLAG einleiten, der dem Schalter 101 zugeordnet ist. Die Sequenz 200 kann eine Sequenz von Konfigurationen umfassen, die den Verkehr zum MCLAG von Schalter 102 wiederherstellt. Dementsprechend kann der MCLAG-Dämon 132 die Kommunikation für den MCLAG aktivieren (Vorgang 252).
Durch die Freigabe der Kommunikation kann der Fluss des Eingangs- und Ausgangsverkehrs zum MCLAG wieder aufgenommen werden. Zu diesem Zweck kann der MCLAG-Dämon 132 eine Benachrichtigung (z. B. eine LACP-Nachricht) an andere Geräte des Netzes 100 senden, die den MCLAG abonnieren (Vorgang 254). Nach Erhalt der Benachrichtigung können die Teilnehmergeräte das Abonnement für die Verbindungen, die vom Switch 101 ausgehen und sich im MCLAG befinden, wiederherstellen. Die Wiederherstellung des Abonnements kann die Teilnehmergeräte veranlassen, diese Verbindungen wieder in den Lastausgleichsprozess einzubeziehen. Dementsprechend können die Teilnehmergeräte die Weiterleitung des Datenverkehrs an den Switch 101 wieder aufnehmen. Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der MCLAG-Daemon 132 eine Bestätigung empfangen, die anzeigt, dass die Kommunikation für den MCLAG aktiviert ist (Vorgang 256).
Der MCLAG-Dämon 132 kann dann die ISL-Umleitung deaktivieren, wodurch der für den MCLAG bestimmte Datenverkehr nicht über ISL 107 an den Switch 102 weitergeleitet wird (Vorgang 258). Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der Programmierdämon 138 eine Bestätigung weiterleiten, die anzeigt, dass die ISL-Umleitung deaktiviert ist (Vorgang 260). Der MCLAG-Daemon 132 kann dann eine Anforderung zur Aktivierung der Egress-Blockierung für ISL-Verkehr auf dem Peer-Gerät, d. h. Switch 102, ausgeben (Vorgang 262). Der MCLAG-Daemon 142 von Schalter 102 kann die Anforderung empfangen und die Egress-Blockierung in der Hardware 140 von Schalter 102 aktivieren (Vorgang 264). Durch die Aktivierung der Egress-Blockierung kann der Switch 102 die Weiterleitung des vom Switch 101 über den MCLAG empfangenen ISL-Verkehrs blockieren.
Der MCLAG-Daemon 142 kann dann eine Bestätigung an den MCLAG-Daemon 132 weiterleiten, die anzeigt, dass die Hardware 140 des Schalters 102 die Egress-Blockierung aktiviert hat (Vorgang 266). Anschließend kann der MCLAG-Daemon 132 das Flood-Blocking für Multidestinationsverkehr für den MCLAG deaktivieren (Vorgang 268). Die Deaktivierung des Flood-Blocking kann die Weiterleitung von Multidestinationsverkehr über den MCLAG ermöglichen. Wenn die Hardware 130 mit der Konfiguration programmiert ist, kann der Programmierdämon 138 eine Bestätigung weiterleiten, die anzeigt, dass die Flutblockierung deaktiviert ist (Vorgang 270). Wenn die Sequenz 200 abgeschlossen ist, kann der Verkehr zu den Verbindungen des Schalters 101 wiederhergestellt werden. Nach der Wiederherstellung des kontrollierten Ereignisses (z. B. wenn der Switch 101 neu gebootet wurde) kann der Datenverkehr also wieder ordnungsgemäß an den Switch 101 weitergeleitet werden, wodurch die negativen Auswirkungen des kontrollierten Ereignisses gemildert werden.
3 zeigt ein Beispiel für die Verkehrsweiterleitung für eine MCLAG während der sequenziellen Konfigurationen für die kontrollierte Nichtverfügbarkeit eines teilnehmenden Geräts der MCLAG gemäß einem Aspekt der vorliegenden Anwendung. Wenn der Switch 101 die Sequenz 150 von Konfigurationen anwendet, kann der Switch 101 Pakete in verschiedenen Schritten empfangen und einen entsprechenden Verkehrsweiterleitungsvorgang durchführen. Wenn z. B. Flood-Blocking für Multi-Destination-Verkehr am Switch 101 für MCLAG 122 aktiviert ist, kann der Switch 101 ein Multi-Destination-Paket 302 vom Switch 104 empfangen. Aufgrund der Flutblockierung kann der Schalter 101 davon absehen, das Paket 302 über MCLAG 122 weiterzuleiten, und kann das Paket 302 verwerfen (Vorgang 312).
Darüber hinaus kann der Switch 101 ein Unicast-Paket 304 empfangen, wenn der Switch 102 die Egress-Blockierung für ISL-Verkehr deaktiviert hat, der Switch 101 aber keine ISL-Umleitung aktiviert hat. Unter solchen Umständen kann der Switch 101 das Paket 304 verwerfen (Vorgang 316). Empfängt der Schalter 101 hingegen das Paket 304, wenn die ISL-Umleitung konfiguriert ist, kann der Schalter 101 das Paket 304 an den Schalter 102 weiterleiten. Da die Ausgangssperre bei Schalter 102 für MCLAG 122 deaktiviert ist, kann Schalter 102 das Paket 304 über seine lokale Verbindung 334 von MCLAG 122 weiterleiten (Vorgang 316). Daher kann die Umleitung des Verkehrs auf Unicast-Verkehr beschränkt werden.
Wenn die Kommunikation für MCLAG 122 bei Switch 101 deaktiviert wird (Vorgang 318), können andere Teilnehmergeräte, wie Switch 104, eine entsprechende Benachrichtigung erhalten und das Abonnement der Verbindung 332 von MCLAG 122 zurückziehen. Folglich kann die Vermittlungsstelle 104 beginnen, alle Pakete für MCLAG 122 an die Vermittlungsstelle 102 zu senden. Anschließend kann der Schalter 104 ein Paket 306 an den Schalter 102 senden. Da die ISL-Umleitung aktiv ist, kann das Paket 306 über ISL 107 an Schalter 102 weitergeleitet werden, auch wenn Schalter 104 das Paket 306 an Schalter 101 sendet. Nach dem Empfang des Pakets 306 kann Schalter 102 das Paket 304 über MCLAG 122 weiterleiten (Vorgang 320).
4A zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts einer MCLAG veranschaulicht, das sequenzielle Konfigurationen anwendet, die den Verkehr von dem Gerät effizient umleiten, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Die Operationen dieses Prozesses können von einem oder mehreren Daemons und der Weiterleitungshardware des Geräts durchgeführt werden. Während des Betriebs kann das Gerät die Auslösung eines kontrollierten Nichtverfügbarkeitsereignisses feststellen (Vorgang 402). Das Gerät kann dann die Flutblockierung für den weiterleitenden Multidestinationsverkehr über den MCLAG aktivieren (Vorgang 404). Das Gerät kann dann eine Kontrollnachricht an ein teilnehmendes Peer-Gerät senden, die es anweist, die Ausgangssperre für ISL-Verkehr zu deaktivieren (Vorgang 406).
Anschließend kann das Gerät eine Bestätigung von dem teilnehmenden Peer-Gerät erhalten, die anzeigt, dass die Egress-Blockierung deaktiviert ist (Vorgang 408). Das Gerät kann dann die ISL-Umleitung zum teilnehmenden Peer-Gerät aktivieren (Vorgang 410) und die lokale Kommunikation für den MCLAG deaktivieren (Vorgang 412). Das Gerät kann prüfen, ob alle MCLAGs für das Ereignis bereit sind (Vorgang 414). Wenn nicht alle MCLAGs bereit sind, kann das Gerät weiterhin Flood-Blocking für die Weiterleitung des Mehrzielverkehrs über einen anderen MCLAG aktivieren (Vorgang 404). Sind hingegen alle MCLAGs bereit, kann das Gerät das Ereignis der kontrollierten Nichtverfügbarkeit einleiten (Vorgang 416).
4B zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts eines MCLAG veranschaulicht, das lokal eine Konfiguration anwendet, die den Verkehr von einem entfernten teilnehmenden Gerät effizient umleitet, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Die Operationen dieses Prozesses können von einem oder mehreren Daemons und der Weiterleitungshardware des Geräts durchgeführt werden. Während des Betriebs kann das Gerät eine Steuernachricht von einem teilnehmenden Peer-Gerät mit der Anweisung empfangen, die Egress-Blockierung zu deaktivieren (Vorgang 432). Das Gerät kann daraufhin die Egress-Blockierung für den MCLAG für ISL-Verkehr deaktivieren (Vorgang 434). Anschließend kann das Gerät eine Bestätigung an das teilnehmende Peer-Gerät senden, die anzeigt, dass die Egress-Blockierung deaktiviert ist (Vorgang 436).
4C zeigt ein Flussdiagramm, das den Prozess eines Daemons eines teilnehmenden Geräts eines MCLAG veranschaulicht, der eine entsprechende Konfiguration zur effizienten Umleitung des Datenverkehrs von dem Gerät anwendet, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Während des Betriebs kann der Daemon eine Wartesperre für eine MCLAG-Verkehrsumleitungskonfiguration einleiten (Vorgang 452). Die Wartesperre kann ein bedingter Warteprozess sein, bis die Bedingung erfüllt ist. Der Daemon kann dann die MCLAG-Verkehrsweiterleitungskonfiguration auf die lokale Hardware anwenden (Vorgang 454) und auf die Bestätigung der Sperre warten, bevor er eine nachfolgende Konfiguration einleitet (Vorgang 456).
Der Daemon kann prüfen, ob eine Bestätigung von der Hardware empfangen wurde (Vorgang 458). Wird keine Bestätigung empfangen, kann der Daemon weiter auf die Sperre warten (Vorgang 460). Wird hingegen eine Bestätigung empfangen, kann der Dämon die Konfiguration der MCLAG-Verkehrsweiterleitung bestätigen (Vorgang 460). Der Dämon kann dann die Sperre aufheben, damit eine nachfolgende MCLAG-Verkehrsweiterleitungskonfiguration fortgesetzt werden kann (Vorgang 462). Der Daemon kann diesen Prozess anwenden, um eine entsprechende Konfiguration der Sequenz anzuwenden.
5A zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts eines MCLAG veranschaulicht, das sequentielle Konfigurationen anwendet, die den Verkehr zum Gerät effizient wiederherstellen, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Die Operationen dieses Prozesses können von einem oder mehreren Daemons und der Weiterleitungshardware des Geräts durchgeführt werden. Während des Betriebs kann das Gerät die Wiederherstellung nach einem kontrollierten Nichtverfügbarkeitsereignis feststellen (Vorgang 502). Das Gerät kann dann die lokale Kommunikation für den MCLAG aktivieren (Vorgang 504) und die ISL-Weiterleitung an das teilnehmende Peer-Gerät deaktivieren (Vorgang 506).
Das Gerät kann eine Kontrollnachricht an ein teilnehmendes Peer-Gerät senden, mit der Anweisung, die Ausgangssperre für ISL-Verkehr zu aktivieren (Vorgang 508). Anschließend kann das Gerät eine Bestätigung von dem teilnehmenden Peer-Gerät empfangen, die anzeigt, dass die Egress-Blockierung aktiviert ist (Vorgang 510). Das Gerät kann dann die Flood-Blockierung für den weiterleitenden Multidestinationsverkehr über den MCLAG deaktivieren (Vorgang 512). Das Gerät kann prüfen, ob der Verkehr für alle MCLAGs wiederhergestellt ist (Vorgang 514). Wenn der Verkehr nicht für alle MCLAGs wiederhergestellt ist, kann das Gerät die lokale Kommunikation für einen anderen MCLAG weiterhin aktivieren (Vorgang 504). Wird hingegen der Verkehr für alle MCLAGs wiederhergestellt, kann das Gerät feststellen, dass der Verkehr für die Wiederherstellung wiederhergestellt ist (Vorgang 516).
5B zeigt ein Flussdiagramm, das den Prozess eines teilnehmenden Geräts eines MCLAG veranschaulicht, das lokal eine Konfiguration anwendet, die den Verkehr zu einem entfernten teilnehmenden Gerät effizient wiederherstellt, gemäß einem Aspekt der vorliegenden Anwendung. Die Operationen dieses Prozesses können von einem oder mehreren Daemons und der Weiterleitungshardware des Geräts ausgeführt werden. Während des Betriebs kann das Gerät eine Steuernachricht von einem teilnehmenden Peer-Gerät mit der Anweisung empfangen, die Ausgangssperre zu aktivieren (Vorgang 532). Das Gerät kann dann die Ausgangssperre für den MCLAG für ISL-Verkehr aktivieren (Vorgang 534). Anschließend kann das Gerät eine Bestätigung an das teilnehmende Peer-Gerät senden, die anzeigt, dass die Egress-Blockierung aktiviert ist (Vorgang 536).
6 zeigt ein Beispiel für einen Switch, der eine effiziente Verkehrsumleitung für MCLAGs bei kontrollierten Nichtverfügbarkeitsereignissen in Übereinstimmung mit einer Ausführungsform der vorliegenden Anwendung unterstützt. In diesem Beispiel umfasst ein Switch 600 eine Reihe von Kommunikationsanschlüssen 602, einen Paketprozessor 610 und ein Speichergerät 650. Der Switch 600 kann auch Switch-Hardware 660 (z. B. Verarbeitungshardware des Switches 600, wie z. B. seine anwendungsspezifischen integrierten Schaltungschips (ASIC)) enthalten, die Informationen enthält, auf deren Grundlage der Switch 600 Pakete verarbeitet (z. B. Ausgangsports für Pakete bestimmt). Der Paketprozessor 610 extrahiert und verarbeitet Header-Informationen aus den empfangenen Paketen. Der Paketprozessor 610 kann eine Switch-Kennung (z. B. eine MAC-Adresse und/oder eine IP-Adresse) identifizieren, die dem Switch 600 im Header eines Pakets zugeordnet ist.
Die Kommunikationsanschlüsse 602 können Kommunikationskanäle zwischen den Switches zur Kommunikation mit anderen Switches und/oder Benutzergeräten umfassen. Die Kommunikationskanäle können über einen normalen Kommunikationsanschluss implementiert werden und auf einem beliebigen offenen oder proprietären Format basieren. Die Kommunikationsanschlüsse 602 können einen oder mehrere Ethernet-Anschlüsse umfassen, die in einem Ethernet-Header gekapselte Rahmen empfangen können. Die Kommunikationsanschlüsse 602 können auch einen oder mehrere IP-Anschlüsse umfassen, die in der Lage sind, IP-Pakete zu empfangen. Ein IP-Port kann ein IP-Paket empfangen und kann mit einer IP-Adresse konfiguriert werden. Der Paketprozessor 610 kann Ethernet-Rahmen und/oder IP-Pakete verarbeiten. Ein entsprechender Anschluss der Kommunikationsanschlüsse 602 kann als Eingangsanschluss und/oder als Ausgangsanschluss fungieren.
Der Schalter 600 kann eine Datenbank 652 verwalten (z. B. im Speichergerät 650). Die Datenbank 652 kann eine relationale Datenbank sein und kann auf einer oder mehreren DBMS-Instanzen laufen. In der Datenbank 652 können Informationen gespeichert werden, die mit einer Abfolge von Konfigurationen verbunden sind, die eine effiziente und schonende Umleitung des Datenverkehrs vom Switch 600 ermöglichen. Die Informationen können zum Beispiel Konfigurationsbefehle und Parameter enthalten, die mit einer entsprechenden Konfiguration und der Abfolge der Konfigurationen verbunden sind.
Der Schalter 600 kann einen VGS-Logikblock 642 und einen Programmierlogikblock 644 enthalten. Der VGS-Logikblock 642 kann es dem Schalter 600 ermöglichen, als VGS, wie z. B. VGS 106 von 1A, in einem Netzwerk zu arbeiten. Zu diesem Zweck kann der VGS-Logikblock 642 in Verbindung mit einem anderen Schalter arbeiten. Der Programmierlogikblock 644 kann eine Anforderung zur Programmierung einer Konfiguration empfangen und die Hardware 660 anweisen, die Konfiguration anzuwenden. Der Programmierlogikblock 644 kann auch eine Bestätigung liefern, wenn die Konfiguration an der Hardware 660 abgeschlossen ist. Der Schalter 600 kann auch einen Verwaltungslogikblock 670 enthalten, der die kontrollierte (oder vorbestimmte) Nichtverfügbarkeit des Schalters 600 verwalten kann. Beispielsweise kann der Verwaltungslogikblock 670 eine oder mehrere Operationen durchführen, die eine kontrollierte Nichtverfügbarkeit auslösen können.
Schalter 600 kann einen MCLAG-Logikblock 630 enthalten, der einen Sequenzlogikblock 632, einen Konfigurationslogikblock 634 und einen Wartelogikblock 636 enthalten kann. Der MCLAG-Logikblock 630 kann es dem Schalter 600 ermöglichen, als teilnehmendes Gerät (z. B. unter Verwendung eines oder mehrerer Anschlüsse der Kommunikationsanschlüsse 602) in einem oder mehreren MCLAGs zu arbeiten. Der Sequenzlogikblock 632 kann die Einleitung eines kontrollierten Nichtverfügbarkeitsereignisses für den Schalter 600 und die Wiederherstellung nach einem solchen Ereignis bestimmen. Der Sequenzlogikblock 632 kann auch entsprechende Sequenzen von Konfigurationen für die Auslösung und Wiederherstellung des kontrollierten Nichtverfügbarkeitsereignisses bestimmen.
Der Konfigurationslogikblock 634 kann eine entsprechende Konfiguration einer Sequenz für einen entsprechenden MCLAG anwenden. Zu diesem Zweck kann der Konfigurationslogikblock 634 den Programmierlogikblock 644 auffordern, die Konfiguration auf der Hardware 660 zu programmieren. Der Konfigurationslogikblock 634 kann auch ein gleichrangiges teilnehmendes Gerät der MCLAG anweisen, eine Konfiguration anzuwenden. Der Wartelogikblock 636 kann auf eine Bestätigung des Programmierlogikblocks 644 für eine entsprechende Konfiguration warten, wodurch sichergestellt wird, dass der Konfigurationslogikblock 634 mit einer nachfolgenden Konfiguration der Sequenz fortfahren kann, wenn die aktuelle Konfiguration abgeschlossen ist. In ähnlicher Weise kann der Wartelogikblock 636 auf eine Bestätigung von einem teilnehmenden Peer-Gerät warten, wenn die Konfiguration an das teilnehmende Peer-Gerät gerichtet ist.
Die in dieser ausführlichen Beschreibung beschriebenen Datenstrukturen und der Code werden in der Regel auf einem computerlesbaren Speichermedium gespeichert, bei dem es sich um ein beliebiges Gerät oder Medium handeln kann, das Code und/oder Daten zur Verwendung durch ein Computersystem speichern kann. Das computerlesbare Speichermedium umfasst unter anderem Flip/Flops, Latches, Register, flüchtige Speicher, nichtflüchtige Speicher, magnetische und optische Speichervorrichtungen wie Disketten, Magnetbänder, CDs (Compact Discs), DVDs (Digital Versatile Discs oder Digital Video Discs) oder andere Medien, die in der Lage sind, heute bekannte oder später entwickelte computerlesbare Medien zu speichern.
Die im Abschnitt „Detaillierte Beschreibung“ beschriebenen Methoden und Prozesse können als Code und/oder Daten verkörpert werden, die wie oben beschrieben in einem computerlesbaren Speichermedium gespeichert werden können. Wenn ein Computersystem den auf dem computerlesbaren Speichermedium gespeicherten Code und/oder die Daten liest und ausführt, führt das Computersystem die Methoden und Prozesse aus, die als Datenstrukturen und Code verkörpert und in dem computerlesbaren Speichermedium gespeichert sind.
Die hier beschriebenen Methoden und Prozesse können von Hardware-Modulen oder -Geräten ausgeführt werden und/oder in diesen enthalten sein. Zu diesen Modulen oder Geräten können unter anderem ein anwendungsspezifischer integrierter Schaltkreis (ASIC-Chip), ein feldprogrammierbares Gate-Array (FPGA), ein dedizierter oder gemeinsam genutzter Prozessor, der ein bestimmtes Softwaremodul oder ein Stück Code zu einem bestimmten Zeitpunkt ausführt, und/oder andere heute bekannte oder später entwickelte programmierbare logische Geräte gehören. Wenn die Hardware-Module oder -Geräte aktiviert werden, führen sie die in ihnen enthaltenen Methoden und Prozesse aus.
Die vorstehenden Beschreibungen von Beispielen der vorliegenden Erfindung wurden nur zur Veranschaulichung und Beschreibung vorgelegt. Sie erheben keinen Anspruch auf Vollständigkeit und schränken diese Offenbarung nicht ein. Dementsprechend werden viele Modifikationen und Variationen für den Fachmann auf dem Gebiet der Technik offensichtlich sein. Der Umfang der vorliegenden Erfindung wird durch die beigefügten Ansprüche definiert.

Claims

Ein Verfahren, das Folgendes umfasst: Teilnahme an einer Multi-Chassis Link Aggregation Group (MCLAG) unter Verwendung einer ersten Schnittstelle eines ersten Switches eines Netzwerks, wobei die MCLAG die erste Schnittstelle des ersten Switches und eine zweite Schnittstelle eines zweiten Switches umfasst; basierend auf einer vorbestimmten Nichtverfügbarkeit für den ersten Switch, Bestimmen einer Sequenz von Anwendungen für eine Vielzahl von Verkehrsweiterleitungskonfigurationen, wobei eine jeweilige Verkehrsweiterleitungskonfiguration eine Schleifenverhinderung für über den MCLAG weitergeleiteten Verkehr erleichtert; Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch, basierend auf der Sequenz von Anwendungen, um Unicast-Verkehr vom ersten Switch zum zweiten Switch umzuleiten, wobei das Anwenden einer jeweiligen Verkehrsweiterleitungskonfiguration das Programmieren entsprechender Switch-Hardware mit der Verkehrsweiterleitungskonfiguration umfasst; und Durchführung einer Reihe von Operationen auf dem ersten Schalter, die die vorbestimmte Nichtverfügbarkeit auslöst.
Das Verfahren nach Anspruch 1, das als Reaktion auf eine Wiederherstellung der vorbestimmten Nichtverfügbarkeit weiterhin umfasst: Bestimmen einer zweiten Sequenz von Anwendungen für die Vielzahl von Verkehrsweiterleitungskonfigurationen; und Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch auf der Grundlage der zweiten Sequenz von Anwendungen, um den Verkehr für den MCLAG wiederherzustellen.
Das Verfahren nach Anspruch 2, wobei die zweite Folge von Anwendungen eine Umkehrung der Folge von Anwendungen ist.
Das Verfahren nach Anspruch 1, wobei der MCLAG in einer Vielzahl von MCLAGs enthalten ist, die für den ersten und zweiten Schalter konfiguriert sind; wobei das Verfahren ferner das Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch für eine jeweilige MCLAG der Vielzahl von MCLAGs umfasst.
Das Verfahren nach Anspruch 4, ferner umfassend das Ausführen des Satzes von Operationen auf dem ersten Switch als Reaktion auf das Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf die Vielzahl von MCLAGs.
Das Verfahren nach Anspruch 1, wobei das Konfigurieren der entsprechenden Switch-Hardware mit der Verkehrsweiterleitungskonfiguration weiterhin umfasst: Empfangen einer Bestätigung, die anzeigt, dass die Verkehrsweiterleitungskonfiguration an der entsprechenden Switch-Hardware programmiert ist; und Fortfahren mit der Anwendung einer nachfolgenden Verkehrsweiterleitungskonfiguration in der Sequenz als Reaktion auf den Empfang der Quittierung.
Das Verfahren nach Anspruch 1, wobei die Sequenz von Anwendungen ferner eine Konfiguration für die Weiterleitung von externem Verkehr enthält, die auf den zweiten Switch anwendbar ist, und wobei das Verfahren ferner umfasst: Aufforderung an den zweiten Switch, die externe Verkehrsweiterleitungskonfiguration anzuwenden; und Empfangen einer Bestätigung, die anzeigt, dass die Konfiguration für die Weiterleitung des externen Verkehrs in der Switch-Hardware des zweiten Switches programmiert ist.
Das Verfahren nach Anspruch 1, wobei die Reihenfolge der Anwendungen auf den gegenseitigen Abhängigkeiten der mehreren Konfigurationen für die Verkehrsweiterleitung basiert, so dass die Verkehrsumleitung vor der Deaktivierung einer lokalen Instanz des MCLAG aktiviert wird.
Das Verfahren nach Anspruch 1, wobei die Vielzahl von Verkehrsweiterleitungskonfigurationen umfasst: die Blockierung der Überflutung des Mehrzielverkehrs über den MCLAG; Umleitung des für den MCLAG bestimmten Datenverkehrs an den zweiten Switch; und Deaktivierung der lokalen Kommunikation für den MCLAG; und wobei die Anwendungssequenz ferner eine Konfiguration für die Weiterleitung des externen Verkehrs enthält, die die Weiterleitung des umgeleiteten Verkehrs über den MCLAG ermöglicht.
Das Verfahren nach Anspruch 1, das ferner das Senden einer Benachrichtigungsnachricht an einen dritten Switch des Netzes umfasst, wobei die Benachrichtigungsnachricht die Nichtverfügbarkeit einer Verbindung des ersten Switches im MCLAG anzeigt, wodurch der dritte Switch sich von der Verbindung zurückziehen kann.
Ein nicht-transitorisches computerlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem Computersystem ausgeführt werden, das Computersystem veranlassen, ein Verfahren durchzuführen, wobei das Verfahren umfasst: Teilnahme an einer Multi-Chassis Link Aggregation Group (MCLAG) unter Verwendung einer ersten Schnittstelle eines ersten Switches eines Netzwerks, wobei die MCLAG die erste Schnittstelle des ersten Switches und eine zweite Schnittstelle eines zweiten Switches umfasst; basierend auf einer vorbestimmten Nichtverfügbarkeit für den ersten Switch, Bestimmen einer Sequenz von Anwendungen für eine Vielzahl von Verkehrsweiterleitungskonfigurationen, wobei eine jeweilige Verkehrsweiterleitungskonfiguration eine Schleifenverhinderung für über den MCLAG weitergeleiteten Verkehr ermöglicht; Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch, basierend auf der Sequenz von Anwendungen, um Unicast-Verkehr vom ersten Switch zum zweiten Switch umzuleiten, wobei das Anwenden einer jeweiligen Verkehrsweiterleitungskonfiguration das Programmieren entsprechender Switch-Hardware mit der Verkehrsweiterleitungskonfiguration umfasst; und Durchführung eines Satzes von Operationen am ersten Schalter, der die vorbestimmte Nichtverfügbarkeit auslöst.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei das Verfahren als Reaktion auf eine Wiederherstellung der vorbestimmten Nichtverfügbarkeit weiterhin umfasst: Bestimmen einer zweiten Sequenz von Anwendungen für die Vielzahl von Verkehrsweiterleitungskonfigurationen; und Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch auf der Grundlage der zweiten Sequenz von Anwendungen, um den Verkehr für den MCLAG wiederherzustellen.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei der MCLAG in einer Vielzahl von MCLAGs enthalten ist, die für den ersten und zweiten Schalter konfiguriert sind; wobei das Verfahren ferner das Anwenden der Vielzahl von Verkehrsweiterleitungskonfigurationen auf den ersten Switch für eine jeweilige MCLAG der Vielzahl von MCLAGs umfasst.
Das nichttransitorische computerlesbare Speichermedium nach Anspruch 13, wobei das Verfahren ferner die Durchführung des Satzes von Operationen auf dem ersten Switch als Reaktion auf die Anwendung der Vielzahl von Verkehrsweiterleitungskonfigurationen auf die Vielzahl von MCLAGs umfasst.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei das Konfigurieren der entsprechenden Switch-Hardware mit der Verkehrsweiterleitungskonfiguration weiterhin umfasst: Empfangen einer Bestätigung, die anzeigt, dass die Verkehrsweiterleitungskonfiguration an der entsprechenden Switch-Hardware programmiert ist; und Fortfahren mit der Anwendung einer nachfolgenden Verkehrsweiterleitungskonfiguration in der Sequenz als Reaktion auf den Empfang der Quittierung.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei die Sequenz von Anwendungen ferner eine externe Verkehrsweiterleitungskonfiguration enthält, die auf den zweiten Switch anwendbar ist, und wobei das Verfahren ferner umfasst: Aufforderung an den zweiten Switch, die externe Verkehrsweiterleitungskonfiguration anzuwenden; und Empfangen einer Bestätigung, die anzeigt, dass die Konfiguration für die Weiterleitung des externen Verkehrs in der Switch-Hardware des zweiten Switches programmiert ist.
Das Nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei die Abfolge der Anwendungen auf den Abhängigkeiten der Vielzahl von Verkehrsweiterleitungskonfigurationen basiert, so dass die Verkehrsumleitung vor der Deaktivierung einer lokalen Instanz des MCLAG aktiviert wird.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei die Vielzahl der Verkehrsweiterleitungskonfigurationen umfasst: die Blockierung der Überflutung des Mehrzielverkehrs über den MCLAG; Umleitung des für den MCLAG bestimmten Datenverkehrs an den zweiten Switch; und Deaktivierung der lokalen Kommunikation für den MCLAG; und wobei die Anwendungssequenz ferner eine Konfiguration für die Weiterleitung des externen Verkehrs enthält, die die Weiterleitung des umgeleiteten Verkehrs über den MCLAG ermöglicht.
Das nicht-transitorische computerlesbare Speichermedium nach Anspruch 11, wobei das Verfahren ferner das Senden einer Benachrichtigungsnachricht an einen dritten Switch des Netzwerks umfasst, wobei die Benachrichtigungsnachricht die Nichtverfügbarkeit einer Verbindung des ersten Switches im MCLAG anzeigt, wodurch der dritte Switch sich von der Verbindung zurückziehen kann.
Ein Computersystem, das Folgendes umfasst: Verarbeitungsschaltungen; Weiterleitungshardware; eine Netzwerkschnittstellenkarte mit einer ersten Schnittstelle; einen MCLAG-Logikblock (Multi-Chassis Link Aggregation Group) zur Teilnahme an einer MCLAG (Multi-Chassis Link Aggregation Group) unter Verwendung der ersten Schnittstelle, wobei die MCLAG die erste Schnittstelle und eine zweite Schnittstelle eines zweiten Computersystems umfasst; einen Sequenzlogikblock, um auf der Grundlage einer vorbestimmten Nichtverfügbarkeit für das Computersystem eine Sequenz von Anwendungen für eine Vielzahl von Verkehrsweiterleitungskonfigurationen zu bestimmen, wobei eine jeweilige Verkehrsweiterleitungskonfiguration eine Schleifenverhinderung für über den MCLAG weitergeleiteten Verkehr erleichtert; einen Konfigurationslogikblock zum Anwenden der mehreren Verkehrsweiterleitungskonfigurationen auf das Computersystem auf der Grundlage der Sequenz von Anwendungen, um Unicast-Verkehr von dem ersten Switch zu dem zweiten Switch umzuleiten, wobei das Anwenden einer jeweiligen Verkehrsweiterleitungskonfiguration das Programmieren der Weiterleitungshardware mit der Verkehrsweiterleitungskonfiguration umfasst; und einen Verwaltungslogikblock zur Durchführung eines Satzes von Operationen auf dem ersten Schalter, der die vorbestimmte Nichtverfügbarkeit auslöst.