Von: Gabriele Schrenk, Andreas Wurm
Immer mehr Carrier setzen auf MPLS (Multiprotocol Label Switching), um ihren Kunden gewinnbringende Mehrwertservices wie Virtuelle Private Netze (VPN) anzubieten. Grund genug für NetworkWorld Germany, gemeinsam mit dem Partner Lab EANTC zwei weitere MPLS-Router zu testen (zu den bisherigen MPLS-Tests siehe Ausgabe 06/01 und 14/01). Im Mittelpunkt stand wieder die Traffic-Engineering-Erweiterung des Resource Reservation Protocol (RSVP-TE).
Die Kandidaten: Riverstone RS 8000 und Avici TSR
Diesmal stellten sich zwei ungleiche Kandidaten den ausführlichen Leistungs- und Funktionstests: Der Core-Router TSR der Firma Avici und der Edge-Router RS 8000 von Riverstone Networks. Die Geräte sind auf verschiedene Zielmärkte ausgelegt und daher so unterschiedlich, dass sie eher Partner als Kontrahenten sind. Ziel von Riverstone und Avici ist es, gemeinsam für Carrier und Serviceprovider eine Lösung für End-to-End-Services anzubieten. Die Leistungsfähigkeit des TSR im Core-Bereich ergänzt sich mit den vielfältigen Möglichkeiten und der Performance des RS 8000 im MAN (Metropolitan Area Network). Beide Hersteller legen großen Wert auf die Interoperabilität ihrer Geräte. Bei unseren Messungen berücksichtigten wir deshalb auch das Zusammenspiel der zwei Router in gemeinsamen Testszenarien.
Nach eigenen Angaben entwickelt Riverstone seine Router nach dem Motto "Reine Bandbreite in profitable Dienste für MANs verwandeln". Die RS-Familie liefert laut Hersteller intelligente Bandbreiten bei hoher Dienstevielfalt und bietet sowohl Routing als auch Switching. Sie unterstützt die wichtigsten Schnittstellen wie Gigabit Ethernet, Packet over Sonet (POS) und ATM (Asynchronous Transfer Mode). Der RS 8000 verwendet die vierte Generation von Asics, um dynamische Bandbreitenregulierung und VPN-Netzwerke auf MPLS-Basis bereitzustellen. Durch das Hitless-Protection-System von Riverstone sollen sich die Geräte auch in puncto Zuverlässigkeit und Verfügbarkeit für Carrier eignen.
Testvorbereitung und Planung
Als Software für den RS 8000 lieferte der Hersteller die Version 8.020 und für die Tests der Priorisierung von Verkehrsströmen die Beta-Version 9.0.A.18. Der Router war mit acht Gigabit-Ethernet-Modulen ausgestattet, die Backplane hat eine Kapazität von 32 GBit/s.
Avici konzipierte die Routerfamilien TSR und SSR mit der Vorgabe, Bandbreiten- und Diensteanforderungen von Carriern und Serviceprovidern gerecht zu werden. Das Ergebnis ist eine ungewöhnliche Systemarchitektur. Sie ermöglicht eine hohe Skalierbarkeit und einen kostengünstigen Kapazitätsausbau im Bereich von 5 GBit/s bis 5 TBit/s.
Avici stattete das Gerät mit der Softwareversion 4.1.2.0 aus. Für die Tests war der Router mit zwei Gigabit-Ethernet- und zwei POS-OC-48-Modulen ausgestattet. Hinzu kamen vier Einschübe für POS-OC-12. Die passive Backplane besitzt keine zentrale Switch-Fabric-Architektur; die Switching-Kapazität zur Backplane beträgt pro Interface 60 GBit/s. Der TSR besitzt eine verteilte Architektur. In der Mainframe-Welt würde man sie "massiv parallel" nennen: Es gibt keine einzelne Backplane, da die jeweils benachbarten Netzwerkprozessoren dreidimensional miteinander verbunden sind. Dadurch variiert die Backplane-Kapazität, abhängig von der Ausstattung eines Gehäuses (Bay). Eine Bay lässt sich mit bis zu 40 Routermodulkarten bestücken. Netzwerkverwalter können mehrere Bays miteinander verbinden. Diese Gehäuse treten dann logisch als ein Router auf. So ist insgesamt eine Kapazität von bis zu 5 TBit/s möglich.
Als Messgerät verwendeten wir den Protokollanalysator und Lastgenerator AX4000 von Spirent Communications, um IP-Pakete mit und ohne MPLS-Label zu erzeugen. Gleichzeitig emuliert der AX4000 das RSVP-TE-Protokoll auf seinen Schnittstellen, verhält sich also wie ein oder mehrere MPLS-Router. Auf seinen ATM-, POS- oder Gigabit-Ethernet-Ports analysiert und generiert er Daten mit Leitungsgeschwindigkeit.
In unserer MPLS Testreihe konzentrierten wir uns dieses Mal neben dem Können auch auf die Zusammenarbeit der beiden Kandidaten. Über die allgemeinen Merkmale hinaus untersuchten wir, wie gut die Geräte Traffic Engineering unterstützen und ob sie als MPLS-Router IP-Pakete korrekt weiterleiten und die Signalisierung standardkonform durchführen. Nicht geprüft wurde, ob die beiden Wettbewerber mit ihrer vollen Backplane-Kapazität Wirespeed routen. Solche Tests sind unserer Meinung nach für die Anwender von zweifelhaftem Interesse, da kein Carrier mit Netzauslastungen von mehr als 60 Prozent arbeitet. Im ersten Teil unseres Tests stand das Signalisierungsprotokoll RSVP-TE im Mittelpunkt.
RSVP-TE-Implementierung
Auf dem Prüfstand mussten die Geräte beweisen, dass sie beherrschen, wofür sie gebaut wurden: Sie sollten entsprechend den Normen Pfade durch ein MPLS-Netz aufbauen. Dabei setzten wir ein ordnungsgemäß funktionierendes IP-Routing voraus. Unser Hauptinteresse richtete sich darauf, wie die Kandidaten Traffic Engineering mit RSVP-TE im MPLS-Netz umsetzen.
Die Tester schlossen den Spirent-Emulator mit jeweils zwei Schnittstellen, Gigabit Ethernet oder POS, an die Router an. Um den Pfad festzulegen, den ein RSVP-TE-Flow passieren soll, können Netzadministratoren Explicit Route Objects (ERO) verwenden. Sie lassen sich für das Traffic Engineering nutzen, das die Auslastung bestehender Netzressourcen steigert. Es ist möglich, einzelne Paketströme von den IP-Routing-Mechanismen abzukoppeln, sodass auch alternative Pfade im Sinne einer gleichmäßigeren Lastverteilung nutzbar sind. Beide Router verstanden und verwendeten das ERO korrekt.
Record Route Objects (RRO) sind wichtig, um Schleifen beim Aufbau von Label Switched Paths (LSP) zu vermeiden. Wie das ERO enthält auch das RRO eine Liste von Routern, die einen LSP durch das MPLS-Netz darstellen. Anders als bei den EROs entsteht diese Liste, während die Path- oder RESV-Message den Weg zum Zielrouter findet. Laut Standard ist dieses Merkmal optional. Es verlangt von jedem Router eine Bestätigung, indem jeder Knoten seine eigene IP-Adresse ans Ende des eingehenden RROs hinzufügt. Der Empfänger dieser Liste sieht den Verlauf des LSP anhand der Informationen aus dem RRO. Diese lassen sich nutzen, um das Netzwerk zu verwalten oder dienen als Input für ein ERO. Auch diese Tests haben beide Router ohne Beanstandung absolviert.
Als nächstes überprüften wir, wie die Router reagieren, wenn ihre maximale Übertragungsrate durch die verwendete Schnittstelle ausgelastet ist und ein Link überbucht wird. Die Geräte sollten eine solche Anfrage ablehnen. Beide erfüllten diese Aufgabe. Einen kleinen Patzer leistete sich hier der RS 8000. Er schickte in der Path-Err-Ablehnung einen falschen Fehlercode. Riverstone will dieses Problem in Kürze beheben. Was die Interoperabilität zu Geräten anderer Hersteller betrifft, dürfte sich der falsche Fehlercode nicht einschränkend auswirken.
Die LSPs lassen sich unterschiedlich priorisieren und damit gewichtet umrouten, falls eine Überlastsituation oder ein Fehler auftritt. Die so genannten Setup- und Hold-Prioritäten werden dabei für jeden LSP definiert. Die Setup-Priorität legt beim Aufbau eines Pfades fest, wie wichtig dieser ist. Die Hold-Priorität dagegen bestimmt den Erhaltungsanspruch für bereits aufgebaute Pfade. Setup und Hold lassen sich von null bis sieben klassifizieren, je kleiner der Wert, desto höher ist die Priorität.
Die von uns verwendete aktuelle Software des Riverstone-Routers unterstützte diesen Mechanismus noch nicht. Deshalb stellte uns der Hersteller die neueste Beta-Version 9.0.A.18 zur Verfügung, die Datenströme priorisieren kann. Damit bestand der Router diese Tests. Auch Avici zeigte hier keinerlei Schwächen. Die als weniger wichtig gekennzeichneten LSPs wurden korrekt von denen mit höherer Priorität verdrängt.
RSVP-TE-Pfadkapazität
Der Test der Call Capacity liefert quantitative Aussagen, wie gut die Router eine große Anzahl von LSPs verwalten können. Wir steuerten den Aufbau der Pfade in einem engen Zeitfenster. Dabei emuliert der Lastgenerator zwei benachbarte Router, die durch regelmäßiges Versenden von Path- und RESV-Messages jeden einzelnen Tunnel im Softstate-Modus halten. Die virtuellen Router erneuern die Pfade, indem sie periodisch Nachrichten verschickten, um die Timer zurückzusetzen. Bleibt eine dieser Nachrichten aus, denkt der Kommunikationspartner, dass der LSP nicht mehr existiert.
Dadurch entsteht eine reale Belastung für die Netzkomponente. Durch das Design des RSVP-Protokolls fällt im Gegensatz zum Label Distribution Protocol (LDP) ein großer Verwaltungsaufwand an, der mit der Anzahl der Pfade linear ansteigt.
LDP ist ein weiteres Protokoll für den Verbindungsaufbau über LSPs in MPLS-Netzen. Mit unserem Lastgenerator bauten wir 10 000 LSPs zwischen zwei Ports des TSR-Routers auf. Damit war die Leistungsgrenze des Adtech-Emulators erreicht. Der Avici TSR meisterte die Aufgabe ohne Probleme. Er baute alle Pfade erfolgreich auf und hielt den Softstate.
MPLS-Datendurchsatz
Laut Aussage von Avici liegt das Limit mir der aktuellen Softwareversion 4.1.2.0 bei 15 000 LSPs pro Port. Riverstone gibt die Kapazität des RS 8000 mit 3000 LSPs pro Port an. Der TSR muss als Internet-Core-Router viele getrennte Kundendatenströme, also LSPs, gleichzeitig verwalten. Riverstone hat ein anderes Einsatzfeld, weshalb an ihn andere Anforderungen gestellt werden und wir seine Leistung in diesem Bereich nicht evaluierten.
Bei großen IP/MPLS-Routern ist es Stand der Technik, Daten bis zur maximalen physikalischen Übertragungsrate der Anschlüsse blockierungsfrei zu routen, auch Wire-Speed genannt. Bei einer großen Anzahl von parallelen IP- beziehungsweise MPLS-Strömen können dennoch manchmal Probleme auftreten. Für diese Tests wählten wir eine bei RSVP-TE realistische Untergrenze von 500 und ein Maximum von 1000 RSVP-Pfaden.
Ein MPLS-Router kann verschiedene Rollen übernehmen. Zum einen als Ingress-Node am Eingang des Netzes, wo er eintreffende IP-Pakete analysiert, klassifiziert und via LSP zum nächsten Knoten schickt. Bei diesem Prozess ordnet der Router die Pakete einem LSP zu und markiert sie mit dessen Label.
Im Core-Bereich dagegen leiten so genannte Label-Switch-Router (LSR) Daten, die auf einem Eingangsport mit einem LSP ankommen, zum dazugehörigen Ausgangsport und LSP weiter. Ein Look-Up in der Forwarding-Tabelle liefert das Label für den Weg zum nächsten Netzknoten, bis schließlich am Ausgang des MPLS-Netzes der Egress-Router das Label wieder entfernt und das IP-Paket gemäß seiner Routing-Tabelle in ein angeschlossenes Netz schickt. Um die Paketverlustrate zu prüfen, gibt es folgende Vorgaben der IETF:
- Konstante Maximallast und variable Pakete, also von 64 Byte bis zur maximalen Frame-Länge.
- Konstante Paketgröße von 64 Byte bei variabler Last von 20 bis 100 Prozent.
Wir verbanden die Router mit zwei Schnittstellen des Lastgenerators AX4000. Die Tests untersuchten die folgenden Rollen und Aufgaben der MPLS-Geräte.
- Label-Edge-Router: klassifiziert eingehende Ströme und schickt sie in das MPLS-Netz weiter.
- Label-Switch-Router: leitet MPLS-Pakete lediglich weiter.
- IP-Durchsatz ohne MPLS: als Vergleichswert.
Router am Eingang eines MPLS-Netzes müssen die meisten Aufgaben erledigen. Der Ingress-Label-Edge-Router (LER) analysiert und klassifiziert alle eingehenden IP-Pakete. Das heißt, er ordnet sie einer Forward Equivalence Class (FEC) zu, versieht sie mit dem richtigen Label und überträgt sie über den entsprechenden Ausgangsport auf den LSP.
Ein LER sitzt gewöhnlich an der Grenze eines Providernetzes und verbindet einen oder mehrere Kunden des Anbieters mit dessen Leitungen. Ein derartiges Gerät muss unterschiedliche Protokolle unterstützen und über Sicherheitsmechanismen verfügen. Der RS 8000 von Riverstone meisterte sämtliche Tests mit einer verschiedenen Anzahl von LSPs und Paketgrößen ohne Paketverlust. Der TSR als Core-Komponente ist meist in der Rolle eines LSRs zu finden. Seine Aufgabe ist es, den von LERs beziehungsweise LSRs kommenden Datenverkehr weiterzuleiten. Die Arbeitsweise des TSR als LER haben wir deshalb nicht getestet. Im Core-Bereich eines MPLS-Netzes sind die LSRs dafür zuständig, die empfangenen IP-Pakete auf den richtigen Ausgangs-Port mit eventuell neuer Label-Information weiterzuleiten. Diese beziehen sie aus der Label Information Base (LIB). Die LIB enthält alle aufgebauten LSPs und beschreibt den Eingangs- und Ausgangsport sowie eventuell vorhandene Reservierungen und Prioritäten.
Nachdem sämtliche Pfade im Netz aufgebaut sind, braucht ein LSR also nur noch anhand der LIB zu switchen. Routen muss er nur im Falle eines Fehlers. Beide Geräte bestanden diesen Test ohne Paketverluste.
Zum Vergleich haben wir auch die reine IP-Performance gemessen. In diesem Test leiteten die beiden Kandidaten die Pakete ohne Label weiter. Sie errechneten anhand der Zieladresse eines Paketes den nächsten Knoten (Next Hop). Hier zeigte der RS 8000 von Riverstone sehr gute Ergebnisse. Auch bei den kleineren Paketgrößen trat während der Tests kein Verlust auf. Der Avici TSR schaffte mit einem realistischen Mix von 500 und 1000 verschiedenen IP-Flows bei allen Paketgrößen einen Durchsatz von 100 Prozent.
Dass die Entwickler von Avici beim TSR ganze Arbeit leisteten, zeigt ein traditioneller, jedoch bei genauerer Betrachtung theoretischer Labortest: Bei nur einem einzigen IP-Datenstrom in voller Bandbreite mit 64 Byte großen IP-Paketen routete der TSR nur mit 55 Prozent Performance. Der Hersteller erläutert hierzu, dass die Switching-Architektur der TSR- und SSR-Modelle darauf ausgelegt wurden, in allen Konfigurationen die korrekte Reihenfolge der IP-Pakete sicherzustellen. Bei einem einzigen IP-Flow können deshalb die massiv verteilten Ressourcen der Avici-Router ihre Stärken gar nicht richtig ausspielen.
Konfiguration der Router
Das Command Line Interface (CLI) von Riverstone ist gut dokumentiert und leicht zu bedienen. Einfache MPLS-Konfigurationen lassen sich schnell und ohne weitere Hilfe aufsetzen.
Das Menü von Avici ist mit dem Internetwork Operating System (IOS) von Cisco nahezu identisch. Darüber hinaus lassen sich die "Config Text Files" von Cisco in den TSR einlesen und als eigene Konfiguration übernehmen. Eventuell nicht unterstützte Merkmale zeigt die Software dem Administrator an. Wie bereits eingangs erwähnt, haben wir auch die Interoperabilität der beiden Router getestet. Dabei interessierten wir uns für folgende Punkte:
- Aufbau von LSPs mit LDP
- Aufbau von Traffic-Engineering-LSPs mit RSVP-TE
Als Routing-Protokoll zwischen den beiden Geräten nutzten wir Open Shortest Path First (OSPF). In den Prüfungen zeigten beide Router keinerlei Schwächen bei der Zusammenarbeit und absolvierten alle Tests ohne nennenswerte Beanstandungen.
Zur Person
Gabriele Schrenk
ist als Vorstandsmitglied des EANTC (www.eantc.de) für die Bereiche Testing und Consulting verantwortlich.