-
Technisches
Gebiet
-
Die
vorliegende Erfindung betrifft Routingsysteme und im Besonderen
Failover von Routingsystemen und ganz besonders Neusynchronisierung mit
Peer-Routingsystemen nach einem Failover.
-
Allgemeiner
Stand der Technik
-
Router
und Routingsysteme sorgen für
das Routing von Paketen zwischen Knoten eines paketvermittelten
Netzes. Um die Zuverlässigkeit
des paketvermittelten Netzes zu steigern, können Routingsysteme, die an
Knoten des Netzes arbeiten, redundante Routingeinrichtungen enthalten.
Zum Beispiel kann ein Routingsystem einen primären oder aktiven Routingprozessor,
der gewöhnlich
die Paketweiterleitung durchführt
oder verwaltet, und einen sekundären
oder Backup-Routingprozessor, um nach einem Ausfall von dem primären Routingprozessor
zu übernehmen,
enthalten. Bei der Umschaltung (d. h. dem Failover) von einem primären zu einem
sekundären Routingprozessor
handelt es sich jedoch oft um ein Störereignis. Zum Zeitpunkt des
Failovers sollte der aktuelle Zustand des primären Routingprozessors von dem
sekundären
Routingprozessor widergespiegelt werden. Viele herkömmliche
Routingsysteme wenden eine aktive Replikationstechnik an, um Ausfälle einzuplanen.
In diesen Systemen werden Zustandsinformationen ständig auf
dem Backup-Prozessor gespeichert (d. h. es werden Prüfpunkte
erstellt). Bei der aktiven Replikation kann die Wiederherstellung
nach Ausfällen
schnell erfolgen, bei der gewöhnlichen
Ausführung
liegt jedoch ein großer Overhead
vor. Die aktive Replikation setzt eine redundante Struktur ein,
die aus zwei Prozessorressourcen (z. B. zwei Prozessoren und einem
Speicher) besteht. Ein Problem mit der aktiven Replikation besteht darin,
dass, weil die Replikation ständig
durchgeführt wird,
während
das System läuft,
die Verarbeitungsressourcen verschwenderisch verwendet werden.
-
Das
Routingprotokoll BGP-4 (Border-Gateway-Protokoll) ist eines der
primären
Protokolle, das für
Internet-Routing verwendet wird, und ist ein inkrementelles Protokoll,
das auf dem TCP-Transport basiert. Eine BGP-Version wird im Request
for Comments (RFC) 1771, als RFC 1771 bezeichnet, der Network Working
Group mit dem Titel „A
Border Gateway Protocol 4 (BGP-4)", herausgegeben von Y. Rekhter und T.
Li und mit März
1995 datiert, beschrieben, während
andere Versionen in folgenden Aktualisierungen und Überarbeitungen
von RFC 1771 beschrieben werden. Der dynamische Austausch von Routinginformationen
für das
BGP wird im RFC 2918 der Network Working Group mit dem Titel „Route
Refresh Capability for BGP-4" von
E. Chen und mit September 2000 datiert beschrieben. Die Tatsache,
dass das TCP-Transportprotokoll selbst ziemlich komplex ist, in
Verbindung mit der Komplexität
des BGP-Protokolls und des schieren Umfangs der Daten, der in der
Regel involviert ist, hat es schwierig gestaltet, ein hoch zuverlässiges BGP-Routingsystem
unter Verwendung von primären
und Backup-Routingprozessoren zu unterstützen, da es schwierig ist,
den TCP-Zustand aufrechtzuerhalten, und es schwierig ist, einen
BGP-Router nach einem Failover mit BGP-Peer-Routern zu synchronisieren.
Herkömmliche
Systeme wechseln entweder das Protokoll oder setzen ein umfangreiches
Erstellen von Prüfpunkten (Checkpointing)
ein. Zum Beispiel erstellen einige herkömmliche Ansätze Prüfpunkte von im Wesentlichen
allen Zustandsdaten (sowohl TCP-Zustand als auch BGP-Protokoll-Zustand). Dieses
umfangreiche Checkpointing verbraucht unmäßige Ressourcen eines Systems,
was die Systemleistung mindert.
-
Folglich
besteht ein allgemeiner Bedarf an einem verbesserten Routingsystem
und Routingverfahren. Folglich besteht außerdem Bedarf an einem Routingsystem
und -verfahren, das das Ausmaß an Checkpointing
reduziert, das während
normalen Routingvorgängen
erforderlich ist. Es besteht außerdem
Bedarf an einem Routingsystem und -verfahren, das nach Ausfall eines
primären
Routingprozessors mit Peer-Routingsystemen
neu synchronisiert. Es besteht außerdem Bedarf an einem Routingsystem und
-verfahren, das ein Border-Gateway-Protokoll (BGP) unterstützt und
nach Ausfall eines primären Routingprozessors
mit Peer-Routingsystemen ohne unmäßiges Checkpointing neu synchronisiert.
Es besteht außerdem
Bedarf an einem Routingsystem und -verfahren, das nach Ausfall eines
primären
Routingprozessors mit Peer-Routingsystemen
neu synchronisiert, ohne dass erforderlich ist, dass die Peer-Systeme
ihre Software aktualisieren.
-
US-A-6148410
offenbart primäre
und Backup-Router, deren Tabellen synchronisiert sind, um einen
Transfer zum Backup-Router
zu ermöglichen.
-
Die
Erfindung stellt ein Schaltverfahren, ein Routingsystem und eine
Schaltvorrichtung bereit, wie in den Ansprüchen 1, 13 und 17 definiert.
-
In
einer Ausführungsform
stellt die vorliegende Erfindung ein Verfahren zum Synchronisieren
eines BGP-Routingsystems (BGP = Border-Gateway-Protokoll) mit Peer-BGP-Routingsystemen
nach Ausfall eines primären
Prozessors des BGP-Routingsystems
bereit. In dieser Ausführungsform
setzt der primäre
Prozessor eine ursprüngliche
Routingdatenbank zum Durchführen
von Routing ein und erhält eine
Präfixtabelle
aufrecht, auf die ein Backup-Routingprozessor zugreifen kann und
die Präfixe
von Routen der ursprünglichen
Routendatenbank aufführt.
Die Präfixtabelle
steht dem Backup-Routingprozessor nach einem Ausfall des primären Routingprozessors
zur Verfügung.
Das Verfahren, das von dem Backup-Prozessor nach Erkennung eines
Ausfalls des primären
Routingprozessors durchgeführt wird,
umfasst das Senden von BGP-Routenauffrischungsnachrichten an die
BGP-Peer-Routingsysteme.
Die BGP-Routenauffrischungsnachrichten fordern Routen an, die von
den BGP-Routingsystemen unterstützt
werden. In dieser Ausführungsform
beinhaltet das Verfahren außerdem
das Empfangen von Routen von den BGP-Peer-Routingsystemen als Reaktion
auf die BGP-Routenauffrischungsnachrichten und das Erstellen einer
Backup-Routingdatenbank (d. h. regenerierten Routingdatenbank) aus
den Routen, die von den BGP-Peer-Routingsystemen empfangen wurden.
Präfixe
von Routen in der Backup-Routingdatenbank werden mit Präfixen in
der Präfixtabelle
verglichen und BGP-Routenrückzugsnachrichten
werden an die Peer-Routingsysteme für Routen mit Präfixen, die
in der Präfixtabelle
aufgeführt sind,
jedoch nicht in der Backup-Routingdatenbank identifiziert wurden,
gesendet.
-
In
einer anderen Ausführungsform
stellt die vorliegende Erfindung ein Routingsystem bereit. Das Routingsystem
umfasst einen primären
Routingprozessor, einen Backup-Routingprozessor
und mehrere Leitungsschnittstellen zum Routen von Kommunikationen
gemäß einer
Routingdatenbank, die von den Routingprozessoren verwaltet wird.
Als Reaktion auf die Erkennung eines Ausfalls des primären Routingprozessors
erstellt der Backup-Routingprozessor eine Backup-Routingdatenbank aus Routen, die von Peer-Routingsystemen
empfangen wurden, vergleicht Präfixe
von Routen in der Backup-Routingdatenbank mit Präfixen in einer Präfixtabelle
und sendet Routenrückzugsnachrichten
an die Peer-Routingsysteme für
Routen mit Präfixen,
die in der Präfixtabelle aufgeführt sind
und nicht in der Backup-Routingdatenbank identifiziert wurden. Bei
Erkennung eines Ausfalls des primären Routingprozessors wird
der Backup-Routingprozessor angewiesen, einen Failover-Prozess durchzuführen, um
die Durchführung von
Routingmanagement durch den Backup-Prozessor zu ermöglichen. Der Failover-Prozess
beinhaltet das Abrufen der Routen von Peer-Routingsystemen. Der
Backup-Routingprozessor kann die Backup-Routingdatenbank mittels
Löschen
von redundanten Routen erstellen, indem er einen „Best-Path"-Algorithmus implementiert,
um die redundanten Routen, die von Peer-Routingsystemen empfangen
wurden, zu eliminieren.
-
Wenn
eine Routenaktualisierungsnachricht von einem der Peer-Routingsysteme
empfangen wird, die eine neue Route anzeigt, die von diesem Peer-Routingsystem
gehandhabt wird, kann die neue Route zu der aktuellen Routingdatenbank
hinzufügt werden.
Als Teil des Checkpointing kann die Präfixtabelle mit einem Präfix der
neuen Route aktualisiert werden, wenn das Präfix nicht bereits in der Präfixtabelle
aufgeführt
ist.
-
Kurzbeschreibung der Zeichnungen
-
Die
angefügten
Ansprüche
sind auf einige der verschiedenen Ausführungsformen der vorliegenden
Erfindung ausgerichtet. Die ausführliche
Beschreibung bietet jedoch ein vollständigeres Verständnis der
vorliegenden Erfindung, wenn sie in Verbindung mit den Figuren betrachtet
wird, in denen gleiche Bezugsziffern sich auf ähnliche Elemente in den gesamten
Figuren beziehen und:
-
1 stellt
ein Netz von Routingsystemen gemäß einer
Ausführungsform
der vorliegenden Erfindung dar;
-
2 ist
ein Beispiel einer Routingdatenbank gemäß einer Ausführungsform
der vorliegenden Erfindung;
-
3 ist
ein Funktionsblockdiagramm eines Routingsystems gemäß einer
Ausführungsform
der vorliegenden Erfindung;
-
4 ist
ein Beispiel einer Präfixtabelle
gemäß einer
Ausführungsform
der vorliegenden Erfindung;
-
5 ist
ein Ablaufdiagramm eines Routingsystem-Synchronisierungsvorgangs gemäß einer Ausführungsform
der vorliegenden Erfindung und
-
6 ist
ein Ablaufdiagramm eines Wiederherstellungsvorgangs gemäß einer
Ausführungsform der
vorliegenden Erfindung.
-
Ausführliche
Beschreibung
-
Die
folgende Beschreibung und die Zeichnungen veranschaulichen spezifische
Ausführungsformen
der Erfindung ausreichend, um Fachmännern zu ermöglichen,
sie auszuüben.
-
Andere
Ausführungsformen
können
strukturelle, logische, elektrische, Verfahrens- und andere Veränderungen
einbinden. Beispiele exemplifizieren lediglich mögliche Variationen. Der Schutzumfang der
Erfindung umfasst den kompletten Umfang der Ansprüche.
-
In
verschiedenen Ausführungsformen
stellt die vorliegende Erfindung ein verbessertes Routingsystem
und Routingverfahren bereit. In Ausführungsformen stellt die vorliegende
Erfindung außerdem
ein Routingsystem und -verfahren bereit, das das Ausmaß an Checkpointing
reduziert, das während
normalen Routingvorgängen
erforderlich ist. In anderen Ausführungsformen stellt die vorliegende
Erfindung ein Routingsystem und -verfahren bereit, das nach Ausfall
eines primären
Routingprozessors mit Peer-Routingsystemen neu synchronisiert. In
anderen Ausführungsformen
stellt die vorliegende Erfindung außerdem ein Routingsystem und
-verfahren bereit, das ein Border-Gateway-Protokoll (BGP) unterstützt und
nach Ausfall eines primären
Routingprozessors mit Peer-Routingsystemen ohne unmäßiges Checkpointing
neu synchronisiert. In anderen Ausführungsformen stellt die vorliegende
Erfindung außerdem
Bedarf an einem Routingsystem und -verfahren bereit, das nach Ausfall
eines primären
Routingprozessors mit Peer-Routingsystemen neu synchronisiert, ohne
dass erforderlich ist, dass die Peer-Systeme ihre Software aktualisieren.
In verschiedenen Ausführungsformen
kann die vorliegende Erfindung das BGP zum Routen von IPv4-Protokoll-Paketen, IPv6-Protokoll-Paketen, CLNS-Paketen
(CLNS = connectionless network service, verbindungsloser Betrieb)
sowie gemäß anderen
Protokollen konfigurierten Paketen unterstützen.
-
Ausführungsformen
der vorliegenden Erfindung stellen ein transparentes Routingsystem-Failover
bereit, indem während
des normalen Betriebs Prüfpunkte
von Routenpräfixen
in einer Routenpräfixtabelle
erstellt werden. Wenn einer Routingdatenbank neue Routen hinzugefügt werden,
wird die Routenpräfixtabelle
aktualisiert, wenn ein Präfix
für die neue
Route nicht in der Präfixtabelle
ist. Nach Ausfall eines primären
Routingprozessors wird das Routing mit Peer-Routingsystemen mittels Verwendung dieser
Präfixtabelle
synchronisiert. Bei Erkennung eines Ausfalls ruft ein Backup-Routingprozessor
als Reaktion auf den Ausfall Routen von Peer-Routingsystemen ab
und erstellt eine Backup-Routingdatenbank aus
den Routen, die von Peer-Routingsystemen empfangen wurden. Der Backup-Routingprozessor sendet
dann Routenankündigungsnachrichten
an die Peer-Routingsysteme
für Routen
in der Backup-Routingtabelle. Der Backup-Routingprozessor vergleicht außerdem Präfixe von
Routen in der Backup-Routingdatenbank mit Präfixen in der Präfixtabelle
und sendet Routenrückzugsnachrichten
an die Peer-Routingsysteme für
Routen mit Präfixen,
die in der Präfixtabelle
aufgeführt
sind und nicht in der Backup-Routingdatenbank
identifiziert wurden.
-
In
einigen Ausführungsformen
der vorliegenden Erfindung kann ein Border-Gateway-Protokoll (BGP)
unterstützt
werden. Ein Beispiel des BGP ist in der Schrift Request for Comments:
1771, als RFC 1771 bezeichnet, von der Network Working Group mit
dem Titel „A
Border Gateway Protocol 4 (BGP-4)", datiert mit März 1995, herausgegeben von Y.
Rekhter und T. Li, beschrieben. Diese Überarbeitung von RFC 1771 und
etwaige spätere
Versionen und Überarbeitungen
sind hierin durch Bezugnahme aufgenommen.
-
1 stellt
ein Netz von Routingsystemen gemäß einer Ausführungsform
der vorliegenden Erfindung dar. Ein Netz 100 enthält mehrere
Routingsysteme (RS) 102, die über Verbindungsstrecken 104 mit
Peer-Routingsystemen kommunizieren. Peer-Routingsysteme beziehen
sich auf Routingsysteme, auf die ein bestimmtes Routingsystem direkt zugreifen
kann, ohne durch ein Zwischenroutingsystem routen zu müssen. Zum
Beispiel können
die Peer-Routingsysteme von Routingsystem 106 die Routingsysteme 108, 110, 112 und 114 beinhalten. Peer-Routingsysteme
beinhalten außerdem
Routingsysteme, die möglicherweise
nicht direkt mittels einer Verbindungsstrecke gekoppelt sind, jedoch
kommunizieren, als wenn sie direkt gekoppelt wären. 1 kann nur
einen kleinen Teil des Netzes 100 darstellen, das viele
Zehntausende oder mehr Routingsysteme 102 umfassen kann.
Die Verbindungsstrecken 104 können eine beliebige Art von
Kommunikationsverbindung umfassen, die für die Kommunikation von paketierten
Daten zwischen Routingsystemen sorgt. Die Verbindungsstrecken 104 können eine
beliebige Art von Kommunikationsverbindung beinhalten, einschließlich drahtloser
Verbindungsstrecken, optischer Verbindungsstrecken, verdrahteter
Verbindungsstrecken und anderer Verbindungsstrecken, die nicht hierin
aufgezählt
sind.
-
In
einer Ausführungsform
können
mindestens einige der Routingsysteme 102 eine Paketweiterleitung
in Übereinstimmung
mit dem BGP durchführen.
Gemäß dieser
Ausführungsform
werden zunächst
Routingtabellen zwischen den Knoten (z. B. den Systemen 102)
ausgetauscht und das Routing kann von jedem Knoten gemäß seiner
lokal gespeicherten Routingdatenbank durchgeführt werden. Inkrementelle Aktualisierungen
werden zwischen Knoten gesendet, um deren Routingdatenbanken zu
aktualisieren. Jedes Routingsystem kann eine Routingdatenbank bewahren,
die aktuelle Routinginformatio nen von ihren Peer-Systemen für die Dauer
der Verbindung enthält.
Keep-Alive-Nachrichten können
periodisch gesendet werden, um dabei zu helfen, die Lebendigkeit
der Verbindung sicherzustellen.
-
2 ist
ein Beispiel eines Teils einer Routingdatenbank gemäß einer
Ausführungsform
der vorliegenden Erfindung. Die Routingdatenbank 200 kann
von einem Routingsystem aus Routinginformationen, die von Peer-Knoten
empfangen wurden, erstellt werden. Die Routinginformationen, die
von Peer-Knoten
empfangen wurden, können
Routingtabellen enthalten oder können
in Form von Routingaktualisierungsnachrichten sein. Wie hierin verwendet, kann
der Ausdruck „Routingdatenbank" eine beliebige Datenstruktur
beinhalten, die zum Routen verwendet wird. In einigen Ausführungsformen,
einschließlich
der BGP-Ausführungsformen,
kann sich der Ausdruck „Routingdatenbank" auf eine Routinginformationsdatenbank
(RIB) beziehen. In den BGP-Ausführungsformen
wird eine lokale Backup-RIB erstellt und dazu verwendet, eine Backup-Weiterleitungsinformationsdatenbank
(forwarding information base, FIB) zu erstellen, in der die Daten
auf Leitungskarten heruntergeladen werden können.
-
Die
Routingdatenbank 200 kann eine Präfixspalte 202 beinhalten,
die ein Präfix,
wie ein IP-Adressen-Präfix,
enthalten kann. Ein beispielhaftes IP-Adressen-Präfix ist „192.168.42/24", wobei „/24" eine Anzahl von
Bits in dem Präfix
bezeichnen kann. Dieses beispielhafte IP-Präfix kann ein Teil einer IP-Adresse
sein. Dieses beispielhafte IP-Präfix 192.168.42/23
wäre ein
23-Bit-Präfix,
das in sich selbst sowohl 192.168.42/24 als auch 192.168.43/24 sowie
alle längeren
Präfixe
(d. h. 192.168.42.*/[25-32] und 192.168.43.*/[25-32]) beinhaltet.
Eine andere Methode zum Schreiben von 192.168.42/24 ist mit einer „Netzmaske", die die signifikanten
Bits anzeigt. Wenn sie auf diese Weise dargestellt wird, wäre sie 192.168.42.0 255.255.255.0,
wobei das erste mit Punkten versehene Quad die Adresse und das zweite
die Maske ist. Für
eine IPv4-Adresse kann es bis zu 2^32 Präfixe geben. Identische Präfixe in
Spalte 202 können
mit mehr als einer Route oder einem Pfad zum Routen von Daten in
Zusammenhang gebracht werden. Die Spalte 204 identifiziert
eine Next-Hop-Adresse für eine
bestimmte Route. Die Next-Hop-Adresse kann die IP-Adresse eines
Grenzrouters sein, der als der nächste
Hop zu einem in einer Aktualisierungsnachricht identifizierten Ziel
verwendet werden sollte.
-
Einträge in der
Routingdatenbank 200 können
außerdem
die Spalte 206 beinhalten, die ein AS-Pfad-Attribut (AS
= autonomes System) für
jede Route identifizieren kann. In einer Ausführungsform, die BGP-4 unterstützt, kann
eine Menge erreichbarer Ziele durch ein einziges IP-Präfix ausgedrückt werden.
Routen mit demselben Präfix
in Spalte 202 können
einen unterschiedlichen, in Spalte 206 identifizierten
AS-Pfad aufweisen. Routingdatenbanken 200 können voneinander
unterschieden werden, indem sie entweder einen unterschiedlichen,
in Spalte 206 identifizierten AS-Pfad oder unterschiedliche, in Spalte 208 identifizierte
Pfadattribute aufweisen. Pfadattribute können beispielsweise das Peer-System identifizieren,
das eine bestimmte Route gesendet hat. In einigen Ausführungsformen
(z. B. einigen Nicht-BGP-Ausführungsformen)
kann die Routingdatenbank 200 eine höhere oder niedrigere Anzahl
von Spalten für
jede Route als die angezeigten beinhalten.
-
Ein
Routingsystem, wie das Routingsystem 102 (1),
kann die Routingdatenbank 200 aus Routinginformationen
(z. B. Aktualisierungsnachrichten) erstellen, die von Peer-Routingsystemen empfangen
werden können.
Eine Aktualisierungsnachricht kann Routen identifizieren, die von
einem Peer-Routingsystem unterstützt
werden, und kann ein Präfix
und einen AS-Pfad enthalten. Eine Aktualisierungsnachricht kann
auch Routen identifizieren, die ein Peer-Routingsystem nicht mehr
unterstützt.
In diesem Fall kann eine Route in einem „Zurückgezogene Routen"-Feld einer Aktualisierungsnachricht angezeigt
werden, die von dem Peer-System empfangen wird.
-
In
einer Ausführungsform
können
Aktualisierungsnachrichten zum Übertragen
von Routinginformationen zwischen Peer-Routingsystemen verwendet werden. Die
Informationen in einem Aktualisierungspaket können dazu verwendet werden,
einen Graph zu konstruieren, der die Beziehungen der verschiedenen
autonomen Systeme beschreibt. Mittels Anwendung von Richtlinien
können
Routinginformationsschleifen und einige andere Anomalien erkannt und
aus dem Routing zwischen autonomen Systemen gelöscht werden. In dieser Ausführungsform kann
eine Aktualisierungsnachricht einem Peer eine oder mehrere durchführbare Routen
ankündigen oder
mehrere undurchführbare
Routen aus dem Dienst genommen. Eine Aktualisierungsnachricht kann
auch gleichzeitig eine oder mehrere durchführbare Routen ankündigen und
mehrere undurchführbare
Routen aus dem Dienst nehmen. Eine Aktualisierungsnachricht kann
einen Kopfteil fester Länge enthalten
und kann gegebenenfalls die anderen Felder enthalten, wie ein „Länge von
undurchführbaren Routen"-Feld, ein „Zurückgezogene Routen"-Feld, ein „Pfadattributgesamtlänge"-Feld, ein „Pfadattribute"-Feld und ein „Vermittlungsschicht-Erreichbarkeitsinformationen"-Feld.
-
Das „Länge von
undurchführbaren
Routen"-Feld kann
eine vorzeichenlose ganze Zahl von zwei Oktetten umfassen, die die
Gesamtlänge
des „Zurückgezogene
Routen"-Felds in
Oktetten anzeigt. Sein Wert kann auch ermöglichen, die Länge des „Vermittlungsschicht-Erreichbarkeitsinformationen"-Felds zu bestimmen.
Ein Wert von Null kann anzeigen, dass keine Routen aus dem Dienst
genommen sind und dass das „Zurückgezogene
Routen"-Feld in
dieser Aktualisierungsnachricht nicht vorliegt. Das „Zurückgezogene
Routen"-Feld kann
ein Feld variabler Länge
sein, das eine Liste von Präfixen von
IP-Adressen für
die Routen enthält,
die aus dem Dienst genommen werden. Jedes IP-Adressen-Präfix kann
als ein 2-Tupel der Form <Länge, Präfix> kodiert werden. Das „Länge"-Feld kann die Länge in Bits
des IP-Adressen-Präfixes anzeigen.
Eine Länge von
Null kann ein Präfix
anzeigen, das auf alle IP-Adressen passt. Das Präfix-Feld kann IP-Adressen-Präfixe enthalten,
auf die genügend
nachlaufende Bits folgen, um zu bewirken, dass das Ende des Felds
auf eine Oktettgrenze fällt.
Die Pfadattributgesamtlänge
kann eine vorzeichenlose ganze Zahl von zwei Oktetten sein, die
dazu verwendet wird, die Gesamtlänge
des „Pfadattribute"-Felds in Oktetten
anzeigt. Ein Wert von Null kann anzeigen, dass in dieser Aktualisierungsnachricht
kein „Vermittlungsschicht-Erreichbarkeitsinformationen"-Feld vorliegt. Die Pfadattribute können eine
Sequenz variabler Länge
von Pfadattributen sein. Pfadattribute können einen Ursprung enthalten,
der den Ursprung der Pfadinformationen definiert. Der AS-Pfad ist
ein Attribut, das sich aus einer Sequenz von AS-Pfadsegmenten zusammensetzen
kann. Jedes AS-Pfadsegment kann von einem Tripel <Pfadsegmenttyp,
Pfadsegmentlänge,
Pfadsegmentwert> dargestellt
werden. Obwohl Ausführungsformen
der vorliegenden Erfindung hierin für die Unterstützung des
BGP für IPv4-Pakete beschrieben
werden, kann die vorliegende Erfindung in anderen Ausführungsformen
das BGP zum Routen von IPv6-Protokoll-Paketen, CLNS-Paketen
(CLNS = connectionless network service, verbindungsloser Betrieb)
sowie gemäß anderen
Protokollen konfigurierten Paketen unterstützen. In einer Ausführungsform
müssen
Aktualisierungsnachrichten nur eine zurückgezogene Route durch das
Präfix
identifizieren.
-
3 ist
ein Funktionsblockdiagramm eines Routingsystems gemäß einer
Ausführungsform
der vorliegenden Erfindung. Das Routingsystem 300 kann
das Routing zwischen Peer-Routingsystemen wie hierin beschrieben
durchführen.
Das Routingsystem 300 kann zur Verwendung als eines der
Routingsysteme 102 (1) geeignet
sein, obwohl andere Routingsysteme ebenfalls geeignet sind. Das
Routingsystem 300 kann einen primären Routingprozessor 302,
einen Backup-Routingprozessor 304 und mehrere Leitungsschnittstellen 306 zum
Routen von Kommunikationen, die über
Verbindungsstrecken 308 empfangen wurden, gemäß einer
Routingdatenbank, die von den Routingprozessoren verwaltet wird,
beinhalten. Die Routingdatenbank 200 (2) ist
ein Beispiel einer geeigneten Routingdatenbank zur Verwendung durch
Routingprozessoren. Das Routingsystem 300 kann ein transparentes
Failover bereitstellen, indem während
des normalen Betriebs Prüfpunkte
von Routenpräfixen
erstellt werden, indem eine Routenpräfixtabelle aufrechterhalten
wird. Ein Beispiel einer geeigneten Präfixtabelle ist in 4 dargestellt.
Als Reaktion auf die Erkennung eines Ausfalls eines primären Routingprozessors 302 erstellt
der Backup-Routingprozessor 304 eine
Backup-Routingdatenbank (z. B. regenerierte Routingdatenbank) aus
Routen, die von Peer-Routingsystemen empfangen
wurden. Der Backup-Routingprozes sor 304 kann auch Routenankündigungsnachrichten
an Peer-Routingsysteme
für Routen,
die in der Backup-Routingdatenbank identifiziert wurden, senden. Der
Backup-Routingprozessor 304 kann auch Präfixe von
Routen in der Backup-Routingdatenbank
mit Präfixen
in einer Präfixtabelle
vergleichen und kann Routenrückzugsnachrichten
an die Peer-Routingsysteme
für Routen
mit Präfixen,
die in der Präfixtabelle aufgeführt sind
und nicht in der Backup-Routingdatenbank
identifiziert wurden, senden. In einer BGP-Ausführungsform können eine
Routenankündigungsnachricht
und eine Routenrückzugsnachricht beide
berücksichtigte
Formen einer BGP-Aktualisierungsnachricht sein.
-
In
einer Ausführungsform
kann der Backup-Routingprozessor 304 bei Erkennung eines
Ausfalls des primären
Routingprozessors 302 angewiesen werden, einen Failover-Prozess
durchzuführen, um
die Durchführung
von Routingmanagement durch den Backup-Prozessor 304 zu
ermöglichen.
Der Failover-Prozess kann das Abrufen der Routen von Peer-Routingsystemen beinhalten.
Der Backup-Routingprozessor 304 kann eine Backup-Routingdatenbank
mittels Löschen
von redundanten Routen erstellen, indem er einen „Best-Path"-Algorithmus implementiert, um die redundanten
Routen, die von Peer-Routingsystemen empfangen wurden, zu eliminieren.
Jedes Routingsystem 302, 304 kann mindestens ein
Verarbeitungselement und einen zugehörigen Speicher enthalten. In
den BGP-Ausführungsformen
wird eine lokale Backup-RIB erstellt und dazu verwendet, eine Backup-Weiterleitungsinformationsdatenbank
(forwarding information base, FIB) zu erstellen, in der die Daten
auf Leitungskarten heruntergeladen werden können.
-
Während normaler
Vorgänge
kann der gegenwärtig
aktive Routingprozessor (entweder Routingprozessor 302 oder 304)
eine Routenaktualisierungsnachricht von einem der Peer-Routingsysteme empfangen,
die eine neue Route anzeigt, die von dem Peer-Routingsystem gehandhabt
wird. Der gegenwärtig
aktive Routingprozessor kann die neue Route zu einer aktuellen Routingdatenbank
hinzufügen.
Der gegenwärtig
aktive Routingprozessor kann auch einen Prüfpunkt des Präfixes erstellen,
indem er die Präfixtabelle
mit einem Präfix
der neuen Route aktualisiert, wenn das Präfix nicht in der Präfixtabelle aufgeführt ist.
Die Präfixtabelle
kann in einem Speicher des Backup-Routingverarbeitungssystems gespeichert
sein.
-
In
einer Ausführungsform,
wenn der gegenwärtig
aktive Routingprozessor eine Routenaktualisierungsnachricht von
einem der Peer-Routingsysteme empfängt, die eine zurückzuziehende
Route identifiziert, kann die Routenaktualisierungsnachricht eine
zurückgezogene
Route anzeigen, die nicht mehr von diesem Peer-Routingsystem gehandhabt
wird. Der gegenwärtig
aktive Routingprozessor kann die zurückgezogene Route aus der aktuellen
Routingdatenbank löschen.
Der gegenwärtig
aktive Routingprozessor kann auch ein Präfix der zurückgezogenen Route aus der Präfixtabelle
löschen,
wenn die aktuelle Routingdatenbank keine Routen mit diesem bestimmten
Präfix
enthält.
-
Die
Leitungsschnittstellen 306 routen Pakete gemäß der Routingdatenbank,
die von dem gegenwärtig
aktiven Routingprozessor über
einen Kommunikationspfad 310, bei dem es sich um einen
Bus handeln kann, bereitgestellt werden kann. In einer Ausführungsform,
nachdem die Routingdatenbank durch den aktiven Routingprozessor
aktualisiert wurde, kann die Aktualisierung den Leitungsschnittstellen 306 bereitge stellt
werden. Während
Failover-Vorgängen
können
die Leitungsschnittstellen 306 fortfahren, die Paketweiterleitung
gemäß der vor
kürzester
Zeit empfangenen Routingdatenbank durchzuführen, bis die regenerierte
Routingdatenbank empfangen wird. In einer Ausführungsform kann ein Systemmanager 312 dazu
verwendet werden, einen Ausfall des primären Routingprozessors 302 auf
viele verschiedene Weisen zu erkennen, einschließlich mittels Überwachen
von Signalen, wie Heartbeat-Nachrichten, vom Routingprozessor.
-
Obwohl
System 300 als mehrere separate Funktionselemente aufweisend
dargestellt ist, können
ein oder mehrere der Funktionselemente kombiniert und durch Kombinationen
von durch Software konfigurierten Elementen, wie Prozessoren, einschließlich digitalen
Signalprozessoren (DSPs), und/oder anderen Hardwareelementen, implementiert
werden. Sofern nicht spezifisch anders angegeben, können sich
Ausdrücke
wie Verarbeitung, Datenverarbeitung, Berechnung, Bestimmung, Anzeige oder
dergleichen auf eine Aktion und/oder einen Prozess eines oder mehrerer
Verarbeitungs- oder
Datenverarbeitungssysteme oder ähnlicher
Einrichtungen beziehen, die Daten, die als physikalische (z. B. elektronische)
Mengen in den Verzeichnissen und dem Speicher eines Verarbeitungssystems
dargestellt sind, verarbeiten und in andere Daten, die in ähnlicher
Weise als physikalische Mengen in den Verzeichnissen oder Speichern
des Verarbeitungssystems oder anderen derartigen Informationsspeicher-,
-übermittlungs-
oder -anzeigeeinrichtungen dargestellt sind, umwandeln können. Des
Weiteren, wie hierin verwendet, beinhaltet eine Datenverarbeitungseinrichtung
ein oder mehrere Verarbeitungselemente, die mit rechnerlesbarem
Speicher gekoppelt sind, bei dem es sich um einen flüchtigen
oder einen nichtflüchtigen
Speicher oder eine Kombination davon handeln kann. Darüber hinaus,
wie hierin verwendet, beziehen sich Daten auf ein oder mehrere Speicherdatenelemente,
die Teile von Dateien, eine einzige Datei, einen Dateibereich, eine
Datenbank, eine Speichereinrichtungspartition, einen Datenträger, Mengen
von Datenträgern
und dergleichen beinhalten können.
Die Daten müssen
sich nicht auf einer einzigen Speichereinrichtung befinden und können sich über mehrere
Speichereinrichtungen erstrecken.
-
4 ist
ein Beispiel einer Präfixtabelle
gemäß einer
Ausführungsform
der vorliegenden Erfindung. Die Präfixtabelle 400 kann
eine Liste von IP-Adressen-Präfixen 402 für Routen
enthalten, die von einem Routingsystem, wie dem Routingsystem 300 (3),
unterstützt
werden. Die Präfixtabelle 300 wird
von dem primären
Routingprozessor verwaltet und ein Backup-Routingprozessor kann
zumindest nach einem Ausfall des primären Routingprozessors auf sie
zugreifen. In einer Ausführungsform
müssen
Präfixe
der Tabelle 400 nur hinzugefügt werden, wenn der Routingdatenbank
eine neue Route hinzugefügt
wird, die ein Präfix
aufweist, das nicht bereits in der Präfixtabelle aufgeführt ist.
Zudem können
Präfixe
aus der Tabelle 400 gelöscht
werden, wenn eine Route aus der Routingdatenbank zurückgezogen
wird und keine weiteren Routen mit demselben Präfix in der Routingdatenbank
enthalten sind. Demgemäß kann die
Verwendung einer Präfixtabelle das
Ausmaß an
Checkpointing, das zur Neusynchronisierung mit Peer-Routingsystemen
erforderlich ist, erheblich reduzieren. Von einem Präfix wird
ein Prüfpunkt
in der Tabelle 400 erstellt, bevor die entsprechende Route
bzw. die entsprechenden Routen Peer-Systemen angekündigt werden. Andererseits müssen Routen
nicht unbedingt zurückgezogen
werden, bevor ein entsprechendes Präfix aus der Tabelle 400 gelöscht wird.
-
5 ist
ein Ablaufdiagramm eines Routingsystem-Synchronisierungsvorgangs gemäß einer Ausführungsform
der vorliegenden Erfindung. Der Synchronisierungsvorgang 500 kann
von einem Routingsystem, wie System 300 von 3,
implementiert werden, obwohl andere Routingsysteme zum Implementieren
des Vorgangs 500 geeignet sein können. Im Allgemeinen kann der
Vorgang 500 Peer-Routingsysteme mittels Anwendung von Checkpointing
synchronisieren und in einem im Wesentlichen transparenten Failover
resultieren. In einer Ausführungsform
kann der Routingsystem-Durchführungsvorgang 500 ein
Border-Gateway-Protokoll, wie das oben erörterte BGP, unterstützen, obwohl
dies keine Bedingung ist, und kann ein transparentes BGP-Failover
bereitstellen. In einer Ausführungsform
kann der Vorgang 500 in Kombination mit einer TCP-Sitzungswiederherstellungstechnik
implementiert werden.
-
Der
Vorgang 500 kann als ein Vorgang angesehen werden, der
während
normaler Vorgänge durchgeführt wird,
was Checkpointing und Routing beinhaltet. Nach einem Ausfall kann
ein Wiederherstellungsvorgang, wie der Vorgang 600 (6), durchgeführt werden,
der ein erneutes Beziehen und eine Neuverteilung von Routen beinhaltet.
-
In
Vorgang 502 kann das Routingsystem Kommunikationen gemäß einer
oder mehrerer Routingdatenbanken routen. In einer Ausführungsform kann
das Routingsystem mehrere Leitungsschnittstellen, wie Schnittstellenkarten,
für bestimmte
Kommunikationsstrecken beinhalten. Die Leitungsschnittstellen können eine
aktuelle Routingdatenbank, wie die Routingdatenbank 200 (2),
zur Verwendung beim Routen von Kommunikationen speichern. Die aktuelle
Routingdatenbank kann von einem aktiven Routingprozessor bereitgestellt
werden, der unter anderem die Routingdatenbank verwaltet.
-
In
Vorgang 504 kann eine neue Route von einem Peer-Routingsystem empfangen
werden. In einer Ausführungsform
kann die neue Route als Teil einer Routenaktualisierungsnachricht
empfangen werden, die in Übereinstimmung
mit dem BGP sein kann. Wenn eine neue Route empfangen wird, kann
der aktive Routingprozessor die aktuelle Routingdatenbank in Vorgang 506 aktualisieren.
Wenn in Vorgang 504 keine neue Route empfangen wird, kann
Vorgang 502 wiederholt werden.
-
In
Vorgang 508 wird ein Prüfpunkt
der neuen Route erstellt. In einer Ausführungsform beinhaltet der Vorgang 508 das
Hinzufügen
eines Präfixes
für die
neue Route zu einer Präfixtabelle,
auf die ein Backup-Routingprozessor zugreifen kann. Der Backup-Routingprozessor
kann vorzugsweise zumindest nach einem Ausfall des primären Routingprozessors auf
die Präfixtabelle
zugreifen. Die Präfixtabelle 400 (4)
ist ein Beispiel einer geeigneten Präfixtabelle, die von dem Routingsystem
eingesetzt wird. Das Präfix
für eine
bestimmte Route wird der Präfixtabelle hinzugefügt, wenn
die empfangene Route für
ein Präfix
ist, das nicht zuvor in der Präfixtabelle
dargestellt wurde. Da eine Routingdatenbank viele alternative Routen
für dasselbe
Präfix
enthalten kann, kann eine erhebliche Reduzierung des Checkpointing
im Vergleich zu einem herkömmlichen
Verfahren, das von jeder Route einen Prüfpunkt erstellt, erzielt werden. In
einer Ausführungsform
wird nur von dem Präfix selbst
ein Prüfpunkt
erstellt (z. B. fünf
Byte oder weniger für
eine IPv4-Route).
-
In
einer Ausführungsform,
wenn in Vorgang 508 der aktuellen Routingdatenbank eine
Route hinzugefügt
wird, kann der aktive Routingprozessor Leitungsschnittstellen, wie
die Leitungsschnittstellen 306 (3), mit
aktualisierten Routinginformationen versorgen. Zudem, wenn der aktuellen
Routingdatenbank eine neue Route hinzugefügt wird, können Peer-Routingsystemen mitgeteilt
werden, dass das Routingsystem das Routing gemäß der empfangenen Route durchgeführt werden
wird. In einer BGP-Ausführungsform
sowie in einigen anderen Ausführungsformen
wird Checkpointing durchgeführt,
bevor eine entsprechende Route Peers angekündigt wird. Der Vorgang 500 kann
auch das Löschen
von Routen als Reaktion auf Routenaktualisierungsnachrichten bezüglich des
Zurückziehens
einer oder mehrerer Routen, die von Peer-Routingsystemen empfangen werden, beinhalten.
In diesem Fall kann Vorgang 508 das Löschen von Präfixen aus
der Präfixtabelle
beinhalten, wenn für
ein bestimmtes Präfix
keine Routen unterstützt
werden.
-
In
Vorgang 510 können
Aktualisierungsnachrichten an Peer-Routingsysteme gesendet werden. Die
Aktualisierungsnachrichten können
Peer-Routingsysteme über
Routen, die jetzt von dem derzeitigen Routingsystem gehandhabt werden,
zusätzlich zu
Routen, die nicht mehr von dem derzeitigen Routingsystem gehandhabt
werden, informieren. In einer BGP-Ausführungsform
kann Vorgang 510 das Senden von Routenaktualisierungsnachrichten
in Übereinstimmung
mit dem BGP beinhalten.
-
Während der
Durchführung
von Vorgang 500 können
Signale von dem gegenwärtig
aktiven (d. h. primären)
Routingprozessor überwacht
werden, um einen Ausfall zu erkennen. Zum Beispiel können Heartbeat-Nachrichten
von dem aktiven Routingprozessor überwacht werden, um einen Ausfall
zu erkennen. Ein Ausfall kann zu einem beliebigen Punkt während der
Durchführung
von Vorgang 500 erkannt werden. Wenn ein Ausfall des gegenwärtig aktiven Routingprozessors
erkannt wird, wird ein Wiederherstellungsvorgang eingeleitet, bei
dem ein Backup-Prozessor Routen von Peer-Routingsystemen abruft, um eine Backup-Routingdatenbank
zu erstellen. Wenn ein Ausfall des gegenwärtig aktiven Routingprozessors
nicht erkannt wird, werden die Vorgänge 502 bis 510 wiederholt
und das Routingsystem kann seine normalen Vorgänge fortsetzen, einschließlich des
Routens von Paketen und Erstellens von Prüfpunkten von Präfixen von
neuen Routen wie oben beschrieben.
-
Obwohl
die einzelnen Vorgänge
von Vorgang 500 als separate Vorgänge dargestellt und beschrieben
werden, können
einer oder mehrere der einzelnen Vorgänge gleichzeitig durchgeführt werden und
nichts macht erforderlich, dass die Vorgänge in der dargestellten Reihenfolge
durchgeführt
werden.
-
6 ist
ein Ablaufdiagramm eines Wiederherstellungsvorgangs gemäß einer
Ausführungsform der
vorliegenden Erfindung. Der Wiederherstellungsvorgang 600 kann
zur Verwendung geeignet sein, wenn ein Ausfall des gegenwärtig aktiven
(d. h. primären)
Routingprozessors erkannt wird. Der Vorgang 600 kann als
ein Failover-Prozess angesehen werden, der einem Backup-Prozessor
ermöglicht, Routingmanagement
durchzuführen.
Der Vorgang 600 kann zur Verwendung geeignet sein, wenn
ein Ausfall während
der Durchführung
des Vorgangs 500 (5) erkannt
wird. Unter anderem ruft ein Backup-Prozessor während der Durchführung des
Vorgangs 500 Routen von Peer-Routingsystemen ab, um eine
neue Routingdatenbank zu erstellen. In Vorgang 602 ruft
der Backup-Prozessor Routen von Peer-Routingsystemen ab und kann
in einer BGP-Ausführungsform
Routenauffrischungs-/-anforderungsnachrichten an die Peer-Systeme
senden. Als Reaktion auf die Anforderung von Routen kann der Backup-Routingprozessor
die Routen des Peers von den Peer-Systemen empfangen, die als Teil
von Routenaktualisierungsnachrichten empfangen werden können. Vorgang 602 kann
auch das Bestimmen beinhalten, wann alle oder genug Peer-Routen empfangen
wurden, das durch eine Heuristik (z. B. Empfangen einer Keep-Alive-Nachricht
oder einer leeren Aktualisierungsnachricht) implementiert werden kann.
Es kann auch eine Zeitabschaltung in dem Fall verwendet werden,
in dem die Keep-Alive- oder Aktualisierungsnachrichten nicht von
einem bestimmten Peer innerhalb einer vorbestimmten Zeitspanne als Reaktion
auf das Abrufen von Routen empfangen werden.
-
In
Vorgang 604 kann eine neue Routingdatenbank aus den Routen
erstellt werden, die von den Peer-Routingsystemen empfangen wurden.
Redundante Routen, die von den Peer-Routingsystemen empfangen wurden, können aus
der Datenbank gelöscht
werden. In einer Ausführungsform
kann der Vorgang 604 einen „Best-Path"-Algorithmus implementieren, um Routen
mit redundanten Präfixen,
die von den Peer-Routingsystemen empfangen wurden, zu eliminieren.
In BGP-Ausführungsformen
kann der Vorgang 604 die lokale Backup-RIB dazu verwenden,
eine Backup-Weiterleitungsinformationsdatenbank (forwarding Information
base, FIB) zu erstellen. Andere Verfahren zum Erstellen einer Routingdatenbank
können
ebenfalls für
verschiedene Ausführungsformen
geeignet sein.
-
In
Vorgang 606 werden die neuen Routen an die Peer-Routingsysteme gesendet
(z. B. diesen angekündigt).
Gemäß einer
BGP-Ausführungsform werden
die neuen Routen als Teil von BGP-Aktualisierungsnachrichten gesendet.
Diese Aktualisierung kann Peer-Systemen mitteilen, welche Routen
von dem Routingsystem unterstützt
werden, das die neuen Routen sendet. In Vorgang 608 werden
die Präfixe,
von denen in der Präfixtabelle
ein Prüfpunkt
erstellt wurde, mit Präfixen
von Routen in der neuen Routingdatenbank verglichen, die in Vorgang 604 erstellt
wurde. Wenn Vorgang 608 ein Präfix in der Präfixtabelle
identifiziert, das nicht mit einer beliebigen Route in der neuen
Routingdatenbank zusammenhängt,
kann der Vorgang 610 eine Rückzugsnachricht an Peer-Routingsysteme
senden, die anfordert, dass die Peer-Routingsysteme Routen mit dieser Präfix zurückziehen.
Der Vorgang 610 zieht Routen zurück, die zuvor als von dem ausgefallenen
Routingprozessor gehandhabt angekündigt wurden, und die Routen
sind nicht mehr in der Routingdatenbank. In einer Ausführungsform
kann eine BGP-Aktualisierungsnachricht
(die anzeigt, ein Präfix
zurückzuziehen)
für jedes
in der Präfixtabelle
vorliegende Präfix gesendet
werden, das nicht in der neuen Routingdatenbank (d. h. der wiederhergestellten
Datenbank) vorliegt. Beim Abschluss von Vorgang 610 sollten
die Zustände
der Peer-Routingsysteme mit dem Zustand des derzeitigen Routingsystems
synchronisiert werden.
-
In
Vorgang 612 kann die von dem Backup-Routingprozessor aufrechterhaltene
Präfixtabelle aktualisiert
werden, wobei die in Vorgang 610 identifizierten Präfixe gelöscht werden
können.
Der Backup-Routingprozessor kann jetzt als der primäre oder aktive
Routingprozessor angesehen werden und kann den Vorgang 614 durchführen. In
Vorgang 614 kann der jetzt aktive Routingprozessor das
Routing und die Routensynchronisierung unter Einsatz der neuen (d.
h. wiederhergestellten) Routingdatenbank und Präfixen, von denen ein Prüfpunkt erstellt
wurde, durchführen,
wie beispielsweise mittels Vorgang 500 (5)
beschrieben. In einer Ausführungsform
kann der ausgefallene Routingprozessor beispielsweise ersetzt, repariert
oder wieder in Dienst gestellt (z. B. neu gestartet) werden. Er
kann dann als ein Backup-Routingprozessor dienen.
-
Obwohl
die einzelnen Vorgänge
von Vorgang 600 als separate Vorgänge dargestellt und beschrieben
werden, können
einer oder mehrere der einzelnen Vorgänge gleichzeitig durchgeführt werden und
nichts macht erforderlich, dass die Vorgänge in der dargestellten Reihenfolge
durchgeführt
werden. In einigen Ausführungsformen
sollte die Hinzufügung von
Präfixen
zu der Präfixtabelle
(d. h. der Prüfpunkt) jedoch
abgeschlossen werden, bevor Peer-Routingsysteme über Routen informiert werden,
die diesen Präfixen
entsprechen.
-
In
mehreren anderen Ausführungsformen stellt
die vorliegende Erfindung einen Gegenstand bereit, der einen Speicherdatenträger umfasst,
auf dem Anweisungen gespeichert sind, die, wenn sie auf einer digitalen
Datenverarbeitungsplattform ausgeführt werden, im Abrufen von
Routen von Peer-Routingsystemen als Reaktion auf den Ausfall, Erstellen
einer Backup-Routingdatenbank aus den Routen, die von Peer-Routingsystemen
empfangen wurden, Vergleichen von Präfixen von Routen in der Backup-Routingdatenbank
mit Präfixen
in einer Präfixtabelle
und Senden von Routenrückzugsnachrichten
an die Peer-Routingsysteme für
Routen mit Präfixen,
die in der Präfixtabelle
aufgeführt
sind und nicht in der Backup-Routingdatenbank identifiziert wurden, resultieren.
Der Gegenstand kann beispielsweise eine Computerdiskette (z. B.
Magnetplatte oder CD) oder Computerspeicher sein und der Speicherdatenträger kann
ein beliebiger rechnerlesbarer Datenträger sein, einschließlich eines
magnetischen oder optischen Datenträgers, der zum Speichern von
digitalen Informationen geeignet ist.
-
Folglich
wurden ein System und ein Verfahren zum Schalten von Routingmanagement
zu einem Backup-Routingprozessor bei Ausfall eines primären Routingprozessors
beschrieben. Das System und das Verfahren können ein im Wesentlichen transparentes
Failover mittels Verwendung von Routenpräfixen, von denen Prüfpunkte
erstellt wurden, bereitstellen.
-
Die
vorstehende Beschreibung von spezifischen Ausführungsformen offenbart die
allgemeine Beschaffenheit der Erfindung ausreichend, so dass andere
sie unter Anwendung geläufigen
Wissens leicht für
verschiedene Anwendungen modifizieren und/oder anpassen können, ohne
vom allgemeinen Konzept abzuweichen. Folglich befinden sich solche Anpassungen
und Modifizierungen innerhalb der Bedeutung und des Bereichs von Äquivalenten
der offenbarten Ausführungsformen.
Die hierin eingesetzte Phraseologie oder Terminologie ist zum Zwecke
der Beschreibung und nicht zum Zwecke der Einschränkung. Demgemäß umspannt
die Erfindung alle derartigen Alternativen, Modifizierungen, Äquivalente
und Variationen, wie sie in die angefügten Ansprüche fallen.