-
Ausführungsbeispiele
gemäß der Erfindung
beziehen sich allgemein auf paketvermittelte Netzwerke und insbesondere
auf das Sammeln und Aufzeichnen von BGP-Routing-Protokollmitteilungen
(BGP = Border Gateway Protocol) in einem vermittelten Internetprotokoll-
(IP-) Netz.
-
Paketvermittelte
digitale Netze sind das Rückgrat
des Internet. In einem paketvermittelten Internetprotokoll- (IP-)
Netzwerk werden digitale Informationen, die von einer Quelle zu
einem Bestimmungsort fließen,
in eine Sequenz von Paketen unterteilt. Diese Pakete werden durch
eine Vielzahl von Routern und Schaltern durch das Netzwerk geleitet.
Es gibt keine Garantie, dass die Pakete alle der gleichen Route
folgen. Das Routing bzw. die Leitwegführung und die Routenverwaltung
steuert die Routen, denen Pakete folgen, und wie sich diese Routen ändern, anpassen
und auf Netzwerkbedingungen, wie z. B. Laden und Ausfälle, ansprechen.
-
Der
Paketverkehr wird zwischen Routern geschaltet. Ein Router ist ein
Computernetzwerkgerät,
das Hardware und Software kombiniert, um Datenpakete zu ihrem Bestimmungsort
weiterzuleiten. Ein Router verbindet mit anderen Routern, die, wenn
sie Border Gateway Protocol (BGP) verwenden, als Peers bzw. Partner bezeichnet
werden. Dieses anfängliche
Peering (wechselseitige Übertragung)
wird allgemein durch manuelle Konfiguration hergestellt. Jeder Router
behält
eine Tabelle von Netzwerken oder Vorzeichen bei, die Netzwerkerreichbarkeit
bestimmen. Peer-Router verwalten diese Tabellen durch Austauschen
von Mitteilungen gemäß dem Border
Gateway Protocol (BGP), das in RFC 1771 spezifiziert ist.
-
Routenverwaltung
ist ein Bereich aktiver Forschung in der Internetgemeinschaft, und
auch ein Bereich von Interesse für
Netzwerkdienstanbieter (NSPs, NSP = Network Service Provider). Durch Überwachen
und Verwalten von Routing kann man Probleme verfolgen, die von traditioneller
Netzwerkelement- und Dienstüberwachung
verpasst werden, und gleichzeitig Informationen sammeln, die sinnvoll
sind, wenn Peering bewertet wird. Um eine sinnvolle Routingverwaltung
durchzuführen,
wie sie Border-Gateway-Routing- (BGP-) Protokoll betrifft, ist es
notwendig, einzelne Routingaktualisierungen von Peer-Routern zu
sammeln.
-
Softwaretools
zum Aufzeichnen von Routinginformationen sind von zumindest zwei
Quellen erhältlich. Die
erste ist Zebra oder Quagga, was eine vollständig funktionsfähige Routingreihe
ist, die die Fähigkeit
hat, Routingaktualisierungen aufzuzeichnen. Mrtd, Teil des MRT-Programmpakets
von der University of Michigan ist auch in der Lage, Routingaktualisierungen
aufzuzeichnen. Beide diese Tools haben ihre Probleme, wenn sie als
Netzwerkinstrument verwendet werden. Zunächst sind sie aufgebaut, um
viel mehr zu tun, als notwendig ist, um einfach Routen aufzuzeichnen.
Beide Tools sind für
eine volle BGP-Routingfunktionalität in der Lage, und skalieren
hauptsächlich
aufgrund dieser zusätzlichen
Verarbeitung nicht gut. Zweitens stört das Verhalten dieser Tools
die Messungen, die dieselben aufzuzeichnen versuchen. Beide oben
erwähnten
Tools brechen die BGP-Peersitzung ab, wenn sie einen Fehler von
dem Peer empfangen, in Übereinstimmung
mit der BGP-Spezifikation.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein Verfahren zum Aufzeichnen
von BGP-Mitteilungen von BGP-Peers, eine verbesserte BGP-Routenaufzeichnungsvorrichtung
BRR zum Aufzeichnen von BGP-Mitteilungen von BGP-Peers sowie ein
computerlesbares Medium, das ausführbare Befehle zum Verarbeiten
von BGP-Mitteilungsverkehr in einer BGP-Routenaufzeichnungsvorrichtung BRR umfasst,
mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1, eine Aufzeichnungsvorrichtung
gemäß Anspruch
4 sowie ein Medium gemäß Anspruch
5 gelöst.
-
Gemäß der Erfindung
zeichnet eine Border-Gateway-Protocol- (BGP-) Routenaufzeichnungsvorrichtung
(BRR) alle ankommenden und abgehenden BGP-Mitteilungen auf und versieht
dieselben mit einem Zeitstempel. Peeringsitzungen können über Fehler
hinweg beibehalten werden, und der BRR ist es nur erlaubt, passiv
nach einer Peersitzungsinitialisierung zu hören.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegende Zeichnung näher
erläutert.
Es zeigt:
-
1 eine
Finit-Zustands-Maschine für
die Verwendung bei Ausführungsbeispielen
der vorliegenden Erfindung.
-
Die
Erfindung bezieht sich auf das Aufzeichnen von BGP-Mitteilungen in einem
paketvermittelten IP-Netzwerk. Die folgende Beschreibung ist dargelegt,
um es einem Fachmann auf diesem Gebiet zu ermöglichen, die Erfindung herzustellen
und zu verwenden, und ist im Zusammenhang einer Patentanmeldung
und ihren Anforderungen vorgesehen. Verschiedene Modifikationen
an den offenbarten Ausführungsbeispielen sind
für Fachleute
auf diesem Gebiet offensichtlich, und die allgemeinen Prinzipien
hierin können
auf andere Ausführungsbeispiele
angewendet werden. Somit soll die Erfindung nicht auf die gezeigten
Ausführungsbeispiele
beschränkt
sein sondern soll in Übereinstimmung
mit den angehängten
Ansprüchen
und mit den hierin beschriebenen Prinzipien und Merkmalen den breitesten
Schutzbereich haben.
-
Der
Betrieb von BGP-Routern ist in RFC 1771 definiert. Die aktuelle Überarbeitung
von RFC 1771 ist BGP-4, veröffent licht
im März
1995, hierin durch Bezugnahme aufgenommen und als RFC 1771 bezeichnet.
-
Unter
RFC 1771 bilden zwei Peers eine Verbindung miteinander. Sie tauschen
BGP-Mitteilungen aus, um die Verbindungsparameter zwischen denselben
zu öffnen
und zu bestätigen.
Abhängig
von der individuellen Routerkonfiguration ist der Anfangsdatenfluss
die gesamte BGP-Routingtabelle. Inkrementale regelmäßige Aktualisierungen
werden gesendet, während
sich die Routingtabellen ändern.
BGP erfordert keine regelmäßige Auffrischung
der gesamten BGP-Routingtabelle. Daher muss ein BGP-System eine
gesammelte Ansicht aller BGP-Routingtabellen
beibehalten, die durch jeden Peer gesendet werden, und auch die
Tabellenversionsnummer von jedem Peer für die Dauer der Verbindung
verfolgen. Aufrechterhalten-Mitteilungen
werden regelmäßig gesendet,
um die Lebendigkeit der Verbindung sicherzustellen. Ansprechend
auf Fehler oder spezielle Bedingungen werden Benachrichtigungsmitteilungen
gesendet. Falls eine Verbindung eine Fehlerbedingung antrifft, wird
eine Benachrichtigungsmitteilung gesendet und die Verbindung wird
geschlossen.
-
Es
sollte angemerkt werden, dass unter RFC 1771 die Verbindung zwischen
Peers geschlossen ist, falls eine Verbindung auf eine Fehlerbedingung
trifft. Wenn eine Verbindung zum ersten Mal geöffnet wird, oder nach dem Erholen
von einem Fehler wieder geöffnet
wird, wird gemäß RFC 1771
die gesamte BGP-Routingtabelle, die für diesen Peer bestimmt ist,
gesendet. Solche Fehler umfassen das Versagen, auf zeitgerechte Weise
auf eine Aufrechterhalten-Mitteilung anzusprechen, Mitteilungsanfangsblockfehler
(Typ 1), Aktualisierungsfehler (Typ 3), Halte-Zeitgeber-Abgelaufen-Fehler
(Typ 4) und Finit-Zustands-Maschinenfehler (Typ 5).
-
Bestehende
Routingreihen, wie z. B. Zebra und Mrtd, haben die Fähigkeit,
einen Teil, aber nicht den gesamten BGP-Verkehr aufzuzeichnen. Weil diese Aufzeichnungsfähigkeit
zu bestehenden Programmen hinzugefügt wurde, die eine volle BGP-Routingfunktionalität haben,
führen
dieselben Rauschen und Fehler in den aufgezeichneten BGP-Verkehr
ein.
-
Ausführungsbeispiele
der vorliegenden Erfindung liefern eine BGP- Routenaufzeichnungsvorrichtung (BRR),
die alle BGP-Mitteilungen
von Peers aufzeichnet. Die BRR gemäß der vorliegenden Erfindung
stellt keine BGP-Aktualisierungen her sondern zeichnet BGP-Mitteilungen
von verbundenen Systemen auf, sowie auch ihre eigenen Aufrechterhalten-,
Benachrichtigungs- und Schließen-Mitteilungen.
Von besonderer Bedeutung ist, dass die BRR eine Benachrichtigungsmitteilung
aufzeichnet, die es senden würde,
aber die Benachrichtigungsmitteilung nicht wirklich sendet. Die
Benachrichtigungsmitteilung enthält
den Grund, weshalb ein Fehler aufgetreten ist. Daher wäre das BRR-Verhalten
auf den Empfang eines Aktualisierungsfehlers hin beispielsweise,
die ursprüngliche
Aktualisierungsmitteilung aufzuzeichnen, wie sie empfangen wurde,
und eine Benachrichtigungsmitteilung des korrekten Typs gemäß dem Fehler
aufzuzeichnen, in diesem Fall ein Fehler vom Typ 3, aber die BRR
würde nie
die Benachrichtigung senden und auch nicht die Sitzung abbrechen.
Dieses Verhalten ist konfigurierbar, da ein fortlaufendes Wiederauftreten
einer Fehlerbedingung ohne ein Entkommen ebenfalls eine gefährliche
Bedingung ist, daher kann bei einem Ausführungsbeispiel die Anzahl von
Malen, die ein Fehler empfangen werden kann, bevor eine Benachrichtigungsmitteilung
tatsächlich
gesendet wird und die Sitzung abgebrochen wird, durch den Benutzer
konfiguriert werden.
-
Bei
einem Ausführungsbeispiel
der vorliegenden Erfindung werden die BGP-Mitteilungen so früh wie möglich mit
einem Zeitstempel versehen, vorzugsweise auf der Sockelebene des
Netzkommunikationsstapels. Bei Systemen, wie z. B. Zebra und Mrtd,
tritt das Versehen mit einem Zeitstempel zu dem Zeitpunkt auf, wenn eine
Mitteilung auf eine Platte zu schreiben ist, was viele Minuten nachdem
dieselbe empfangen wurde sein kann.
-
Die
Hauptfunktion von Systemen, wie z. B. Zebra und Mrtd, ist, dass
dieselben Router sind; BGB-Aufzeichnung ist ein Zusatz. Wenn Routingoperationen
und Routingverkehr einen wesentlichen Teil der Systemkapazität besetzen,
können
BGP-Mitteilungen
nicht aufgezeichnet werden. In der Tat ist es ein bekanntes Problem
mit Systemen, wie z. B. Zebra und Mrtd, dass dieselben unter schwerer
Belastung nicht in der Lage sind, BGP-Aufrechterhalten-Mitteilungen
mit Peers zu erzeugen, was dazu führt, dass die Sitzung mit diesem
Peer zurückgesetzt
und abgebrochen wird. Die Sitzung wird dann automatisch wiederhergestellt
und die volle Tabelle für
diesen Peer neu übertragen.
Dies führt
nicht nur Rauschen ein, wenn versucht wird, BGP-Protokollaktivität zu versuchen,
sondern kann auch eine Kaskade von Ausfällen verursachen, wenn die
Vorrichtung Belastung hinzufügt
durch Zurücksetzen
von Sitzungen und Empfangen voller Routingaktualisierungen für jede, wodurch
die Belastung der Aufzeichnungsvorrichtung verstärkt wird. Da aktuelle Verfahren
Programme verwenden, die volle Routingreihen implementieren, müssen diese
Programme Routingentscheidungen auf jeder Route beibehalten und
treffen, wenn dieselbe empfangen wird. Implementierungen der vorliegenden
Erfindung liefern ein speziell angefertigtes Messinstrument, das
nur Routingmitteilungen mit Zeitstempeln versieht und aufzeichnet,
und keinen weiteren Routingalgorithmus verwenden muss oder Routingtabellen
beibehalten muss, dies liefert eine wesentliche Verbesserung bei
der Leistung und wesentliche Einsparungen bei Hardwareerforderungen.
Außerdem,
wenn ein Router, wie z. B. Zebra oder Mrtd eine fehlerhafte Mitteilung
empfängt,
oder seinen Peers einen Fehler berichtet, werden diese BGP-Mitteilungen
nicht aufgezeichnet oder werden mit null Feldern aufgezeichnet.
Das Nichtaufzeichnen von Mitteilungen, insbesondere derjenigen,
die Fehler anzeigen oder zu solchen führen, ist für Instrumentierung und Messung
ein Gräuel.
Eine BRR gemäß der vorliegenden
Erfindung erfasst alle BGP-Mitteilungen, einschließlich denjenigen,
die Fehler signalisieren oder zu Fehlern führen.
-
Wenn
eine Site startet, versucht dieselbe gemäß RFC 1771, BGP-Sitzungen mit
allen konfigurierten Peers zu öffnen.
Wenn jede Sitzung geöffnet
wird, werden BGP-Routingtabellen mit Peers ausgetauscht. Mit einer
großen
Anzahl von Peers kann dies eine beträchtliche Menge an Verkehr darstellen.
Eine BRR gemäß der vorliegenden
Erfindung zeigt Verhalten, das von demjenigen abweicht, das in RFC
1771 spezifiziert ist. Eine BRR gemäß der vorliegenden Erfindung
startet in dem passiven Modus, hört
auf Verkehr und zeichnet denselben auf, aber wartet darauf, dass
Peers eine BGP-Sitzung öffnen.
-
1 zeigt
eine Finit-Zustands-Maschine, die für die Verwendung bei Ausführungsbeispielen
der vorliegenden Erfindung geeignet ist. Beim Betrieb besteht ein
Fall der Zustandsmaschine für
jede Peer-Verbindung.
-
Jedem
Fall der Zustandsmaschine, der eine Peer-Verbindung darstellt, ist
ein aktueller Zustand zugeordnet. Alle Zustandsmaschinen beginnen
im Leerlaufzustand 1. Die Finit-Zustands-Maschine, die in 1 gezeigt
ist, hat sechs Zustände:
-
- 1
- Leerlauf
- 2
- Verbinden
(nicht genutzt)
- 3
- Aktiv
- 4
- OffenGesendet
- 5
- OffenBestätigt
- 6
- Eingerichtet
-
Eine
Austrittsverarbeitung am Ende einer Aufzeichnungssitzung ist in 1 als 7 gezeigt.
Jedem Zustand ist ein Satz von Ereignissen und Übergangstabellen zugeordnet.
Ein Satz von Zuständen,
Ereignissen und Übergangstabellen,
der für
die in 1 gezeigte Finit-Zustands-Maschine geeignet ist,
ist als Anhang 1 angehängt.
Obwohl die Zustände
und Ereignisse gleich sind, wie es in RFC 1771 beschrieben ist,
ist anzumerken, dass sich die Übergangstabellen,
die durch die vorliegenden Erfindung verwendet werden, von denjenigen
in RFC unterscheiden.
-
Der
Satz von Ereignissen, die der Finit-Zustands-Maschine von 1 zugeordnet
sind, ist:
-
- 1 BGP Start
- 2 BGP Stop
- 3 BGP Transportverbindung offen
- 4 BGP Transportverbindung geschlossen
- 5 BGP Transportverbindung offen fehlgeschlagen
- 6 BGP Transport schwerwiegender Fehler
- 7 VerbindungsWiederholung Zeitgeber abgelaufen
- 8 Halte-Zeitgeber abgelaufen
- 9 Aufrechterhalten-Zeitgeber abgelaufen
- 10 Offen-Mitteilung empfangen
- 11 Aufrechterhalten-Mitteilung empfangen
- 12 Aktualisieren-Mitteilung empfangen
- 13 Benachrichtigungsmitteilung empfangen
-
In
jedem Zustand spezifiziert die zugeordnete Übergangstabelle von Anhang
1, welches Ereignis zu welchen Zuständen übergeht, und stellt auch Einzelheiten
anderer Verarbeitung dar, die auftritt, während Ereignisse gehandhabt
werden. Alle BGP-Mitteilungen, ankommend und abgehend, werden aufgezeichnet,
und auch die Benachrichtigungen. Wie es bei der Implementierung
von Finit-Zustands-Maschinen üblich
ist, kann es sein, dass nicht alle Ereignisse in jedem Zustand erlaubt
sind. Bei Routern, die mit RFC 1771 übereinstimmen, führen Fehler
und/oder verbotene Übergänge dazu,
dass die BGP-Peersitzung beendet wird. Bei einer BGP- Routenaufzeichnungsvorrichtung
(BRR) gemäß der vorliegenden
Erfindung werden solche Fehler protokolliert. Eine BRR gemäß der vorliegenden
Erfindung kann konfiguriert sein, um Verbindungen mit BGP-Peers
beizubehalten, wenn Fehler auftreten.
-
Alle
Peer-Verbindungen, und daher die Zustandsmaschine für jede Peer-Verbindung,
beginnt in dem Leerlaufzustand 1. Das BGP-Startereignis
bringt die Zustandsmaschine zu dem aktiven Zustand 3. Für jedes andere
Ereignis bleibt die Zustandsmaschine in dem Leerlaufzustand 1.
-
Der
Verbindungszustand 2 wird durch die BRR gemäß der vorliegenden
Erfindung nicht verwendet, aber wird durch BGP-Router verwendet, die RFC 1771 entsprechen.
-
In
dem aktiven Zustand 3 bleibt der Empfang eines BGP-Startereignisses
in dem aktiven Zustand 3. Der Empfang eines BGP-Stoppereignisses
geht zu dem Leerlaufzustand 1 über. Der Empfang eines BGP-Transportverbindungs-Offen-Ereignisses beginnt
den offenen Prozess und geht zu einem OffenGesendet-Zustand 4 über. Der
Empfang eines BGP-Transportverbindung-Offen-Versagt-Ereignisses
bleibt in dem aktiven Zustand 3. Alle anderen Ereignisse
gehen zu dem Leerlaufzustand 1 über.
-
Der
OffenGesendet-Zustand 4 ist der nächste Teil des Prozesses des
Einrichtens einer vollen BGP-Peersitzung. Der Empfang eines BGP-Startereignisses
bleibt in dem OffenGesendet-Zustand 4. Der Empfang eines
BGP-Stoppereignisses geht nach der Benachrichtigung und Löschung zu
dem Leerlaufzustand 1 über.
Der Empfang von BGP-Transportverbindung-Geschlossen-,
Verbindung-Offen-Versagt-,
oder Schwerwiegender-Fehler-Ereignissen geht zu dem aktiven Zustand 3 über. Der
Empfang von Halten- oder Aufrechterhalten-Zeitgeber-Abgelaufen-Ereignissen
bleibt in dem OffenGesendet-Zustand 4. Der Empfang des
Offen-Ereignisses
geht entweder zu dem OffenBestätigen-Zustand 5 über und
sendet Offen- und Aufrechterhalten-Mitteilungen und startet Aufrechterhalten-
und Halte-Zeitgeber, oder nach der Fehlerbenachrichtigung zu dem
Leerlaufzustand 1. Der Empfang anderer Ereignisse erzeugt
Benachrichtigungen und einen Übergang
zu dem Leerlaufzustand 1.
-
Der
OffenBestätigen-Zustand 5 setzt
das Verarbeiten der BGP-Peersitzung fort. Der Empfang von BGP-Start-,
Halte- Zeitgeber-Abgelaufen-,
Aufrechterhalten-Zeitgeber-Abgelaufen
oder Aktualisieren-Ereignissen bleibt in dem OffenBestätigt-Zustand 5,
mit den zusätzlichen
Aktionen, wie sie in dem Anhang 1 gezeigt sind. Der Empfang
von BGP-Stopp bewirkt Benachrichtigungs- und Löschaktionen, wie angezeigt,
und das Übergehen
zu dem Leerlaufzustand 1. Der Empfang von Halte-Zzeitgeber-Abgelaufen-Ereignissen
benachrichtigt den Halte-Zeitgeber und startet denselben neu, und
bleibt in dem OffenBestätigen-Zustand 5.
Der Empfang von Aufrechterhalten-Zeitgeber-Abgelaufen-Ereignissen
startet den Aufrechterhalten-Zeitgeber neu, sendet eine Aufrechterhalten-Mitteilung
an den BGP-Peer und bleibt in dem Offen-Bestätigen-Zustand 5.
Wenn ein Aufrechterhalten-Ereignis empfangen wird, wird der Halte-Zeitgeber
neu gestartet und geht zu einem Eingerichtet-Zustand 6 über.
-
Der
Eingerichtet-Zustand 6 stellt eine eingerichtete BGP-Peersitzung dar.
Der Empfang von BGP-Stopp- oder Benachrichtigungsereignissen bewirkt
Benachrichtigung, Löschung
und Übergang
zu dem Leerlaufzustand 1. Der Empfang anderer Ereignisse
bleibt in dem Eingerichtet-Zustand 6, mit der Verarbeitung,
wie sie angezeigt ist.
-
Dieser
Anhang erörtert
die Übergänge zwischen
Zuständen
in der BGP-FSM ansprechend
auf BGP-Ereignisse. Es folgt die Liste dieser Zustände und
Ereignisse, wenn der verhandelte Halte-Zeitwert ungleich Null ist.
-
BGP-Zustände:
-
- 1 – Leerlauf
- 2 – Verbunden
(nicht genutzt)
- 3 – Aktiv
- 4 – OffenGesendet
- 5 – OffenBestätigen
- 6 – Eingerichtet
-
BGP-Ereignisse:
-
- 1 – BGP
Start
- 2 – BGP
Stopp
- 3 – BGP
Transportverbindung offen
- 4 – BGP
Transportverbindung geschlossen
- 5 – BGP
Transportverbindung offen fehlgeschlagen
- 6 – BGP
Transport schwerwiegender Fehler
- 7 – Verbindung
wiederherstellen – Zeitgeber
abgelaufen (nicht genutzt)
- 8 – Halte-Zeitgeber
abgelaufen
- 9 – Aufrechterhalten – Zeitgeber
abgelaufen
- 10 – OFFEN-Mitteilung
empfangen
- 11 – AUFRECHTERHALTEN-Mitteilung
empfangen
- 12 – AKTUALISIEREN-Mitteilung
empfangen
- 13 – BENACHRICHTIGUNG-Mitteilung
empfangen
-
Die
folgende Tabelle beschreibt die Zustandsübergänge der BGP-FSM und der Aktionen,
die durch diese Übergänge ausgelöst werden. Leerlauf
(1)
-
Verbinden (2)
-
- Diesen Zustand niemals verwenden
-
Aktiv
(3)
Offen
gesendet (4)
Offen
Bestätigen
(5)
Eingerichtet
(6)
Offen Bestätigen (5)
Eingerichtet (6)
