Intelligente Netzwerk-Topologien per Software

Kaum ein Bereich der IT hat eine derart unternehmenskritische Bedeutung wie ein sicheres und performantes Netzwerk. Es nützt nichts, den schnellsten Massenspeicher, die leistungsstärksten Server und die modernsten Anwendungen einzusetzen, wenn die Konnektivität mit dem wachsenden Datenvolumen kaum noch Schritt hält, auf Bedarfsfluktuationen nicht reagieren kann und erst recht nicht in der Lage ist, die Netzwerktopologie dynamisch zu verändern oder verteilte Denial-of-Service-Attacken (DDoS) aufzuspüren und abzuwehren, bevor die Firewall zusammenbricht.

Doch genau das ist die Realität der immer noch vielerorts vorherrschenden Netzwerktechnik. Bei der geringsten Betriebsstörung müssen Administratoren etliche Räume durchqueren, Racks aufschließen, Kabel manuell umstöpseln, Netzwerk-Hardware rebooten, IP-Adressen oder Subnetzmasken von Hand eingeben, denn ohne ein robustes Netzwerk kommt das Geschäft zum Stillstand. SDN soll hier Abhilfe schaffen.

SDN steht für Software-defined Networking – zu Deutsch also softwaredefiniertes Netzwerk. Wer sich mit der SDN-Praxis tiefer gehend auseinandersetzt, stellt allerdings schnell fest, dass SDN lediglich ein Oberbegriff ist, der für eine Vielzahl von Ansätzen und Technologien verwendet wird – aber alle mit dem Zweck, das althergebrachte klassische Netzwerk umfassend zu moder­nisieren.

Die Implementierung eines SDNs setzt den Einsatz geeigneter Steuerungsprotokolle voraus, die die Abstraktion des physischen Netzwerks mit einer fein abgestuften Kontrolle ermöglichen können. Diese drei abgestuften Ansätze gibt es:

Die Netzwerkanbieter, von Alcatel-Lucent über Arista Networks, Brocade, Citrix, F5 bis hin zu Juniper und Riverbed, sind allesamt auf den SDN-Zug aufgesprungen. Cisco führt SDN-Lösungen im Rahmen der Produktreihen ONE, API und OpFlex. Auch Hersteller von Datencenter-Hardware – von HP über IBM bis hin zu Dell – wollen bei der Umrüstung von Netzen keinesfalls außen vor bleiben. Diese Anbieter inte­grieren in ihre sogenannten Black-Box-Switches erweiterte SDN-Funktionalität – meist auf der Basis proprietärer Software.

Generische White-Box-Switches sollen die Kostenspirale in den Boden drücken. White-Box-Switches von Anbietern wie Accton Technology, Celestica und Quanta Computer auf der Basis von Betriebssystemen aus dem Hause Cumulus, Vello, Big Switch oder Pica8 und erschwinglicher Hardware mit Broadcom- oder Intel-Bauteilen ermöglichen den Aufbau von SDN-Overlays zu vergleichsweise geringen Anschaffungskosten und die Netzwerkorchestrierung mit minimaler Einarbeitung, bieten jedoch nicht die erweiterte Funktionalität von Marken-Hardware. VMware ermöglicht mit der NSX-Netzwerkvirtualisierungssoftware das Aufsetzen von Overlay-SDNs auf fast beliebiger Hardware.

Quelloffene Lösungen respektabler Standard-Gremien ließen nicht lange auf sich warten. In diese Kategorie fallen unter anderem OpenFlow und OpenStack. OpenDaylight täuscht diese Offenheit lediglich vor, denn hinter dieser Initiative stecken vor allem Cisco und IBM, einige ihrer Partner und auch ein paar neugierige Mitbewerber.

Zu guter Letzt wollen auch innovative Start-ups wie ADARA, Big Switch, Embrane, Midokura, Plumgrid, Pluribus und andere im SDN-Markt Fuß fassen.

Mit der lobenswerten Ausnahme von OpenFlow existieren bisher keine nennenswerten offenen SDN-Standards. Zwar gibt es mit dem OpenDaylight-SDN-Konsortium einen scheinbaren Anwärter, aber die zwei Hauptakteure hinter der Initiative, Cisco und IBM, stellen die Unabhängigkeit ernsthaft infrage. Auch ein uniformer SDN-Ansatz existiert nicht. Jeder Anbieter kocht vorerst mehr oder weniger sein eigenes Süppchen.

Betroffene Interessenten sehen sich somit bei der Wahl einer Lösung einem unübersichtlichen, dynamischen Markt voller Tücken gegenüber.

„Es wäre gar nicht schwierig, sich auf einen Standard zu einigen“, bemerkt Robert Sherwood, CTO von Big Switch Networks und Vorsitzender der Architecture and Framework Working Group der Open Networking Foundation, die für die Entwicklung der Northbound-APIs verantwortlich zeichnet. „Wir könnten einfach sagen, gut, dieser oder jener ist jetzt unser Standard und schon sind wir fertig. Meine Sorge ist aber, dass sich ein Standard später entweder als komplett falsch oder als unvollständig entpuppen könnte. Am Ende kann das viel mehr Schaden anrichten als vorerst überhaupt keine Wahl zu treffen.“

Zumindest anhand der verwendeten API lassen sich die SDN-Lösungen dennoch klassifizieren.

Ist von Software-defined Networking die Rede, dann spielen immer zwei Fachbegriffe eine Rolle: Northbound-API und Southbound-API.

Unter einer Northbound-API versteht man eine Schnittstelle, die mit einer Komponente einer höheren Ebene des OSI-Modells (der Southbound-API) kommunizieren kann. Zu den Funktionen der Northbound-API einer Netzwerk-Hardware-Komponente wie einem Router oder einem Switch zählt die Kommunikation mit Managementlösungen für die Automatisierung, die Orchestrierung und den Austausch von Daten zwischen verschiedenen Netzwerken.

Der Begriff Southbound-API bezeichnet eine Schnittstelle, die mit einer Komponente einer niedrigeren Ebene des OSI-Modells (der Northbound-API) kommunizieren kann. Zu den Funktionen der Southbound-API einer Komponente wie einem Router oder einem Switch zählen die Kommunikation mit dem Netzgewebe (Network Fabric) und die Funktionalität rund um die Handhabung von Netzwerkvisualisierungs-Protokollen und die Integration in ein verteiltes Netzwerk.

Genaugenommen können die Begriffe Northbound und Southbound praktisch jede Art von Netzwerk oder Computersystem bezeichnen, sofern die betreffende Komponente Datenflüsse befördert. Dennoch kamen Northbound und Southbound in den letzten Jahren besonders im Zusammenhang mit APIs und SDNs in Mode. In Netzwerkdiagrammen hat sich die Konvention etabliert, einen Northbound-Datenfluss als von der betreffenden Netzwerkeinheit nach oben verlaufend und analog dazu einen Southbound-Datenfluss nach unten verlaufend zu visualisieren.

---

Etablierte Anbieter von Netzwerk-Hardware fokussieren sich tendenziell auf Southbound-APIs, um eine enge Integration mit den eigenen Produkten zu gewährleisten. Bei solchen SDN-Lösungen spricht man von Underlay-SDNs.

In diese Kategorie fallen unter anderem Cisco mit FabricPath und Juniper mit QFabric. Zu den unverkennbaren Stärken von Underlays zählen die enge Integration und ihre hohe Performance. Diese Eigenschaften erkaufen sich ihre Anwender durch vergleichsweise hohe Anschaffungskosten und eine reduzierte Interoperabilität mit anderen Herstellern.

Ein Underlay-SDN birgt für den Anwender ein hohes Risiko des Vendor-Lock-ins, ließe sich allerdings durchaus auch hersteller- und Controller-unabhängig implementieren – etwa bei der hybriden Arista- 7000-Serie. Diese Implementierung kann jedoch bei der In­tegration des SDN mit physischen Netzen auf der Basis von VXLAN Probleme bereiten.

Der Virtualisierungspionier VMware legt mit der eigenen Overlay-Technologie NSX den Schwerpunkt auf Northbound-APIs. Gleiches trifft auf Microsofts System Center, Junipers Contrail und die SDN-Technologie von Nuage Networks zu. Der wichtigste Vorteil von Overlays besteht in ihrer vergleichsweise hohen Interoperabilität mit vorhandener Hardware nahezu beliebiger Anbieter. Dieser weitgehend hardwareunabhängige Ansatz kann die Migration bestehender Netzwerke wesentlich erleichtern.

Die Flexibilität dieser Lösungen fordert jedoch ihren Preis in Form einer etwas reduzierten Leistung aufgrund des Overheads und eingeschränkten Möglichkeiten der Diagnose von Hardware-Problemen.

Während die Verfechter der Underlay- und Overlay-SDNs ihren jeweils bevorzugten Ansatz für unschlagbar halten, hat sich ein dritter, hybrider SDN-Ansatz auf der Basis von Northbound- und Southbound-APIs entwickelt, der für sich in Anspruch nimmt, die Vorteile von Underlay- und Overlay-SDNs zu verbinden.

Einen hybriden Ansatz verfolgt unter anderem Arista Networks mit dem Software-Driven-Networking-Konzept. SDN-Lösungen von Arista Networks kombinieren die hohe Geschwindigkeit der vergleichsweise komplexen OSI-Ebenen L2/L3/L4 der Underlay-SDNs mit den relativ unkompliziert einzubindenden Overlay-SDN-Daten, die durch SDN-Controller gesteuert und unter Verwendung von OpenFlow-, Wireless- und anderen Protokollen übertragen werden. Arista Networks empfiehlt sich generell dann, wenn die maßgeschneiderte Optimierung des Netzwerkgewebes (Fabric) und des Overlays im Hybrid-SDN zu merklichen Performance-Gewinnen führen soll. Es gibt also insgesamt drei Arten von SDNs:

Wenn über das Pro und Contra von SDN-Lösungen gestritten wird, dann werden als Beispiele gern das Overlay-SDN VMware NSX und das Underlay-SDN Cisco ACI herangezogen.

Bei VMware NSX handelt es sich um eine Netzwerkvirtualisierungs-Plattform für das softwaredefinierte Datencenter (SDDC). VMwares Ansatz basiert auf verteilten virtuellen Switches (vSwitches), die innerhalb des Hypervisors arbeiten, die Konnektivität virtueller Maschinen kontrollieren und mit Hilfe eines Overlay-SDNs verbunden sind. Jeder vSwitch bildet eine Bridge zwischen den virtuellen Maschinen des Hosts und dem Netzwerk außerhalb. Darüber hinaus kann jeder einzelne vSwitch die Aufgaben eines Routers und die einer (verteilten) Firewall und eines Lastverteilers übernehmen. Zwischen den Anwendungen und dem Netzwerk vermittelt der NSX-Controller. Die Southbound-Schnittstelle des Controllers spricht OpenFlow mit der Netzwerk-Hardware. Das Overlay kommuniziert durch Tunneling der Datenpakete via VXLAN (Virtual Extensible LAN), STT (Stateless Transport Tunneling) und/oder GRE (Generic Routing Encapsulation), um die Kompatibilität mit mehreren Hypervisoren zu gewährleisten. Auf ihrem Weg nach außen müssen diese ein NSX-Gateway passieren.

NSX ist eine erweiterbare Netzwerkplattform, die eine Vielzahl von Lösungen von Anbietern wie Arista, Brocade, Cumulus, Palo Alto Networks, Citrix, F5, Symantec und anderen integriert.

Die wichtigsten Kritikpunkte sind die eingeschränkte Erkennung von Hardware-Versagen und mangelnde Transparenz des Netzwerkgewebes gegenüber Anwendungen. VMware NSX empfiehlt sich vor allem dann, wenn die vorhandene Hardware weiterhin im Einsatz bleiben soll.

Bei Cisco ACI (Application Centric Infrastructure) handelt es sich um eine SDN-Lösung, bei der sich alles um die Anforderungen der betreffenden Anwendungen als „Endverbraucher“ der Netzwerkdienstleistung dreht. Cisco steht auf dem Standpunkt, dass sich die IT-Landschaft dauernd ändert und dass Infrastructure as a Service (IaaS) mehr und mehr dem AaaS-Ansatz (Applications as a Service) weicht.

Potenzielle Anwender der ACI-Technologie müssen nicht nur auf Netzwerk-Hardware anderer Hersteller, sondern selbst auf bestehende, aber nicht unterstützte Cisco-Produkte verzichten und Hardware anschaffen. Alte Lösungen von Cisco laufen zwar mit ACI, aber nur mit reduzierter Performance.

Der Einsatz von Cisco ACI erfordert Switches aus der Nexus-9000-Produktlinie und mindestens einen APIC-Hardware-Controller (Application Policy Infrastructure Controller). Diese vielfach als übertrieben kostspielig empfundenen Hardware-Anforderungen hat Ciscos ACI-Technologie den Spitznamen „Hardware-definierte Netzwerke“ eingebracht.

Mit der Application Virtual Switch bietet Cisco auch einen eigenen virtuellen Switch. Zu den unterstützten Hypervisoren zählen die von Microsoft, VMware, Red Hat und Citrix. Für die Konnektivität zwischen den Nexus-9000-Switches (in der Leaf- und Spine-Zuordnung) kommt VXLAN zum Einsatz.

Eine ideale Lösung für sämtliche Nutzungsszenarien gibt es nicht. Cisco ACI bietet sich in erster Linie für ein Cisco-zen­trisches Unternehmen an, wenn es darum geht, die Fa­bric zu modernisieren und zu beschleunigen. Cisco konzentriert sich beim Support ohnehin auf die ACI-Technologie und ist dabei, die eigenen Legacy-Technologien schrittweise ab­zuschaffen.

Mit dem verstärkten Einsatz von SDNs rücken Sicherheits­aspekte in den Vordergrund. Ein durchdacht implementiertes SDN kann gegenüber konventioneller Netzwerktechnik eine deutlich höhere Sicherheit bieten. So lassen sich etwa OpenFlow-basierte Access-Switches nutzen, um vorab alle Datenpakete zu filtern, die ins Netzwerk gelangen sollen.

Außerdem lässt sich die Ressourcenzuordnung auf der Basis von Rollen einrichten und via SDN-Controller überwachen. SDN-Controller können zudem DDoS-Attacken abwehren. Sicherheitsdienstleister, die sich auf die Verteidigung von Datencentern gegen DDoS-Attacken spezialisiert haben, setzen ebenfalls auf SDNs.

Mit SDNs lassen sich zwar sicherere Netzwerke einrichten, aber bisher sind bei Weitem nicht alle Lösungen automatisch abgesichert. SDN-Administratoren kommen daher nicht da­rum herum, sich mit dem Thema Sicherheit von SDNs auseinanderzusetzen.

Mittlerweile gibt es Implementierungen von Overlay-SDNs, die mit mehreren intelligenteren Controllern aufwarten können. Dennoch ist diese Konfiguration längst nicht der Standardfall.

Ein einzelner zentralisierter SDN-Controller eines Overlay-SDNs kann als ein potenzieller „Single Point of Attack“ schnell zum ersten Opfer werden. Sollte der SDN-Controller im Fall eines Angriffs temporär offline gehen, muss er in der Lage sein, sich bei der Wiederverfügbarkeit umgehend um die Synchronisierung der Daten zu kümmern.

Das Southbound-Interface zwischen dem SDN-Con­troller und den darunter befindlichen Netzwerkgeräten ist potenziellen Angriffen ausgesetzt. Es sind Schutzmechanismen vonnöten, um die Verfügbarkeit, die Leistungsbereitschaft und die Integrität des Netzes zu gewährleisten.

Die Hardware in einem SDN muss in der Lage sein, trotz des Ausfalls des (letzten) SDN-Controllers gelegentliche Angriffe zu überstehen und trotzdem neue Netzwerkdatenflüsse umgehend synchronisieren können, sobald die betroffenen SDN-Controller ihre Betriebsbereitschaft wiederherstellen.

Um Schwachstellen zu minimieren, gilt es, das System des SDN-Controllers und des Host-Betriebssystems beim Einsatz von virtuellen Maschinen zu härten. Darüber hinaus sollten Authentifizierungs- und Autorisierungs-Prozeduren implementiert werden, die den Zugriff auf SDN-Controller beschränken.

Die SDN-Ära bringt einen Paradigmenwechsel mit sich: Anstatt die bloße Übertragung von Datenpaketen von Schnittstelle zu Schnittstelle zu verwalten, wird verteilte Software eingesetzt, die komplette Datenflüsse intelligent optimiert.

Im Markt für SDN-Lösungen dominieren derzeit drei Ansätze: Overlay-SDN (Northbound-APIs), Underlay-SDNs (Southbound-APIs) und hybride SDNs (Northbound- und Southbound-APIs).

Unter den IT-Entscheidungsträgern setzt sich schrittweise die Überzeugung durch, dass SDN-Technologie nicht nur die Provisionierung und Auslastung physikalischer Infrastruktur verbessert, sondern auch die Netzwerksicherheit erhöhen kann. Eine fachgerecht umgesetzte SDN-Architektur zählt unter anderem zu den bewährten Lösungen, wenn es darum geht, verteilte DoS-Attacken abzuwehren, die neue Plage aus der Cloud.