Von: Gabriele Schrenk, Herbert Almus
Entgegen allen Unkenrufen aus dem Lager der IP-Freunde erfreut sich die ATM-Technik unter Netzbetreibern nach wie vor großer Beliebtheit. Als verbindungsorientierte Übertragungstechnologie ermöglicht sie es, Dienstgüte auch in sehr großen Netzen zu garantieren. Zuständig für die Ermittlung von denjenigen Pfaden durch ein ATM-Netz, welche jeweils die geforderten Qualitäten garantieren, ist das PNNI (Private Network Network Interface). Die Ermittlung der geeigneten Pfade setzt entsprechendes Wissen über die Netzwerkstruktur (Topologie, Ressourcen et cetera) voraus. Routing-Hierarchien gestatten es, Topologieinformationen zusammenzufassen und damit auch in komplexen Umgebungen effizient die Wegebestimmung durchzuführen.
Wie aber testet man das korrekte Routing in sehr großen Netzen? Wohl kaum ein Hersteller oder Netzbetreiber wird dafür Hunderte von ATM-Switches im Labor aufbauen - der finanzielle Aufwand wäre immens. Die Lösung liegt im Einsatz von Emulationswerkzeugen, die es erlauben, einem realen Switch ein komplexes Netzwerk "vorzugaukeln" und gleichzeitig sein Verhalten zu testen. Emulatoren erlauben es auch, das Verhalten von Switches bei Netzwerkfehlern oder Engpässen zu überprüfen. Halten sie den Belastungen stand? Oder zeigen sie Einbrüche, die im Realbetrieb unzufriedene Kunden und entsprechende Verluste und Kosten bedeuten würden?
Mithilfe der Software "Interemulator" des Messgeräteherstellers GN Nettest und eines "Omniswitch" von Alcatel haben wir die praktische Realisierbarkeit eines derartigen Tests erprobt, grundlegende Funktionstests am Switch vorgenommen und wertvolle Erfahrungen mit dem Einsatz eines Emulators gewonnen. Quasi nebenbei fielen dabei auch Erkenntnisse über die Leistungsfähigkeit des eingesetzten Switches an.
Bei dem Produkt von GN Nettest handelt es sich um einen kompletten PNNI-Netz-Emulator. Die Software läuft auf Sun-Rechnern unter dem Betriebssystem Solaris. Entsprechend seiner kleinen, aber äußerst feinen Zielgruppe ist der Preis des Produkts nichts für den Bastler von nebenan: Rund 135 000 Mark sind für die Software hinzublättern. Entsprechend hoch sind die Erwartungen an die Professionalität des Werkzeugs anzusetzen.
Mit dem Emulator, genauer gesagt mit dem Rechner, auf dem der Emulator läuft, wird ein realer Switch oder ein Teilnetz verbunden. Die Software selbst erzeugt dann Dutzende emulierter Netzknoten und Endgeräte, baut Verbindungen auf und streut Fehler ein. Der Emulator erlaubt es, mehrere PNNI-Hierarchien zu konfigurieren. Die Statistiken liefern Informationen über die Auslastung der Links zwischen den Switches, die Anzahl der aufgebauten Verbindungen, den Status der Verbindungen und über eventuell aufgetretene Fehler. Zusätzlich kann ein Monitor gestartet werden, der es ermöglicht, den Protokollaustausch aufzunehmen und anschließend zu analysieren. Dieser dekodiert auch das Signalisierungs- und das Routingprotokoll.
Der Switch in unserem Test besitzt zwei Backplanes. Damit ist er in der Lage, sowohl Zellen als auch Frames zu switchen. Er bietet Schnittstellen für den Einsatz verschiedener Netztechniken: Es stehen Interfaces für Ethernet, Fast Ethernet, Token Ring, FDDI, CDDI, ATM und WAN über Lichtwellenleiter oder Kupfer zur Verfügung. Darüber hinaus bietet der Omniswitch auch Unterstützung beim Routen von IP- und IPX-Daten. Für unseren Test benutzten wir indessen nur zwei STM-1-Schnittstellen mit Bandbreiten von 155 MBit/s.
Die Architektur des Geräts basiert auf der Store-and-Forward-Technik. Der Switch unterstützt zehn PNNI-Hierarchiestufen. Er ist in der Lage, in jeder Stufe die Aufgaben des "Peer Group Leader" zu übernehmen.
PNNI- und Routing-Hierarchien
Der PNNI-Standard besteht aus zwei Teilen - einem Routing-Protokoll und einem Signalisierungsprotokoll. Das Routingprotokoll verfährt nach dem so genannten Source-Routing-Prinzip. Das bedeutet: Der Netzknoten (ATM-Switch) am Eingang des Netzes, der den Verbindungsaufbauwunsch vom Endgerät erhält, berechnet den kompletten Weg durch das Netz und fügt den Weg den Verbindungsaufbaunachrichten (Setup Messages) an. Für diese Berechnung benötigt der Switch das Wissen über die gesamte Netztopologie. Damit die Datenbasen nicht all diese Informationen vorhalten müssen, ist es notwendig, eine Zusammenfassung vorzunehmen. Das wird in verschiedenen Abstrakionsstufen durchgeführt; man spricht in diesem Zusammenhang von "hierarchischem PNNI". Die Hierarchiebildung erfolgt durch Konfiguration des "Level Indicators" der Switchadresse. Switches mit gleichem Level Indicator gehören der gleichen Hierarchiestufe an.
Nebenstehendes Bild zeigt ein Beispielnetz mit insgesamt drei Hierarchiestufen. Auf der untersten Ebene sind die Switches physikalisch miteinander verbunden. Die beiden nächsthöheren Stufen bilden sich automatisch zwischen den Switches, die in der untersten Stufe mehr als einen Level Indicator besitzen. Diese Switches nennt man "Peer Group Leader" (PGL); sie haben unter anderem die Aufgabe, die Switches ihrer Gruppe in der nächsthöheren Hierarchiestufe zu vertreten. Switches, die ihre Gruppe in den höheren Hierarchiestufen vertreten sollen, müssen hier besonders leistungsstark sein. Sie haben die Aufgabe, die Topologie-Informationen sowohl in den höheren Schichten zu verteilen als auch in der Gruppe, für die sie zuständig sind. In unserem Beispiel heißt das, der Switch mit der abstrakten Adresse B.1.3 ist in allen drei Hie-rarchien für diese Verteilung zuständig.
Testkonfiguration
Beide Interfaces des Emulators waren an den Alcatel-Switch angeschlossen. An einem Port wurde ein ATM-Endsystem, am anderen Port ein ATM-Switch einschließlich Netzwerk emuliert. Der Interemulator verfügt bereits über einige vorkonfigurierte Testszenarien. Diese kann der Anwender auch an seine Bedürfnisse anpassen. Szenarien können auch komplett selbst entworfen werden.
Zur Fehleranalyse lässt sich auf jedem virtuellen (emulierten) Switch und Endgerät ein Protokollmonitor starten. Während der Test läuft, kann auch manuell eingegriffen werden. Ausfälle von virtuellen Switches oder Verbindungen können simuliert werden. Statistiken liefern detaillierte Informationen über Anzahl und Dauer der Verbindungen, über deren Wegewahl, Dienstgüte und mögliche Fehler.
Aufbau von Hierarchiestufen
Ziel des Tests war es, zu überprüfen, ob der Switch sechs Hierarchiestufen korrekt unterstützt. Der PNNI-Standard erlaubt zwar theoretisch bis zu zehn Hierarchiestufen. Experten gehen aber davon aus, dass in der Praxis auch für sehr große weltweite ATM-Netze vier bis sechs Stufen absolut ausreichen.
Der Alcatel-Switch war dazu mit zwei Ports an den Emulator angeschlossen. Auf einem Port simulierte letzterer ein virtuelles Endgerät, auf dem anderen ein hierarchisches PNNI-Netz mit virtuellem Endgerät. Ziel war es nun, zwischen den virtuellen Endgeräten des Emulators Verbindungen aufzubauen.
Auf dem Alcatel-Switch wurden sechs Hierarchiestufen konfiguriert. Die Einstellungen wurden so gewählt, dass der Switch auf jeder Stufe den Peer Group Leader darstellen sollte. Er hatte somit die Aufgabe, seine eigene Gruppe in der nächsthöheren Stufe zu repräsentieren. Für diese Aufgabe muss der Prüfling eine Verbindung zu allen anderen Switches auf der gleichen Stufe aufbauen. Die Anzahl der aufgebauten Verbindungen wurde in die Statistik aufgenommen.
Die Konfiguration des Switches gestaltete sich einfach - es waren nur insgesamt sieben Befehle einzugeben. Zuerst wies man dem Switch einen ATM-Adressbereich (Network Prefix) und einen "Level Indicator" auf der untersten Hie-rarchiestufe zu. Danach ließen sich die zusätzlichen Hierarchiestufen durch Konfiguration der anderen Level Indicators zügig eingeben. Abschließend musste mit zwei Befehlen die PNNI-Software neu gestartet werden. Um die Konfiguration einfach zu halten, haben wir auf dem Emulator pro Hierarchiestufe nur einen einzigen virtuellen Switch konfiguriert. Das reicht aus, um das Verhalten "unseres" Alcatel-Switches in diesem Test beurteilen zu können.
Die Switches waren auf physikalischer Ebene untereinander in einer Serienschaltung verbunden (siehe obiges Bild). Der Alcatel ist der grüne Switch mit der Bezeichnung SE5, die blauen Switches und Endgeräte werden vom Emulator simuliert. Die beiden simulierten Endgeräte tragen die Bezeichnungen TE0 und TE1.
Logisch stellte sich die Situation jedoch anders dar (siehe nachfolgendes Bild). In jeder Hierarchiestufe fungierte der Alcatel-Switch mit der Bezeichnung SE5 als Peer Group Leader. Auf der untersten Hierarchiestufe waren alle Switches jeweils allein in ihrer Gruppe. Auf der nächsthöheren Stufe tauschte der Alcatel-Switch mit seinem emulierten Nachbarn SE1 seine Adress- und Konfigurationsdaten über das "Hello"-Protokoll aus.
Zuvor musste er aber erst einmal mit Hilfe der Signalisierung einen so genannten SVCC-RCC (Signalled Virtual Channel Connection - Routing Control Channel) aufbauen. Über diesen dynamisch aufgebauten Kanal ließen sich dann die Routing-Informationen austauschen. Diesen Vorgang führten wir für alle Stufen durch. Es wurden also insgesamt jeweils zwischen dem Alcatel-Switch und einem virtuellen Switch fünf SVCC-RCCs aufgebaut, über die dann die Routing-Informationen übertragen wurden. Nachdem alle Hierarchien erfolgreich etabliert waren, konnten die Endgeräte Verbindungen zueinander aufbauen. Wir konfigurierten die beiden Endgeräte so, dass immer das Endgerät TE0 das Endgerät TE1 "anrief". Aufgabe des Alcatel-Switch war es nun, die richtige Route durch die Hierarchien zu berechnen und den Verbindungsaufbauwunsch an seinen virtuellen Nachbarswitch SE1 weiterzuleiten.
Longest-Path-Testszenario
Der längste Weg, den im PNNI eine "Setup"-Nachricht in einer Peer Group beschreiben kann, liegt bei 20 Knoten. In einer Peer Group können mehr als 20 Switches enthalten sein, aber die längste Strecke zwischen zwei Endgeräten darf nicht mehr als 20 Switches enthalten. Diese Einschränkung resultiert aus der Längenbeschränkung der Verbindungsaufbaunachricht in der Signalisierung. Um zu testen, ob der Alcatel-Switch eine Route durchs Netz berechnen kann, die den maximal erlaubten Weg nutzt, haben wir das folgende Szenario entwickelt: Die Switches 1 bis 20 sind alle in einer Reihe geschaltet. Lediglich der erste Switch ist real vorhanden; alle anderen sind "nur" emuliert. Das Endgerät TE0 ist physikalisch am Alcatel-Switch (SE1) angeschlossen und baut Verbindungen zum Endgerät TE1 auf. Der Alcatel-Switch muss nun den Weg durch die Peer Group finden und diesen Weg an die Setup-Nachricht anhängen.
Wir bauten nacheinander 1000 Verbindungen vom Endgerät TE0 nach TE1 auf und wieder ab. Die Gleichverteilung der fünf Meldungen (Message-Typen) zeigt, dass alle Verbindungen erfolgreich auf- und wieder abgebaut wurden. Die Call-Statistik dokumentiert ebenfalls den erfolgreichen Aufbau sämtlicher Verbindungen.
Routing nach QoS
Ziel des nächsten Tests war es, die verschiedenen Servicekategorien zu testen, die ATM zu bieten hat. Der Alcatel-Switch muss die Routing-Entscheidung für die Wegewahl des Verbindungsaufbaus von der geforderten Dienstgüte abhängig machen. Auch in diesem Szenario hatte der Alcatel-Switch die Aufgabe, Verbindungen, die vom Endgerät TE0 aufgebaut wurden, abhängig von der geforderten Dienstgüte durch den Backbone zu routen. Ziel der Anrufe war jeweils das emulierte Endgerät TE1. Die Testkonfiguration enthielt vier alternative Routen, die je nach gewählter Dienstgüte einzuschlagen waren.
Der Alcatel-Switch interpretierte und modifizierte die internen Beschreibungen (Setup-Parameter) der geforderten Dienstqualitäten bei diesem Test leider nicht korrekt und routete die Message über den falschen Switch.
Fazit
Der Interemulator besitzt eine große Vielzahl an Testmöglichkeiten und hat sich als Werkzeug zur Evaluierung der Funktion in großen PNNI-Netzen gut bewährt. Hervorzuheben sind insbesondere folgende Eigenschaften:
-Komplexe Netzstrukturen lassen sich zuverlässig emulieren;
-vorkonfigurierte Testbeispiele erleichtern den Einstieg; sie sind durch den Anwender anpassbar;
-Definition und Erstellung auch komplexer Tests mittels grafischer Benutzerschnittstelle möglich; Programmierkenntnisse sind dazu nicht erforderlich;
-Detailliertes Handbuch.
Wo Licht ist, ist auch Schatten. Trotz des an sich guten Handbuchs ist die Benutzerführung verbesserungsbedürftig.
-Für die Definition der Tests wäre ein Überblick über sämtliche notwendigen Konfigurationsschritte und deren Zusammenhang sehr hilfreich; sowohl Handbuch als auch Online-Hilfe sollten hier erweitert werden;
-Im Falle von Fehlkonfigurationen gibt die Dokumentation nur wenige Hinweise auf mögliche Fehlerquellen.
Alles in allem ist der Interemulator aber ein sehr mächtiges Werkzeug, das viele Testmöglichkeiten bietet, angefangen beim Netzdesign über ganze Netze. Sogar Funktionsumfang und Korrektheit der Implementierung einzelner realer Switches lässt sich überprüfen.
Auch der Alcatel Omniswitch machte insgesamt eine gute Figur. Die Hierarchiestufen waren problemlos zu konfigurieren, die Routen wurden von dem Switch immer ermittelt. Auch alle Kontrollverbindungen (Routing Control Channels) wurden korrekt und zuverlässig aufgebaut. Der Switch ist somit für den Aufbau hierarchischer ATM-Netze gut geeignet.
Der Switch eignet sich für flache Hierarchien auch mit maximal langen Wegen. Selbst beim "Long-Path-Test" führte er problemlos die Wegeberechnung durch, und auch beim 1000fach wiederholten Aufbau von Verbindungen zeigte er keine Schwächen.
Allerdings behandelt der Switch die Dienstqualitäten nicht korrekt. Dies führt dazu, dass Wege durch das Netz ermittelt und gewählt wurden, die den gestellten Anforderungen nicht genügten. Er wählte beispielsweise für eine Verbindung einen Weg, der die geforderte Zellverlustrate und maximale Laufzeit nicht gewährleistete. Der Hersteller teilt hierzu allerdings mit, dass das Problem erkannt ist und mit einem der nächsten Software-Releases behoben werden wird. (ch)
Zur Person
Herbert Almus
ist Leiter des European Advanced Network Test Center (EANTC) in Berlin, das unter anderem unabhängige Tests von Netzwerkequipment durchführt.
Gabriele Schrenk
ist als Vorstandsmitglied des EANTC für die Bereiche Testing und Consulting verantwortlich.