Von: GABRIELE SCHRENK, CHRISTOPH LANGE
Die Protokollfamilie Multiprotocol Label Switching (MPLS) bietet Mechanismen für die Laststeuerung, zur Unterstützung von Service Level Agreements (SLA) und zum Aufbau von Virtuellen Privaten Netzen (VPN) auf Basis des Internet Protocol (IP). Aufgrund dieser Funktionsvielfalt erfreut sich MPLS bei Service Providern immer größerer Beliebtheit.
In NetworkWorld 06/01 (22. März 2001) hatten wir mit einem Test von MPLS-Routern begonnen, die aus ATM-Switches hervorgegangen sind und zur Signalisierung das Label Distribution Protocol (LDP) beziehungsweise Constraint Based Routing LDP (CR-LDP) benutzen. Diese Geräte sprechen nach wie vor pures ATM, verlassen jedoch den ATM-Bereich und vereinbaren mit anderen MPLS-Routern auf der Grundlage von Routing-Protokollen wie OSPF und RIP, welchen Weg die Datenpakete durch das ATM-Netz gehen.
MPLS ist nicht gleich MPLS
Nun führen wir die Testreihe mit MPLS-Routern fort, die auf einer gänzlich anderen Hard- und Softwarebasis vergleichbare Leistungsmerkmale bieten. Dabei handelt es sich um IP-Router, die IP-Pakete in Hardware weiterleiten und durch RSVP-TE um MPLS-Fähigkeiten ergänzt wurden. Der Schwerpunkt unserer Tests lag auf der korrekten Funktionsweise dieses Signalisierungsprotokolls, das die MPLS-Verbindungssteuerung übernimmt (siehe vorstehenden Einleitungsartikel auf Seite 41).
Bei den Tests von MPLS-Komponenten unterscheidet man zwischen Data-Plane- und Control-Plane-Tests. Bei den Data-Plane-Prüfungen wird getestet, wie sich die Systeme unter Last verhalten, wie die Priorisierung funktioniert, und ob die Ressourcenreservierung eingehalten wird. Die Control-Plane-Tests dagegen untersuchen die Leistungsfähigkeit der MPLS-Signalisierungsprotokolle.
Neben der Verbindungssteuerung benötigt ein MPLS-Router Methoden zur Wegefindung. Hierfür setzen die Hersteller herkömmliche Routingprotokolle oder statische Routen ein, die wir nicht intensiv getestet haben.
Die Kandidaten: Juniper M10 und Unisphere ERX-700
Zum Test beim NetworkWorld-Partner-Lab EANTC in Berlin traten zwei MPLS-Router von Juniper und Unisphere an. Juniper Networks stellt ausschließlich IP-Router her, vorrangig für IP-Infrastrukturanbieter, und verfolgt die Philosophie "Services mit Wire-Speed". Das Produktportfolio umfasst sowohl den Edge- als auch den Core-Bereich. Für den Rand des IP-Netzes bietet Juniper Schnittstellen wie E1, E3, DS3 oder Channelized STM-1/E1 an, sowie Software-Unterstützung zum Beispiel für Layer-2-MPLS und VPNs.
Wir testeten zwei Router des Typs "Juniper M10", die über acht Slots verfügen, in der folgenden Ausstattung: Packet-over-Sonet-Schnittstellen (PoS) der Bandbreiten STM-1, STM-4 und STM-16 (155, 622, und 2048 MBit/s) sowie Gigabit-Ethernet- und Fast-Ethernet-Ports. Die Backplane-Kapazität dieses Modells beträgt 12 GBit/s, andere Geräte wie der M40 oder M160 skalieren nach oben, der M5 nach unten. Beide M10-Router waren mit der Softwareversion "Junos 4.4R2.3" ausgerüstet.
Die Firma Unisphere Networks, die mehrheitlich zum Siemens-Konzern gehört, ist momentan nach eigener Aussage besonders in Asien und Europa sehr erfolgreich. Gemessen am Umsatz liegt sie auf dem IP-Router-Weltmarkt hinter Cisco und Juniper auf Platz drei. Das Unternehmen heißt weiterhin Unisphere und wird nicht in die Konzernstrukturen eingegliedert. Siemens will mit diesem neuen Ansatz die erfolgreichen Unternehmensstrukturen von Unisphere fördern.
Das Motto von Unisphere ähnelt dem von Juniper und lautet "Switch at Wire Speed". Auch Unisphere hat sich auf die Produktion von IP-Routern spezialisiert, die in verschiedenen Größen erhältlich sind. Im Gegensatz zu Juniper fokussiert der Hersteller ausschließlich auf den Einsatz im Edge-Bereich. Dabei geht es im Unterschied zum Core-Routing nicht primär um die Bereitstellung von möglichst großen Bandbreiten, sondern um Dienste, die für bestimmte Einsatzgebiete notwendig sind. Dazu zählen laut Unisphere beispielsweise das Subscriber-Management in DSL-, Fernsehkabel- oder Funknetzen sowie die Bereitstellung von IP-Sicherheit, Virtuellen Privaten Netzen (VPN) und Dienstgütemanagement. Für die Tests stellte Unisphere einen Router des Typs "ERX-700" mit sieben Slots und einer Backplane-Kapazität von 10 GBit/s zur Verfügung. Sein Schnittstellenangebot: STM-1- und STM-4-PoS sowie Gigabit-Ethernet-Ports. Die Router-Software war noch nicht freigegeben, weshalb wir das Gerät mit der Beta-Version "3.2.0 development-0.14" testeten.
Test der RSVP-TE-Implementierung
Im Test mussten die beiden Geräte zunächst beweisen, dass sie die Pflicht beherrschen, das heißt die von den Normen vorgesehenen Pfade durch das MPLS-Netz fehlerfrei aufbauen können. Dabei setzten wir ein ordnungsgemäß funktionierendes IP-Routing voraus. Unser Hauptinteresse galt dem Traffic Engineering mit RSVP-TE im MPLS-Netz.
Diese MPLS-Funktionen sind zwar optional, werden aber von beiden Testgeräten unterstützt. Unseren Testemulator, den "Adtech AX 4000" von Spirent (siehe obiges Bild), verbanden wir über zwei Schnittstellen (Gigabit-Ethernet oder Packet over Sonet) mit dem Router. In dieser Konfiguration führten wir sämtliche Funktionalitätstests durch.
Um die Lastverteilung zu steuern, muss sich der Weg der Pfade fest vorgeben lassen. Voraussetzung hierfür ist die Unterstützung der Explicit Route Objects (ERO), die explizit angegebene IP-Router-Adressen auflisten. Die Testkandidaten mussten zeigen, dass sie explizite Pfade aufbauen können. Dazu ist es notwendig, aus dem Pfad, der in der PATH-Nachricht beschrieben ist, den bereits durchlaufenen Teilweg vor der Weiterleitung zu entfernen. Beide Geräte bewältigten dies problemlos.
Im nächsten Schritt prüften wir die korrekte Ablehnung eines unmöglichen Pfades. Dabei erwarteten wir eine PATHERR-Fehlernachricht mit dem Inhalt "Bad Explicit Route Object". Auch diesen Teil des Standards beherrschten beide Router korrekt.
Einem vorgegebenen Weg zu folgen, ist nur die halbe Miete: Ein RSVP-TE-Router sollte auch Wege aufzeichnen können, einerseits um Schleifen zu erkennen und andererseits, um einmal gewählte Pfade festzuschreiben. Wir testeten das hierfür nötige Record Route Object (RRO), indem wir den emulierten PATH- und RESV-Nachrichten diese Objekte hinzufügten. Der Testrouter sollte seinen Teilweg in das RRO eintragen und damit dokumentieren, dass ein Pfad über seinen Knoten läuft. Die Geräte beider Hersteller absolvierten diese Tests ebenfalls tadellos.
Überprüfung der Traffic-Engineering-Funktionen
Den ordnungsgemässen Umgang mit den Traffic-Engineering-Parametern überprüften wir anhand des Überbuchens eines Links. Das Testgerät muss in diesem Fall Anfragen eindeutig durch eine Ablehnung beantworten. Zur Ausstattung beider Geräte gehörten STM-4-PoS-Schnittstellenkarten, die bei einer Bandbreitenreservierung jenseits ihrer Kapazität von 622 MBit/s eine PATHERROR-Nachricht in Richtung des anfordernden Routers absenden sollten. Gleiches erwarteten wir bei einer Überlastung der Gigabit-Ethernet-Karte mit mehr als 1 GBit/s. In beiden Fällen zeigten die Router das erwünschte Verhalten: Alle zu hoch angesetzten Pfadanforderungen wurden standardgerecht negativ quittiert. Bei Juniper erfolgt dies per Fehlermeldung "Admission Control Failure" mit dem Wert "Requested Bandwidth Unavailable". Unisphere antwortet mit einem "Policy Control Failure". Beides sind akzeptable Reaktionen, der Standard lässt hier genügend Spielraum.
Beschränkte Kontrolle der Policies
Eine Randbemerkung zum Thema Policy Control: Ist einmal eine Reservierung angemeldet, überprüft keines der beiden Geräte den tatsächlich fließenden Verkehr daraufhin, ob die maximale Bandbreite eingehalten wird.
Beide Hersteller gaben auf Rückfrage an, dass keine Garantie für den verlustfreien Transport besteht. Überlast wird statistisch mit Weighted Fair Queueing (WFQ) bekämpft. Dadurch kann es passieren, dass ein konformer Datenstrom Paketverluste erleidet, wenn ein anderer Pfad seine Reservierung überschreitet. Eine Kontrolle der Policies, die einen hundertprozentigen Schutz der konformen Pfade bieten würde, ist weder bei Juniper noch bei Unsiphere vorgesehen. Dazu wurde RSVP-TE laut Aussage von Juniper auch nicht entworfen, da die Bandbreitenreservierung lediglich bei vorübergehender Überlast zum Tragen komme.
Lastverteilung
In Lastsituationen kann RSVP wichtigere Datenströme höher priorisieren als weniger wichtige. Steht beispielsweise eine dringende Videokonferenz an, die über eine bereits ausgelastete Strecke geleitet werden muss, kann der Router niedriger priorisierte Datenströme anweisen, die benötigten Ressourcen freizugeben.
Dies geschieht mit Setup- und Hold-Prioritäten, die sich für jeden RSVP-Pfad festlegen lassen. Dabei definiert "Setup" die relative Wichtigkeit beim Pfadaufbau, während "Hold" den Erhaltungsanspruch für bereits belegte Ressourcen bestimmt. Beide können Werte von 0 bis 7 annehmen. Je kleiner der Wert, desto höher ist die Priorität. Die Unterteilung in Hold und Setup ermöglicht es, die Stabilität eines Pfades unabhängig davon zu definieren, wie wichtig er zum Zeitpunkt des Aufbaus war.
Der Juniper M10 bestand alle Priorisierungstests mit Bravour, während der Unisphere ERX an dieser Stelle einige Schwächen in der Beta-Software zeigte: Offenbar überprüfte der Router nicht die Setup- sondern die Hold-Priorität eines neuen Pfades mit den Hold-Werten existierender Pfade. Zudem löste er bei wichtigen Anfragen alle niedriger priorisierten Pfade auf, ohne vorher zu prüfen, ob die frei werdende Bandbreite für den Aufbau des neuen Pfades ausreichen würde. Daher führte der letzte unserer Priorisierungstests bei Unisphere zu dem ungewöhnlichen Ergebnis, dass alle drei Pfade abgebaut wurden (siehe Tabelle "Priorisierung von Datenströmen").
Datendurchsatz und Kapazität
Die von uns durchgeführten Tests der Call Capacity liefern quantitative Aussagen, wie viele LSPs ein Router maximal verwalten kann. Schätzungen gehen davon aus, dass in mit MPLS-RSVP-TE verknüpften Router-Backbones normalerweise 600 Pfade pro Router nicht überschritten werden. Sobald VPNs zum Einsatz kommen, kann diese Zahl jedoch bedeutend höher liegen. Deshalb ermittelten wir, ob die Geräte bis zu 1700 parallele RSVP-Pfade verwalten können - dies ist die derzeitige Leistungsgrenze unseres Lastgenerators.
Für dieses Testszenario nutzten wir die Fähigkeit des Adtech AX4000, den Aufbau der LSPs in einem engen Zeitfenster zu steuern. Dabei emuliert das Gerät zwei benachbarte Router, die durch regelmäßiges Versenden von PATH- und RESV-Messages jeden einzelnen Tunnel aktiv halten, sodass eine reale Belastung für das Testgerät entsteht.
Beide Geräte absolvierten diesen Test mit Bravour: Die erwarteten Nachrichten wurden regelmäßig für jeden einzelnen Tunnel gesendet. Juniper M10 und Unisphere ERX sind also bei der RSVP-Kapazität auf zukünftige Anwendungen mit einer großen Zahl von Tunneln gut vorbereitet. Laut Hersteller liegt die maximale Zahl von RSVP-Pfaden beim ERX bei 4000 LSPs, der M10 soll sogar 10 000 LSPs sicher bewältigen können.
Durchsatzmessungen der Data Plane
Die Data-Plane-Tests bewerten die Leistungsfähigkeit bei der Weiterleitung von MPLS-Paketströmen. Aufgrund ihrer ähnlichen technischen Ausstattung lassen sich die beiden Kandidaten miteinander vergleichen. Die Tabelle mit den Messwerten finden Sie in der erweiterten Online-Berichterstattung auf www.networkworld.de. Für die Auswahl der Testszenarien legten wir die Bedingungen zu Grunde, die in einem realen Netz zu erwarten sind, und gingen von 500 bis 1000 RSVP-Pfaden pro Router aus. Mit diesen beiden Werten führten wir sämtliche Skalierungstests durch.
Die Durchsatzmessungen ermittelten die IP-Paketverlustrate zum einen bei konstanter Maximallast und variabler Paketgröße (64 Byte bis maximale Größe MTU), zum anderen bei konstanter Paketgröße von 64 Byte und variabler Last (20 bis 100 Prozent). Wir führten die Tests jeweils mit 622-MBit/s-PoS- und 1000-MBit/s-Gigabit-Ethernet-Schnittstellen durch, wobei der Router über zwei Schnittstellen an den Lastgenerator AX4000 angeschlossen war.
In Abhängigkeit von der Rolle eines Routers im MPLS-Netz teilten wir die Messungen in drei Gruppen auf.
- Ingress-Label-Edge-Router: Klassifizierung eingehender IP-Ströme und Weiterleitung in das MPLS-Netz;
- Label-Switch-Router: reine Weiterleitung von MPLS-Paketen;
- IP-Durchsatz ohne MPLS: als Vergleichswert.
Ein Ingress Label Edge Router muss alle ankommenden IP-Pakete analysieren und klassifizieren, sie mit einem MPLS-Label versehen und in den jeweiligen Label Switch Path weiterleiten. Wir wollten wissen, ob diese im Vergleich zu einfachem IP-Routing aufwändigere Arbeit zu Leistungseinbußen führt.
Der Juniper M10 hatte bei diesem Leistungstest eindeutig die Nase vorn: Sowohl auf der PoS-Verbindung als auch über Gigabit-Ethernet sortierte er bei 100 Prozent Last alle Pakete anstandslos in LSPs ein.
Der Unisphere ERX hingegen arbeitete unter Volllast nur bis zu 128-Byte-Paketen einwandfrei ab. Bei der Messung mit 64-Byte-Paketen, welche die für Router theoretisch maximal mögliche Paketlast erzeugt, verlor er bis zu 38 Prozent der kleinen Pakete. Dies weist auf eine Lastgrenze im Extrembereich hin. In der Praxis wird jedoch fast immer ein Mix aus kleineren und größeren Paketen übertragen. Daher dürfte dieses Problem im Normalfall keine Rolle spielen.
Als Label-Switch-Router müssen die Geräte selbst keine Routingentscheidung treffen sondern tauschen nur die Label in den empfangenen Paketen gegen neue aus. Unsere Erwartung, dass hier keine Pakete verlorengehen sollten, erfüllten beide Router auch für kleine Paketgrößen vollauf.
Schließlich verglichen wir die reine IP-Routing-Leistung mit der MPLS-Routing-Performance. Beim Unisphere war deutlich zu erkennen, dass die Ingress-LER-Aufgaben für die Einbußen in der Leistungsfähigkeit verantwortlich sind: Mit Pure-IP leitete der ERX auch die kleinen 64-Byte-Pakete zu 99,1 Prozent weiter. Der Juniper M10 zeigte auch hier in allen Testdurchläufen 100 Prozent Durchsatz.
Bedienung und Konfiguration
Beide Router verfügen über ein einfach zu bedienendes Command Line Interface (CLI). Die Kommando-Vervollständigung und die History (Verfügbarkeit aller zuvor eingegebenen Befehle) sorgen für eine bequeme Konfiguration. Die Befehlsmenüs sind übersichtlich aufgebaut, wodurch sich die Geräte in vielen Fällen auch ohne Blick in die Dokumentation konfigurieren lassen. Die Oberfläche ist stark an das CLI von Cisco angepasst. Zudem unterstützen beide Router das Simple Network Management Protocol (SNMP) und bieten die Möglichkeit, die Konfigurationsarbeit zu automatisieren.
Unisphere implementiert eine Makro-Sprache, mit der sich Konfigurationsskripte erstellen lassen. Diese sind sehr flexibel, da sie auch Parameter enthalten können. Die Sprache ist sehr einfach und gut dokumentiert. Die Makros werden auf den Unisphere-Router heruntergeladen und ausgeführt. Juniper verfügt mit Junoscript über einen ähnlichen Mechanismus. Die Sprache basiert auf XML (Extensible Markup Language).
Insgesamt gesehen belegen die Ergebnisse der von uns durchgeführten Tests, dass MPLS mittlerweile den Kinderschuhen entwachsen ist und für Service Provider und Großunternehmen zunehmend zu einer attraktiven Option wird.
Zur Person
Gabriele Schrenk
ist als Vorstandsmitglied des European Advanced Networking Test Center (EANTC, www.eantc.de) für die Bereiche Testing und Consulting verantwortlich.