Von: Bernd Reder
Auf den ersten Blick scheint virtuelles Routing ein eher esoterisches Thema zu sein, das höchstens für eine Handvoll Serviceprovider und Carrier von Interesse ist. Dem ist jedoch nicht so. Virtuelle Router kommen beispielsweise dann ins Spiel, wenn ein Nutzer auf ein Virtuelles Privates Netz zurückgreifen möchte, um den Transfer von Daten über das Internet oder Extranets abzusichern. Zudem bestehen viele Firmen mit großen unternehmensweiten Netzen nach wie vor darauf, die Konfiguration der Router in ihren Enterprise Networks selbst vorzunehmen. Andererseits greifen sie auf einen Serviceprovider zurück, um Zugang zum Internet oder zu anderen Diensten zu erhalten. In beiden Fällen sind virtuelle Router von Vorteil, um die Zugangskontrolle und das Filtern der Routing-Daten zu vereinfachen.
Weitere Anwendungsgebiete, bei denen VR zum Zuge kommen, sind räumlich verteilte Speichernetze (Storage Area Networks) oder das Bereitstellen von Breitbanddiensten in Geschäftsgebäuden.
Was ist aber nun ein virtueller Router? Die amerikanische Firma IP Infusion, die Netzwerkprozessoren und die Routing- und Switching-Protokollsoftware "ZebOS", anbietet, definiert einen virtuellen Router folgendermaßen: als "Emulation eines physikalischen Routers auf der Software-Ebene". Allegro Networks, ein Startup-Unternehmen, das ebenfalls in den USA beheimatet ist, betrachtet virtuelles Routing als "Aufteilen eines einzelnen Route-Prozessors in mehrere logische Untereinheiten, die unterschiedliche Routing-Tabellen verarbeiten."
An einen virtuellen Router (VR) werden folgende Anforderungen gestellt:
- Er muss komplett unabhängig von den anderen Systemen arbeiten. Das schließt auch die Routing-Protokolle mit ein, sprich, jedes System sollte über seinen eigenen Protokollsatz verfügen.
- Für jeden VR ist eine separate Routing Information Base (RIB) erforderlich, und zwar ebenfalls für alle Protokolle, die unterstützt werden, etwa die Internet-Protokoll-Versionen 4 und v6 oder Multiprotocol Label Switching (MPLS).
- Zwei Instanzen müssen den VR managen können: zum einen der Spezialist, der nur für einen speziellen Router zuständig ist, sei es beim Serviceprovider oder auch ein IT-Fachmann in einem Unternehmen, zum anderen ein autorisierter globaler Administrator, der Zugriff auf alle virtuellen Systeme hat.
- Ein virtueller Router benötigt eine eigene Forwarding Information Base (FIB).
- Es müssen virtuelle Instanzen für Firewalls, NAT-Dienste (Network Address Translation) sowie Quality-of-Service- und Sicherheitservices implementiert sein.
- Das System muss sich auf einfache Weise skalieren lassen.
Hinzu kommen noch Anforderungen, die sich auf das Gesamtsystem beziehen (siehe Ticker oben).
Ein Beispiel dafür, wie sich virtuelle Router in Software "nachbauen" lassen, ist die "ZebOS Advanced Routing Suite" von IP Infusion. Das Unternehmen erweiterte dazu eine bestehende Version der Routing-Suite. Da ein virtueller Router ein physikalisches System nachbildet, finden sich in ihm dieselben Bestandteile wie bei einem "richtigen" Gerät, etwa die Routing Information Base, Forwarding Plane oder Komponenten für den Transport von Daten mittels unterschiedlicher Routing-Protokolle.
Als zentrale Verwaltungseinheit des virtuellen Routers dient die Management Authority (MA) . Sie stellt Informationen über die Konfiguration des Systems bereit. Außerdem ist sie die Kommunikationsschnittstelle zur Management Authority des Hardware-Routers, auf dem die Software implementiert wird. Das Kernstück des Programmpakets, mit dem sich ein VR simulieren lässt, ist im Falle von IP Fusion im "Network Services Module" (NSM) untergebracht.
Eine besondere Rolle spielt bei VR der TCP/IP-Stack. Er muss in der Lage sein, mehrere Forwarding Information Bases (FIB) zu unterstützen. Hinzu kommt, dass der Stack mithilfe von Application Programming Interfaces (APIs) den einzelnen Forwarding Information Bases die passenden Router-Schnittstellen zuordnet.
Multi-Router statt virtueller Systeme
Das Konzept softwaregestützter virtueller Router wird von einigen Fachleuten kritisiert. Zu ihnen gehört Troy Dixler, der Mitbegründer von Allegro Networks. Nach seiner Ansicht weist dieser technische Ansatz eine Reihe von Schwachstellen auf:
- Die virtuellen Systeme müssen sich CPU-Leistung und Arbeitsspeicher der Hardware-Plattform teilen. Das kann zu Lasten der Performance gehen.
- Software ist in der Regel fehlerträchtiger als Hardware, das heißt, ein rein softwaregestütztes Routing ist weniger zuverlässig.
- Virtuelle (Software-)Router verwenden in der Regel dasselbe Betriebssystem. Wenn eine neue Version oder Patches eingespielt werden, tangiert das somit alle Router.
- Sicherheitsprobleme, etwa Denial-of-Service-Attacken, können sich auf alle Router auswirken.
Allegro versucht derzeit, einen Ansatz in die Routing-Welt einzuführen, den das Unternehmen als Multi-Router-Technologie bezeichnet. Vereinfacht gesagt, handelt es sich um ein System, das aus separaten Routing-Engines mit eigener CPU und Arbeitsspeicher besteht. Mithilfe spezieller Software lässt sich jeder Port flexibel einzelnen Routern zuordnen, und zwar auf der logischen wie auf der physikalischen Ebene.
Diese Architektur soll ein Kernproblem herkömmlicher "monolithischer" Router und von virtuellen Routern beseitigen: Die Überlastung der Control Plane der Systeme durch die Vielzahl der Routing-Informationen, die zu verarbeiten sind. Dieses Phänomen tritt Troy Dixler zufolge vor allem dann auf, wenn Multiprotocol Label Switching in größerem Maßstab Verwendung findet. In diesem Fall müssen vor allem die Router am Rande des Providernetzes, also am Edge, die Routing-Informationen aller Firmennetze verarbeiten, für die sie virtuelle Router aufsetzen. Auch die Line-Cards in den Routern stoßen an ihre Leistungsgrenzen, weil sich die Zahl der Forwarding-Informationen erhöht, die sie zu bewältigen haben.
All diese Probleme soll das Konzept von Allegro lösen. Allerdings hat das Unternehmen seine Technik bislang noch nicht in ein funktionierendes Produkt umsetzen können. Wann das angesichts der schrumpfenden Budgets der potenziellen Abnehmer, sprich Carrier und Internet-Serviceprovider, der Fall sein wird, ist offen. Derzeit deutet alles darauf hin, dass die Anwender zunächst eher auf bewährte Lieferanten wie Cisco oder Juniper setzen und sich die Option offen halten, später auf eine neue Generation von Edge-Routern umzusteigen.