Neuer Schwung durch VPN

Neu ist das Thema "virtuelles Routing" beileibe nicht, doch erlebt es derzeit seinen zweiten Frühling. Maßgeblich dafür verantwortlich ist die wachsende Nachfrage nach Virtuellen Privaten Netzen, die eine strikte Trennung der einzelnen Datenströme erfordern.

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.