Kommentar: Cisco´s SDN-Strategie
Openflow versus Vpath
Flexibilität und Automatisierung von Netwzerken, dafür steht der Begriff Software-Defined-Networking. Die darunterliegende Basis ist ein Protokoll, welches die Daten von der Logik trennt. Doch während fast alle Switch-Hersteller den offenen Standard Openflow unterstützen, setzt Cisco auf ihr eigenes Protokoll Vpath.
In der SDN-Welt wird immer wieder über das Openflow-Protokoll gesprochen. Es handelt sich dabei um ein „offenes“ Protokoll, welches die Trennung der Control- und der Data-Plane in den im Netzwerk installierten Switches oder Routern ermöglicht. Dieses Protokoll wird zwischen einem Controller und physikalischen/virtuellen Switches zur Programmierung und zum Management der Forwarding-Tabellen genutzt.
Weniger bekannt als das Openflow-Protokoll ist das Vpath-Protokoll. Bei Vpath handelt es sich um eine proprietäre Technologie des Herstellers Cisco und wird zur Steuerung der Verkehrsströme in Nexus-1000V-Umgebungen genutzt. Jedoch wird nicht direkt mit den Forwarding-Tabellen kommuniziert, sondern man bedient sich der Hilfe einer Service-Policy. Im Prinzip ist das Ergebnis ähnlich wie in Openflow-Umgebungen.
Da es sich um eine Cisco-Technologie handelt, kann Cisco die Integration virtueller Dienste mit Vpath durch andere Unternehmen steuern. Zu diesen gehören beispielsweise Citrix und Imperva. Mit CiscoVpath wird der Datenverkehr mithilfe von vorkonfigurierten Richtlinien über Virtual-Security-Gateways (VSG) und ASA 1000 geleitet, um betriebliche Abläufe auf Mandantenebene zu vereinfachen.
Vpath ermöglicht einer Nexus-1000V-Komponente nur solchen Verkehr zu empfangen, die bestimmten Kriterien beziehungsweise Richtlinien (IP-Source/Destination) entsprechen, um anschließend eine vordefinierte Aktion auszuführen und den Verkehr an einen Virtual-Services-Node (VSN) weiterzuleiten. Kommt uns das nicht irgendwie bekannt vor? Openflow verwendet hierzu die Match/Action-Mechanismen. Mit Hilfe einer Openflow-Regel lassen sich anschließend die Verkehrströme an einen bestimmten Port oder über eine festgelegte Overlay-Struktur weiterleiten.
Vpath fängt den Verkehr aus einer VM ab, untersucht die Datenströme anhand der damit verbundenen Service-Politik (VM-Port-Profil) und trifft eine entsprechende Entscheidung. Der Verkehr wird gemäß der MAC-Tabelle weitergeleitet oder per Vpath umgeleitet. Auf Basis eines Virtual-Security-Gateways (VSG) wird beispielsweise und unter der Annahme, dass der Verkehr einer definierten Richtlinie entspricht, ein Paket an die VSG zur Inspektion umgeleitet. Entsprechend der Policy wird anschließend eine ACL vom VSG auf das 1000V-Virtual-Ethernet-Module (VEM) heruntergeladen. In der Praxis bedeutet dies, dass das erste Paket eines Datenstroms über einen "langsamen“ Weg übermittelt wird. Alle nachfolgenden Pakete des betreffenden Datenstroms werden nicht mehr untersucht und direkt über einen "schnellen“ Weg übermittelt. Klingt das nicht wie die bekannten Funktionen aus der Openflow/SDN-Welt?
Vpath verwendet eine Overlay-Tunnelstruktur für den Transport der Verkehrsströme aus den VEMs (1000V-Linecards) zu und zwischen den Virtual-Services-Nodes (VSNs). Die Overlay-Struktur ermöglicht auch eine dynamische Service-Verkettung verschiedener virtueller Services.
Die proprietäre SDN-Technologie von Cisco basiert momentan auf VPath. An dieser Strategie ist erst einmal nichts auszusetzen, denn es besteht die Hoffnung, dass Cisco auf Umwegen den SDN-Standard in seine Produkte integriert. Das gleiche gilt für das Virtual-Supervisor-Module (VSM) der 1000V-Lösung. Diese Komponente wird zwar nicht als Controller bezeichnet, sorgt jedoch für das Management der VXLAN-Overlays und schlüpft somit in die Rolle eines SDN-Controllers. Daher muss Cisco beim Marketing von Vpath und VSM noch nachlegen. In der Öffentlichkeit wird diese Gemeinsamkeit beziehungsweise der Unterschied zu den SDN-Konzepten nicht verstanden.
- Openflow versus Vpath
- Fazit
Lesen Sie mehr zum Thema
