-
Der
Begriff „Netzwerktestinstrument" (hierin manchmal
als Testinstrumente oder Tester bezeichnet) umfasst eine große Bandbreite
von Testinstrumenten, einschließlich
Vorrichtungstestern, Protokollanalysatoren, Einhaltungsanalysatoren,
Leitungstestern usw... In der Vergangenheit waren derartige Netzwerktestinstrumente üblicherweise
allein stehende Einheiten, die an einem Testnetzwerk oder Testobjekt
vorprogrammierte Tests durchführten.
Ergebnisse werden an einem Monitor angezeigt, der üblicherweise
physisch an das Netzwerktestinstrument angeschlossen war, möglicherweise
jedoch in einer entfernten Position über eine Netzwerkverbindung.
Derartige Tests eignen sich dafür,
ein Verständnis
der Funktionsweise einer einzelnen Netzwerkkomponente, z.B. eines
Routers oder Schalters, oder eines Netzwerksegments, über das
Verkehr läuft,
zu gewinnen. Um jedoch mehrere Komponenten oder Segmente zu testen,
muss der Tester mit jeder Komponente und jedem Segment, für die bzw.
das ein Testen gewünscht
ist, verbunden sein.
-
Moderne
Netzwerke tendieren zu einer Architektur, die die Verbindung unterschiedlicher
Netzwerke durch die Verwendung von Gateways bzw. Netzübergängen und
dergleichen favorisiert. Ferner ändert
sich die Art des Verkehrs über
Netzwerke dahingehend, dass er einen einsatzkritischen Verkehr einer
hohen Bandbreite, z.B. VoIP (Voice over Internet Protocol) umfasst.
Um zu einem Verständnis
der Dienstgüte
(Qos – quality
of service) zu gelangen, die durch derartige moderne Netzwerke bereitgestellt
wird, sind oft Messungen von verschiedenen Positionen aus nötig. Es
reicht nicht aus, die Daten und Qos über eine einzelne Komponente
zu verifizieren; vielmehr muss man den Datenstrom von Anfang bis
Ende verfolgen.
-
Ein
weiterer Bereich, der von der Verwendung von Messungen und Tests,
die an verschiedenen Positionen durchgeführt werden, profitieren würde, ist
die Abwehr gegen Hacker. Üblicherweise
treiben Hacker von mehreren Stellen aus ihr Unwesen bzw. oder starten
von mehreren Stellen aus Angriffe. Netzwerktestinstrumente, die
sich auf eine einzige Position konzentrieren, sind eventuell nicht
in der Lage, einen Angriff auf der Basis eines Datenstroms durch
diese Position zu identifizieren, wenn jedoch mehrere Ströme zugänglich wären, werden
manche Angriffe leichter zu identifizieren.
-
Kein
einziges Netzwerktestinstrument ist in der Lage, all die notwendigen
Messungen durchzuführen, die
benötigt
werden, um entstehende Netzwerke und entstehenden Verkehr zu überwachen.
Demgemäß erstellen
Hersteller von Netzwerktestinstrumenten, z.B. AGILENT, derzeit verteilte
Netzwerktestumgebungen, bei denen eine Mehrzahl von Netzwerktestinstrumenten
Messungen von mehreren Positionen durchführen und Ergebnisse an eine
zentrale Stelle liefern. Die zentrale Stelle sammelt die Messungen
von einer Mehrzahl von Testinstrumenten ein und formatiert eine
Anzeige von Ergebnissen auf einem Monitor.
-
Es überrascht
nicht, dass die Konsolidierung von Messungen von mehreren Netzwerktestinstrumenten
zu einer Überlastung
mit Informationen führte,
bei der die Benutzer derartiger Systeme mit zu vielen Informationen
konfrontiert werden, was ihre Fähigkeit,
Probleme zu identifizieren, einschränkt. Fortschritte bei Informationsanzeigemethodologien,
z.B. hierarchische Anzeigen, die es erleichtern, von abstrahierten
Informationen zu den Rohdaten durchzudringen, milderten das Problem
ab. Siehe z.B. die gleichzeitig anhängige US-Patentanmeldung Serien-Nr.
10/225,181 mit dem Titel METHOD AND APPARATUS FOR DRILLING TO MEASUREMENT
DATA FROM COMMONLY DISPLAYED HETEROGENEOUS MEASUREMENT SOURCES.
Die '181-Anmeldung,
die am 22. August 2002 eingereicht wurde, ist an die Anmelderin
der vorliegenden Anmeldung über tragen
und ist durch Bezugnahme in das vorliegende Dokument aufgenommen.
-
Ein
weiteres Gebiet, das Entwerfer von Test- und Messinstrumenten zu
verbessern suchen, ist die Automatisierung von Reaktionen auf identifizierte
Probleme. Siehe z.B. US-Patentschrift
Nr. 5,621,892 mit dem Titel METHOD AND APPARATUS FOR MANAGING ALERTS
AND EVENTS IN A NETWORKED COMPUTER SYSTEM, die am 15. April 1997
erteilt wurde. Siehe außerdem
US-Patentanmeldung Serien-Nr. 09/835,619 mit dem Titel SYSTEM AND
METHOD FOR AUTOMATED PREDICTIVE AND SELFHEALING NETWORK ANALYSIS.
Die '619-Anmeldung,
die am 16. April 2001 eingereicht wurde, ist an die Anmelderin der
vorliegenden Anmeldung übertragen
und durch Bezugnahme in das vorliegende Dokument aufgenommen. Bei
bekannten reaktionsfähigen
Test- und Messsystemen besteht die typische Funktionsweise darin,
einen Alarm von einem einzelnen Instrument oder einer einzelnen
Komponente zu empfangen und entsprechend zu reagieren. Ein entsprechender
Fall ist die '892-Patentschrift,
bei der jede Warnung einem Dienst, z.B. einem Fax, Pager und einer
E-Mail, zugeordnet wird.
-
Es
wurde bisher keine bekannte Lösung
präsentiert,
die automatische Reaktionen auf Probleme liefert, die bei verteilten
Netzwerktestumgebungen identifiziert wurden. Die Erfinder der vorliegenden
Erfindung haben einen Bedarf an Systemen und Verfahren identifiziert,
die Daten von einer Mehrzahl von Netzwerktestinstrumenten zusammenstellen,
bestimmen, ob ein interessierendes Ereignis oder eine Sequenz von
interessierenden Ereignissen stattgefunden hat, und Korrekturmaßnahmen
implementieren, wenn ein derartiges Ereignis oder eine derartige
Sequenz von Ereignissen aufgetreten ist.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen
-
1 ein
Blockdiagramm eines Netzwerks;
-
2 ein
Blockdiagramm eines verteilten Test- und Messrahmens;
-
3 ein
Blockdiagramm einer Sammeltopographie;
-
4 ein
Blockdiagramm eines beispielhaften Testinstruments;
-
5 ein
Flussdiagramm eines Verfahrens gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
6 ein
Flussdiagramm eines Verfahrens gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
7 einen
Screenshot eines Agentenauslösermusterspezifikationsfensters
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
8 einen
Screenshot eines Agentenauslösermusterspezifikationsfensters
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
9 einen
Screenshot eines Agentenauslösermusterspezifikationsfensters
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
10 einen
Screenshot eines Agentenauslösermusterspezifikationsfensters
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung.
-
Im
Folgenden wird ausführlich
auf die vorliegende Erfindung Bezug genommen, wobei Beispiele derselben
in den beiliegenden Zeichnungen veranschaulicht sind, in denen sich
gleiche Bezugszeichen durchgehend auf gleiche Elemente beziehen.
-
Die
folgende ausführliche
Beschreibung präsentiert
Verfahren, die durch Routinen und symbolische Darstellungen von
Operationen von Datenbits in einem computerlesbaren Medium, zugeordneten
Prozessoren, spezifischen und Mehrzweck-Rechenvorrichtungen, die mit Netzwerkschnittstellenkarten
und dergleichen konfiguriert sind, verkörpert sein können. Hier
und im Allgemeinen wird als Routine eine Sequenz von Schritten oder
Handlungen angenommen, die zu einem gewünschten Ergebnis führen, und
als solches umfasst der Begriff Routine technische Begriffe wie „Programm", „Objekte", „Funktionen", „Teilroutinen" und „Prozeduren". Diese Beschreibungen
und Darstellungen sind die Mittel, die Fachleute verwenden, um die
Substanz ihrer Arbeit anderen Fachleuten effektiv zu vermitteln.
-
Die
Verfahren der vorliegenden Erfindung werden bezüglich einer Implementierung
an einem Protokollanalysator beschrieben, jedoch können die
hierin erwähnten
Verfahren auch an einem Mehrzweckcomputer oder einem anderen Netzwerkinstrument
arbeiten, der bzw. das durch eine in dem Computer gespeicherte Routine
selektiv aktiviert oder umkonfiguriert wird, und sie können mit
den notwendigen Signalverarbeitungsfähigkeiten eine Schnittstelle
bilden. Genauer gesagt sind die hierin präsentierten Verfahren inhärent nicht
auf eine bestimmte Vorrichtung bezogen – vielmehr können bei
Routinen gemäß den hierin
offenbarten Lehren verschiedene Vorrichtungen verwendet werden.
Maschinen, die ausgelegt sein können,
die Funktionen der vorliegenden Erfindung zu erfüllen, umfassen diejenigen,
die durch Firmen wie z.B. HEWLETT PACKARD, INC., AGILENT TECHNOLOGIES,
INC. UND TEKTRONIX, INC. sowie durch andere Hersteller von Netzwerktestausrüstung hergestellt
werden.
-
Bezüglich der
hierin beschriebenen Software werden Fachleute erkennen, dass es
eine Vielzahl von Plattformen und Sprachen zum Erzeugen von Software
zum Durchführen
der hierin umrissenen Prozeduren gibt. Das bevorzugte Ausführungsbeispiel
der vorliegenden Erfindung kann unter Verwen dung einer beliebigen Anzahl
von Variationen von C implementiert werden, Fachleute werden jedoch
auch erkennen, dass die Wahl der genauen Plattform und Sprache oft
durch die besonderen Merkmale des eingerichteten tatsächlichen
Systems vorgegeben wird, so dass etwas, für eine Art von System funktioniert,
bei einem anderen System eventuell nicht effizient ist. Ferner sollte
man verstehen, dass die in dieser Erfindung beschriebenen Routinen
und Berechnungen nicht darauf beschränkt sind, als Software an einem
Computer oder DSP (digital signal processor – digitaler Signalprozessor)
ausgeführt
zu werden, sondern auch in einem Hardwareprozessor implementiert
sein können.
Beispielsweise könnten
die Routinen und Berechnungen mit HDL (hardware design language – Hardwareentwurfssprache)
in einer ASIC implementiert werden.
-
1 ist
ein Blockdiagramm eines Netzwerks 100. Das Netzwerk 100 ist
als nicht einschränkendes Beispiel
einer Umgebung vorgesehen, bei der die Verfahren und Vorrichtungen
der vorliegenden Erfindung arbeiten können. Ein IP-Netzwerk 102 verbindet
eine Vielzahl von Vorrichtungen, einschließlich: Telekommunikationsvorrichtungen 104a und 104b;
Computer 106; Server 108; und Datenbank 110.
Die Telekommunikationsvorrichtungen 104a und 104b können VoIP-befähigte Vorrichtungen
(VoIP = Voice over Internet Protocol) oder gewöhnliche leitungsgeschaltete
Vorrichtungen sein, die durch Gateways bzw. Netzübergänge (nicht gezeigt) verbunden
sind. Der Server 108 kann beliebige einer Vielzahl von
Diensten liefern, einschließlich
z.B.: FTP, HTTP, SMTP etc.
-
Es
können
eine Vielzahl von Testinstrumenten eingesetzt werden, um die verschiedenen
Verbindungen und die Gesundheit des Netzwerks zu überwachen.
Die Testinstrumente umfassen üblicherweise
Protokollanalysatoren und RMON-Vorrichtungen
(RMON = remote monitoring, Fernüberwachung).
Beispielsweise können
Protokollanalysatoren von AGILENT verschiedene Arten von Einzelsegmentmessungen
durchführen, einschließlich, aber
nicht ausschließlich,
Telefonie netzwerkanalysatoren (TNAs), wesentliche Protokollbestandteile,
RTP-Statistik usw. Eine TNA-Messung, die auf einem Protokollanalysator 112a und 112b läuft, liefert
eine Diagnostik von VoIP-Verbindungen, z.B. derjenigen, die den
Telekommunikationsvorrichtungen 104a und 104b zugeordnet
sind. Die Protokollanalysatoren 114a und 114b liefern
eine allgemeine Diagnostik des Verkehrs über Netzwerkverbindungen, z.B.
die Verbindungen zwischen dem Computer 106, dem Server 108 und
dem Datenbankserver 110. Eine RMON-Vorrichtung 116 arbeitet gemäß einer
Standardüberwachungsspezifikation,
die verschiedene Netzwerküberwachungsvorrichtungen
und Konsolensysteme befähigt,
Netzwerküberwachungsdaten
auszutauschen. Allgemein stattet RMON Netzwerkadministratoren mit
mehr Freiheit beim Auswählen
von Netzwerküberwachungssonden
und Konsolen mit Merkmalen, die ihre bestimmten Vernetzungserfordernisse
erfüllen,
aus.
-
2 ist
ein Blockdiagramm eines verteilten Test- und Messrahmens 200,
bei dem zumindest ein zentraler Server 206 mit einer Reihe
von Testinstrumenten 202n (wobei 202a, 202b und 202c gezeigt
sind) zum Testen eines zu testenden Netzwerks 102 verbunden
ist. Netzwerktestinstrumente, einschließlich der Protokollanalysatoren
von AGILENT und der meisten RMON-Vorrichtungen, können konfiguriert
sein, um mit einer zentralen Konsole, z.B, dem PC 106,
zu interagieren. Ein Netzwerk 204 verbindet den zumindest
einen zentralen Server 206 mit dem Testinstrument 202n.
Die Beziehung zwischen dem zumindest einen zentralen Server 206 und
den Testinstrumenten 202n ist eine von Viele-Zu-Vielen.
Mit anderen Worten kann eine Mehrzahl der zentralen Server 206 mit
einer Mehrzahl der Testinstrumente 202n eine Schnittstelle
bilden. Auch erwähnenswert
ist, dass jedes Testinstrument 202n mit mehreren Verbindungen
mit dem zu testenden Netzwerk 102 konfiguriert sein kann.
Wie nachfolgend ausführlicher
erläutert
wird, können
die meisten Testinstrumente mit einer Mehrzahl von Schnittstellen
ausgestattet sein, um beispielsweise mit beiden Seiten eines Netzübergangs verbunden
zu sein.
-
3 ist
ein Blockdiagramm einer Sammlungstopographie 200, die sich
auf die interne Konfiguration des zentralen Servers 206 konzentriert.
Segmente des Netzwerks 102 sind z.B. durch Schalter 302n und
Router 304 miteinander verbunden. Allgemein ist es wünschenswert,
dass die Testinstrumente 202n Verbindungsvorrichtungen
wie z.B. Schaltern 302n, Routern 304 und Netzübergängen (nicht
gezeigt) zugeordnet sind. Demgemäß ist das
Testinstrument 202a, z.B. ein Agilent DNA MX, über einen
ATM und Gigabit-Ethernet-Verbindungen
mit dem Schalter 302a, der ein ATM-Schalter sein kann,
verbunden. Die Testinstrumente 202b und 202c,
z.B. Agilent DNA MXs, sind z.B. über
OC12-Verbindungen mit Routern 304b und 304c verbunden. Schließlich ist
das Testinstrument 202d, z.B. ein Agilent DNA MX, über ATM
und 10/100-Ethernet-Verbindungen mit dem Schalter 302b,
der ein ATM-Schalter sein kann, verbunden.
-
Jedes
der Testinstrumente 202n ist üblicherweise über ein
Netzwerk 102 mit einer zentralen Konsole 206 verbunden.
Es ist eventuell vorzuziehen, einzelne Direktverbindungen oder sogar
ein getrenntes Zwischennetzwerk bereitzustellen, das den Testinstrumenten 202n und
dem zumindest einen zentralen Server 206 gewidmet ist.
Der zentrale Server 206 ist mit Software, z.B. dem Agilent
Network Troubleshooting Center (Netzwerkfehlersuchzentrum von Agilent)
konfiguriert, die Test- und Messergebnisse von den Testinstrumenten 202n empfängt und
anzeigt. Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung ist der zentrale Server 206 konfiguriert,
um Test- und Messergebnisse von den Testinstrumenten 202n zu
empfangen, die Ergebnisse zusammenzustellen, die Ergebnisse mit
einem Auslöserzustand
zu vergleichen und eine Reaktion auszulösen, wenn die Auslöserbedingung
vorliegt. Bei dem vielleicht bevorzugten Ausführungsbeispiel, und wie hierin
erörtert,
ist der zentrale Server mit einer Zustandsmaschine ausgestattet,
um die vorliegende Erfindung zu implementieren. Es sei erwähnt, dass
auch andere Softwarekonstrukte verwendet werden können, um
die vorliegende Erfindung zu implementieren, wobei die Zustandsmaschine
lediglich ein Beispiel ist, das Fachleuten allgemein einleuchten
wird.
-
Gemäß zumindest
einem Ausführungsbeispiel
weist die Software zumindest eine Anwendungsschicht 208 und
eine Datensammelverwaltungsschicht 214 auf. Die Anwendungsschicht 208 umfasst
Präsentationskomponenten 210,
einschließlich
Berichterstattungs- und Graphikroutinen zusammen mit einer Auslösezustandsmaschine 212.
Da die Präsentationskomponenten 210 durchschnittlichen
Fachleuten allgemein bekannt sind, wird auf eine weitere Erläuterung
derselben allgemein verzichtet. Die Auslösezustandsmaschine 212 verwaltet
Auslöser,
die auf der Basis des Vorliegens eines verteilten Ereignisses oder
einer Sequenz von Ereignissen, wie es bzw. sie durch die Testinstrumente 202n erfasst
wird bzw. werden, aktiviert werden. Ein geeignetes Ausführungsbeispiel
einer Auslösezustandsmaschine 212 wird
hierin nachfolgend erläutert.
-
Die
Datensammelschicht 214 umfasst einen Datensammler 216;
eine Datenspeicherung 218; Anwendungsprogrammierungsschnittstellen
(APIs – application
programming interfaces) 220 für eine Kommunikation mit den
Testinstrumenten 202n und eine Netztransportschicht 222 (z.B.
HTTP). Die Datensammelschicht 214 ist dafür verantwortlich,
mit den verteilten Testinstrumenten zu interagieren und ihre Daten
zu sammeln. Die Datenspeicherung 218 ist dafür verantwortlich,
die Daten von der Datensammelschicht 214 zu nehmen und
sie in eine Form umzuwandeln, die in einer Datenbank (nicht gezeigt)
weiter bestehen kann. Die APIs 220 ermöglichen eine sichere Fernsteuerung
der Netzwerktestinstrumente 202n. Bei dem vielleicht bevorzugten
Ausführungsbeispiel
sind die APIs 220 unter Verwendung der XML-APIs implementiert,
die in der gleichzeitig anhängigen
US-Patentanmeldung 10/224,556 beschrieben sind, die den Titel SYSTEM
CONTROLLING TEST/MEASUREMENT DEVICES ON A NETWORK USING MARKUP LANGUAGE
DOCUMENTS AND METHODS THEREOF trägt,
am 21. August 2002 eingereicht wurde und an die Anmelderin der vorliegenden
Anmeldung übertragen
wurde. Die US-Patentanmeldung 10/224,556 ist durch Bezugnahme in
das vorliegende Dokument aufgenommen.
-
4 ist
ein Blockdiagramm eines beispielhaften Testinstruments 400.
Das Testinstrument 400, in 4 gezeigt,
beruht auf dem Netzwerkanalysator von Agilent, Fachleute werden
jedoch erkennen, dass jegliche Testinstrumentarchitektur, die für eine Aufnahme
in ein System gemäß der vorliegenden
Erfindung geeignet ist, verwendet werden kann. Das Testinstrument
ist konfiguriert, um mit einer Mehrzahl von Verbindungen in dem
zu testenden Netzwerk 102 eine Schnittstelle zu bilden.
Intern kann man sich das Testinstrument 400 zu Zwecken
der Erläuterung
der vorliegenden Erfindung so vorstellen, dass es einen Servlet-Behälter 404 umfasst,
der über
ein internes Netzwerk 408 (z.B. ein IP-Netzwerk) mit einer Mehrzahl von logischen
Testinstrumentschnittstellen 406n verbunden ist.
-
Der
Servlet-Behälter 404 umfasst
allgemein ein Sammelagentenkommunikationsservlet 410 und
einen HTTP-Server 412. Der HTTP-Server 412 kommuniziert
mit der Datensammelverwaltungsschicht 214 in dem zentralen
Server 206 unter Verwendung von z.B. XML-Dokumenten, wie
sie in der gleichzeitig anhängigen
US-Patentanmeldung 10/224,556 beschrieben sind. Das Servlet 404 kann
von seinen entsprechenden logischen Testinstrumentschnittstellen 406n physisch
getrennt sein, muss aber nicht.
-
Jede
logische Testinstrumentschnittstelle 406n umfasst allgemein
Netzwerktransport-APIs; XML-APIs; Testinstrumentanwendungen; und
eine Erfassungshardware, z.B. Line Interface Modules (LIMs) von
Agilent. In manchen Fällen
umfasst eine logische Testinstrumentschnittstelle 406n ein
herkömmliches Netzwerktestinstrument,
das konfiguriert ist, um mit dem Servlet 404 zu kommunizieren.
Eine derartige Konfiguration wird in der gleichzeitig anhängigen US-Patentanmeldung
10/224,556 ausführlicher
erläutert.
-
5 ist
ein Flussdiagramm eines Verfahrens gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Das Verfahren beginnt bei Schritt 502 mit
der Erzeugung eines Tests. Im Allgemeinen umfasst ein Test einen
Satz einer oder mehrerer Messungen von einem oder mehreren Testinstrumenten.
In Verbindung damit wird auf der Basis der Messungen ein Auslöserereignis
definiert. Beispielsweise kann ein Test erstellt werden, der eine
Identifizierung eines traditionellen SYN-Dienstverweigerungsangriffs
ermöglicht. Bei
einem derartigen Angriff wird eine ungewöhnlich hohe Anzahl von SYN*-Anforderungen
an eine bestimmte IP-Adresse gerichtet. Ferner kommen die SYN*-Anforderungen üblicherweise
von mehreren Netzwerksegmenten. Somit wird ein geeigneter Test ausgelöst, wenn
die durch mehrere Testinstrumente erfasste zusammengefasste Anzahl
von SYN*-Anforderungen, die auf eine bestimmte IP-Adresse gerichtet
sind, eine bestimmte Schwelle übersteigt.
-
Als
Nächstes
werden die bei dem Test zu verwendenden Testinstrumente bei Schritt 504 ausgewählt. Diese
können
so viele oder so wenige sein, wie der Benutzer wünscht. Bei Schritt 506 werden
die physischen Schnittstellen des ausgewählten Testinstruments gemäß ihrer
Betriebssoftware konfiguriert. Bei Schritt 508 werden die
gewünschten
Messungen ausgewählt
und anschließend
bei Schritt 510 konfiguriert, wiederum gemäß der Betriebssoftware
an jedem bestimmten Testinstrument.
-
Bei
Schritt 512 wird ein Auslöserqualifikationsmuster festgelegt.
Ein Auslöserqualifikationsmuster
wird verwendet, um das Testinstrument mit Messungen anzuweisen,
die an den zugewiesenen zentralen Server weiterzugeben sind. Dies
ermöglicht
es dem Benutzer, den Messverkehr lediglich auf die interessierenden Messungen
zu reduzieren. Unter Fortsetzung des SYN*-Angriffstests könnte der
Benutzer festlegen, dass lediglich SYN*, die auf eine festgelegte
IP-Adresse oder eine Bandbreite von Adressen gerichtet sind, in
Betracht gezogen werden sollen. In mancherlei Hinsicht fungiert
das Auslöserqualifikationsmuster
als Filter.
-
Bei
Schritt 514 wird das Auslöserqualifikationsmuster an
Agenten verteilt, die bei Schritt 504 ausgewählt werden.
Dies kann unter Verwendung der XML-APIs 220 durchgeführt werden,
wie in der gleichzeitig anhängigen
US-Patentanmeldung
10/224,556 beschrieben.
-
Bei
Schritt 516 wird eine Aktion bezüglich einer Ausführung festgelegt,
wenn der zentrale Server eine Auslöserbedingung identifiziert.
Die Aktion kann vorzugsweise in Form einer ausführbaren, Stapel-, Skript- oder
Makrodatei vorliegen. Beispielsweise könnte die Aktion ein Öffnen einer
Instanz eines Netzwerkanalysators auf einem Bildschirm und ein Durchdringen
zu den relevanten Messungen an einem identifizierten Testinstrument
umfassen. Als weiteres Beispiel könnte die Aktion das Einstellen
eines zweiten Tests mit einem zweiten Auslöser und einer anschließenden Aktion
umfassen. Bei einem weiteren Beispiel könnte die Aktion ein Speichern
von Test- und Messergebnissen in der Datenspeicherung 218 (siehe 3) über einen
vordefinierten (oder offenen) Zeitraum umfassen. Ferner kann die
Aktion ein Senden einer SNMP-Falle an ein OSS-System umfassen. Man
muss erkennen, dass eine Vielzahl möglicher Aktionen existiert
und dass eine beliebige Kombination oder beliebige Kombinationen
von Aktionen ansprechend auf die Erfassung einer Auslöserbedingung
durchgeführt
werden kann bzw. können.
Das Spektrum möglicher
Aktionen liegt größtenteils
außerhalb des
Schutzumfangs der vorliegenden Erfindung, so dass eine weitere Erläuterung
desselben eingeschränkt ist.
-
Bei
Schritt 518 wird der Test begonnen. Danach, bei Schritt 520,
werden die Daten, die durch die bei Schritt 504 ausgewählten Testinstrumente
weitergegeben werden, gesammelt und zusammengestellt, z.B. unter
Verwendung der Einrichtungen des Datensammlers 216 und
der Datenspeicherung 218 des zentralen Servers 206 (siehe 2).
In der einfachsten Form umfasst die Zusammenstellung ein Hinzuaddieren
eines Werts, der den Daten zugeordnet ist, z.B. der Anzahl von empfangenen
SYN*-Anforderungen. Als Nächstes werden
die Daten bei Schritt 522 analysiert, um zu bestimmen,
ob eine Auslöserbedingung
vorliegt. In der einfachsten Form umfasst eine derartige Analyse
ein Vergleichen des bei Schritt 520 berechneten kombinierten Werts
mit einem Schwellwert. Wenn eine Auslöserbedingung vorliegt, wenn
z.B. die Anzahl von gefilterten SYN*-Anforderungen die Schwelle übersteigt,
wird die bei Schritt 516 festgelegte Aktion vorgenommen.
-
6 ist
ein Flussdiagramm eines Verfahrens gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Im Einzelnen ist 6 ein Flussdiagramm
der Funktionsweise der Auslösezustandsmaschine 212 in
dem zentralen Server 206, wie bei 2 zu sehen
ist, gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Das Verfahren beginnt bei Schritt 602 mit
der Initialisierung der Zustandsmaschine. Als Nächstes wird die Zustandsmaschine
bei Schritt 604 zurückgesetzt.
Bei Schritt 606 werden die durch die Zustandsmaschine verwendeten
nötigen
Teilprozesse bzw. Threads eingerichtet. Im Allgemeinen ist ein Thread
jedem Auslöser
gewidmet, der durch den zentralen Server 206 verwaltet
wird. Wie man weiß,
ist Threading eine Form einer Parallelverarbeitung, die die Ausführung mehrerer
Prozesse auf scheinbar gleichzeitige Weise ermöglicht. Gemäß dem vorliegenden Ausführungsbeispiel
ermöglicht
die Verwendung von Threads durch die Zustandsmaschine, dass mehrere
gesonderte Auslöser
definiert und die denselben gewidmeten Prozesse parallel durchgeführt werden.
Dadurch können
mehrere Tests durch den zentralen Server verwaltet werden, wobei
jeder seine eigene Auslöserdefinition
und -aktion aufweist.
-
Bei
Schritt 608 wird die Eingabe von jedem Testinstrument ausgewertet,
um eine Anwendbarkeit auf den aktuellen Test zu gewährleisten.
Beispielsweise werden die Anfangsblöcke von Paketen bezüglich des richtigen
Inhalts geprüft.
Als Nächstes
wird die Eingabe, die für
relevant erachtet wird, bei Schritt 610 verarbeitet und
mit existierenden Daten kombiniert, z.B. wird eine Paketzählung erhöht. Bei
Schritt 612 wird ein Zeitfenster ausgewertet. Bei vielen
Tests ist die Zeit, innerhalb derer getestete Aktionen erfolgen,
wichtig. Bei dem vorherigen Beispiel des Analysierens der empfangenen
SYN*-Anforderungen ist der Zeitraum, innerhalb dessen die Anforderungen
empfangen werden, beim Identifizieren eines Dienstverweigerungsangriffs
nützlich. Dementsprechend
können
Zeitfenster definiert und verwendet werden, um etwaige anwendbare
Zähler
zurückzusetzen.
Wenn im optionalen Fall ein Zeitfenster ohne eine Zustandsänderung überschritten
wird, kann das Verfahren zu Schritt 604 zurückkehren,
und die Zustandsmaschine wird zurückgesetzt. Der Zeitraum kann auch
als rollend definiert sein, wobei Zählungen gelöscht werden, während sich
das Zeitfenster z.B. an den Zählwerten
vorbeibewegt, die lediglich diejenigen SYN*-Anforderungen reflektieren,
die in der letzten Stunde empfangen wurden.
-
Bei
Schritt 614 wird der Zustand der Zustandsmaschine ausgewertet
und verändert,
wenn die Zustandsänderungskriterien
erfüllt
sind. Im Allgemeinen ändert
sich der Zustand auf die Identifizierung eines Auslöserereignisses
hin. Beispielsweise erreicht der Paketzählwert eine Schwelle in dem
definierten Zeitfenster. Als Nächstes
wird bei Schritt 616 eine Prüfung dahingehend durchgeführt, ob
sich der Zustand geändert
hat. Wenn sich der Zustand geändert
hat, wird die festgelegte Aktion bei Schritt 618 ausgeführt. Danach
kehrt das Verfahren zu Schritt 604 zurück, und die Zustandsmaschine
wird zurückgesetzt.
Wenn der Zustand nicht verändert
ist, kehrt das Verfahren zur weiteren Auswertung zu Schritt 608 zurück. Fachleute
werden erkennen, dass die vorstehende Beschreibung einer Zustandsmaschine
nicht exakt ist und vereinfacht wurde, um eine lineare Erläuterung
zu ermöglichen.
Bei den vielleicht bevorzugten Ausführungsbeispielen werden die
Auswertung des Zustands und das Auslösen (Schritte 614 und 616)
parallel zur Datenaufnahme und -analyse (Schritte 608 mit 612)
durchgeführt.
-
Tabelle
1 enthält
einen Pseudocode, der die Funktionsweise einer Auslösezustandsmaschine
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung beschreibt. Es ist wichtig, zu beachten, dass
der Pseudocode im Kontext eines einzigen Betriebs-Threads liegt;
es kann viele Threads in der Auslösezustandsmaschine geben, um
mehreren Tests, die durch den zentralen Server verwaltet werden,
zu entsprechen.
-
-
-
7 bis 9 sind
Screenshots eines Agentenauslösermusterspezifikationsfensters 700 gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Die in 7 bis 8 gezeigten
Fenster ermöglichen
die Erzeugung eines Filters bei einem Netzwerkanalysator von AGILENT,
das bewirkt, dass das Testinstrument interessierende Posten an einen
zentralen Server weiterleitet. Fachleute werden erkennen, dass die
in 7 bis 8 gezeigten Fenster lediglich
eine von vielen Möglichkeiten
sind, wie derartige Filter eingerichtet und konfiguriert sein können, wobei
die gezeigten Bildschirme lediglich dargelegt werden, um eine vollständige Offenbarung
zu liefern. Ferner können
bei Systemen und Verfahren gemäß der vorliegenden
Erfindung auch andere Testinstrumente als der Netzwerkanalysator
von AGILENT verwendet werden. Allgemein kann jeglicher Protokollanalysator
verwendet werden, solange er konfiguriert werden kann (vorzugsweise
aus der Ferne), interessierende Posten an einen zentralen Server
zu liefern, z.B. einschließlich
eines weiteren Protokollanalysators.
-
Bei
manchen Testinstrumenten können
Benutzer den Registrierungszeitraum steuern, indem sie Start- und
Stoppauslöserereignisse
definieren. Es können
eine beliebige Anzahl von Auslösern
definiert werden. Beispiele von Auslösern umfassen: Datum und Uhrzeit;
Vorliegen einer festgelegten Meldung oder eines festgelegten Parameterwerts
in einer Meldung; Ereignis (z.B. CRC-Fehler); seit dem Startauslöser verstrichener
Zeitraum; wiederholbare Start- und Stoppauslöser. Ferner ermöglichen
es manche Testinstrumente dem Benutzer, Filter zu definieren, die
die Art und Menge von registrierten Daten steuern (und gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung, von Daten, die an zumindest einen zentralen
Server kommuniziert werden). Allgemein erfolgt eine Annahme oder
Zurückweisung
von Meldungen durch Filter auf der Basis von Werten in den Meldungen
(z.B. Meldungsarten oder Parameter in Meldungen). Unter Verwendung
einer UND/ODER-Verknüpfung
können
Filter logisch kombiniert werden.
-
Bei 7 werden
die Allgemeinen Attribute des Filters in einer ersten Markierung 702 des
Fensters 700 konfiguriert. In diesem Fall wird dem Filter
der Titel „SYN-Anforderungen" gegeben. Ferner
wird eine „Erfassungs"-Aktion für Pakete ausgewählt, die
die dem Filter zugeordneten Kriterien erfüllen. Schließlich wird das
Filter auf „EIN" geschaltet.
-
Bei 8 werden
die Rahmenattribute des Filters in einer zweiten Markierung 704 des
Fensters 700 konfiguriert. Bis zu 16 Ethernet-Filter sind
ebenfalls erhältlich.
Die Filter werden einer logischen „ODER"-Verknüpfung unterzogen und können bezüglich der
IP-Adresse, eines Rahmenattributs wie z.B. gute Rahmen, schlechte „FCS"-Rahmen (FCS = Frame
Check Sequence, Rahmenprüfsequenz),
Runts, Jabber und Dribble, filtern. Eine schlechte FCS kann eine
beliebige Anzahl von Dingen sein, bezieht sich jedoch allgemein
auf eine Anzahl von Rahmen gültiger
Größen mit
FCS-Fehlern, jedoch ohne Rahmenbildungsfehler. Ein Runt ist ein Rahmen,
der kleiner ist als die minimale IEEE802.3-Rahmengröße (64 Bytes
für Ethernet)
und eine schlechte CRC aufweist. Ein Jabber ist ein Rahmen, der
länger
ist als 1518 Oktette (ausschließlich Rahmenbildungsbits, jedoch
einschließlich
FCS-Oktette), der nicht mit einer geraden Anzahl von Oktetten endet
(Ausrichtungsfehler) oder einen Schlechte-FCS-Fehler aufweist. Ein
Dribblebitfehler zeigt an, dass ein Rahmen etwas zu lang ist. Bei
dem bei 8 gezeigten Beispiel kann der
Benutzer ein Muster spezifizieren, nach dem in den tatsächlichen
Daten in dem Rahmen zu suchen ist. Dies umfasst üblicherweise das Einstellen
eines Datenfeldes in dem Anfangsblock eines Pakets in dem Rahmen.
-
9 zeigt
die Protokolle, die in einer dritten Markierung 706 in
dem Fenster 700 identifiziert werden. In diesem Fall wird
http-Verkehr über
IP ausgewählt.
-
10 ist
ein Screenshot eines Serverauslösespezifikationsfensters 1000 und
einer Auslöseraktionsspezifikation
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Das in 10 gezeigte
Fenster ist ein Beispiel einer Software, die die Konfiguration eines
zentralen Servers gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung ermöglicht.
Allgemein arbeitet der zentrale Server als Zustandsmaschine, derart,
dass jegliches Ereignis oder jegliche Folge von Ereignissen, die
zum Ändern des
Zustands der Zustandsmaschine verwendet werden könnte, zum Auslösen verwendet
werden könnte.
Das in 10 gezeigte Fenster ist lediglich
ein Beispiel einer Sammlung von Auslösekriterien, die gemäß einem bevorzugten
Ausführungsbeispiel
der vorliegenden Erfindung verwendet werden können.
-
Bei
dem in 10 gezeigten Beispiel beruht
ein Auslöser
auf einer Anzahl von Auftretensfällen
eines bestimmten definierten Musters. Weitere Kriterien werden bereitgestellt,
um die Auftretensfälle
zu qualifizieren. Beispielsweise könnte das Vorliegen des Musters über einen
gewissen Prozentsatz (in diesem Fall 75 %) der Agenten hinweg erforderlich
sein. Wie oben erörtert
wurde, kann ferner ein Zeitfenster spezifiziert werden (in diesem
Fall 10 Minuten).
-
Die
Rahmenanfangsblockdaten können
ebenfalls qualifiziert werden.
-
Bei
dem gezeigten Beispiel kann jedes der Dateneingabefelder jegliche
Werte annehmen, die der Systementwerfer als notwendig erachtet.
Beispielsweise kann die Anzahl von Auftretensfällen ein offenendiger Wert
oder begrenzt sein. Das Musterdefinitions-Drop-Down-Menü könnte z.B.
folgende Einträge
umfassen: zweckangepasst; IP; HTTP:FTP; Telnet usw. Das Pull-Down
nach dem Wort „von", das die Anzahl
oder den Prozentsatz von Agenten angibt, von denen der Auftretensfall
empfangen wird, könnte
dazu programmiert sein, eine Vielzahl von Prozentsätzen oder
einen feststehenden Wert (z.B. bei 10 Agenten) aufzulisten. Selbstverständlich würde das
Zeitfenster die Eingabe eines beliebigen nützlichen Zeitwerts ermöglichen.
Das Rahmenanfangsblockfilter könnte
auf „gleich" (gezeigt) oder „nicht
gleich" eingestellt
werden. Das Muster in dem Musterzweckanpassungsfeld wird auf die übliche Weise
eingestellt.
-
In
einem Pull-Down-Kästchen
ist eine Aktion für
das beschriebene Auslöserereignis
definiert. Bei dem gezeigten Beispiel besteht die Aktion darin,
eine Fernfehlersuche zu beginnen. Allgemein bezieht sich dies auf das
automatische Öffnen
von Fenstern, die definierten Netzwerktestagenten zugeordnet sind.
Andere Beispiele möglicher
Auslöseraktionen
umfassen: Senden einer Meldung an eine vordefinierte Stelle über einen
vordefinierten Pfad (z.B. Fax, E-Mail oder Pager); Einstellen eines
zweiten Auslösers;
Anhalten oder Starten eines Tests und der Ausführung einer Programm-, einer
Makro- oder einer Stapeldatei. Die Einschränkungen, denen die möglichen
Aktionen unterliegen, bestehen in den Grenzen der Kreativität des Entwerfers
und der Beschränkung
der Hardware und Software.
-
Obwohl
sich die beschriebenen Ausführungsbeispiele
der vorliegenden Erfindung auf die Verwendung von Auslösern zum
Erfassen eines Dienstverweigerungsangriffs konzentrieren, werden
Fachleute erkennen, dass eine fast unendliche Vielzahl von Auslösern möglich ist.
Anhand eines weiteren Beispiels besteht bei einem Einsatz eines
großen,
Multisegment-VoIP ein Erfordernis, die Qualität der Anrufe zu gewährleisten.
Allgemein wird ein derartiger VoIP-Einsatz in mehrere Regionen unterteilt.
Für jede
Region kann ein Test erstellt werden, wobei jede Region mehrere
TNA-Messungen aufweist. Beispielsweise kann ein Test, der die „westliche
Region" abdeckt,
eine TNA in San Francisco, San José, Oakland und Sacramento
aufweisen. Somit werden das VoIP-Netzwerk
und die Anrufe in demselben über
mehrere Netzwerksegmente in ganz Kalifornien überwacht. Der Test selbst kann
derart konfiguriert sein, dass für
jegliche TNA in dem Test, falls die MOS (Mean Objective Score – mittlere
objektive Punktzahl, ein Maß der
Anrufqualität)
unter eine gewisse Schwelle abfällt,
oder das Jitter größer ist
als eine Schwelle oder die Anzahl verlorener Pakete eine Schwelle überschreitet, ein
Auslöserereignis
erzeugt und eine Aktion eingeleitet wird. Eine derartige Aktion
könnte
ein Hinunterdringen zu der TNA aus der Ferne umfassen, die den Schlechte-VoIP-Zustand
erfasst, oder einen SNMP-Alarm, der an OSS gesendet wird, usw. Diese
Art von Test kann den Fehlersucher umfassen, um die Übergangsstelle
und den Übergangspunkt
von Gute-Zu-Schlechte-VoIP-Telefonanrufen schneller festzustellen.
-
Obwohl
ein Ausführungsbeispiel
der vorliegenden Erfindung gezeigt und beschrieben wurde, werden Fachleute
erkennen, dass an diesen Ausführungsbeispielen Änderungen
vorgenommen werden können,
ohne von den Prinzipien und der Wesensart der Erfindung, deren Schutzumfang
in den Ansprüchen
und deren Äquivalenten
definiert ist, abzuweichen.
