SD-WAN
Hier liegt der Fokus auf der Optimierung von Weitverkehrsnetzen. Der Vorteil steckt in der automatisierten Flexibilität in Bezug auf intelligentere Routingentscheidungen.
Die kontinuierlich steigenden Anforderungen an Wide Area Networks (WAN) basieren zu großen Teilen auf dem wachsenden Einsatz von Cloud-Lösungen. So steigt mit jedem Dienst, der aus dem eigenen RZ ausgelagert wird, die benötigte WAN-Kapazität. Zudem haben viele dieser Cloud-basierten Dienste auch den Bedarf nach geringer Latenz. Stichworte sind hier Software-as-a-Service (SaaS) und Infrastructure-as-a-Service (IaaS). Besonders Unternehmen mit vielen Außen- oder Zweigstellen brauchen auch ohne Cloud-Services ein effizientes, wartungsarmes Weitverkehrsnetz. Zweigstellen müssen performant und redundant angebunden sein, im Fehlerfall sollten auch alle übrigen Leitungen den Ausfall effektiv abfangen.
Worin liegen die Vorteile eines Software-basierten Ansatzes?
Hochverfügbare, leistungsfähige WAN-Anbindungen kosten Geld. Die Aufteilung des Netzverkehrs auf verschiedene WAN Strecken nach Priorität und Anwendungsanforderungen ist mit aktuellen Netztechnologien nur schwer zu realisieren, da die Routingentscheidungen meist nicht auf der Anwendung, sondern dem Zielnetz basieren.
SD-WAN bietet hier Möglichkeiten der Kostensenkung durch unabhängige, anwendungsbasierte Routingentscheidungen für verschiedene WAN-Strecken eines Unternehmens (DSL, MPLS, 3G/4G/5G, Dark Fiber, usw.). So können zum Beispiel zeitkritische Systeme über eine schnelle, aber schmalbandige Verbindung geleitet werden, wohingegen das datenintensive Zweigstellen-Backup zeitlich und automatisch über einen Breitband-DSL-Anschluss fließt.
Zu den stärksten Anbietern in diesem Bereich zählt VMware. Der Grund ist offensichtlich. Das virtualisierte RZ-Netz möchte natürlich auch aus der Cloud und aus Zweigstellen kosteneffizient und sicher erreichbar sein.
Silver Peak und Cisco sind nur zwei der vielen Anbieter, die in diesem Kontext Lösungen anbieten. Silver Peak wirbt zusätzlich zum Software-defined WAN auch noch mit einem Self-Driving WAN, das Automatisierung und Machine Learning kombiniert. Naja, die Abkürzung SD-WAN passt ja trotzdem noch!
Wie macht Google das eigentlich?
Eines der größten Firmennetze weltweit gibt es ohne Zweifel bei Google. Ca. 25% des globalen Internetverkehrs wandert täglich über Googles Leitungen. Ein Blick auf diese Infrastruktur ist durchaus lohnenswert.
“Early on, we realized that the network we needed to support our services did not exist and could not be bought.” (Amin Vahdat, Technical Lead for Networking at Google)
Diese Aussage ist am Beispiel vom Google Assistant nur allzu gut nachvollziehbar. Der Gedanke an die Anforderungen eines globalen Netzes mit Echtzeit-Sprach-Kommunikation lässt so manchen Administrator erzittern. Auf die gesprochene Frage nach den neuesten Nachrichten in jeder Sprache, jedem Akzent und in jedem Land der Welt muss der Google Assistent in Sekundenbruchteilen eine Antwort parat haben. Und wie? Die Sprachdatei wird vom Smartphone zum nächsten „Peering-Point“ von Google geleitet. Von dort sucht das Software-gesteuerte Netz den schnellsten Weg zum nächsten Speech-to-text-RZ. Sind die Daten nun in Textform vorhanden, suchen Google-Server auf der ganzen Welt nach den neuesten Nachrichten, filtern diese nach persönlichen Präferenzen, bereiten sie auf und senden sie auf das Smartphone des Nutzers. All dies in Sekunden oder Sekundenbruchteilen. Im Vergleich zu dieser Aufgabe scheint unterbrechungsfreies Telefonieren im eigenen Firmen-WAN eine Banalität. Und trotzdem ist dies in vielen Konzernen noch immer problematisch.
Kommen wir aber zurück zu unserem Taxi-Beispiel. Ein riesiger Vorteil wäre doch, wenn der Hubschrauber seine Informationen mit den Fahrern aller Taxi-Unternehmen teilen würde. Leider ist das größtenteils noch Wunschdenken. Haben Hersteller erst einen potenten Hubschrauber entwickelt, teilen sie diesen nur äußerst ungern mit der Konkurrenz.
Openflow
Ein nennenswerter Ansatz in Bezug auf herstellerunabhängige, Software-basierte Netze ist die Arbeit der Open Networking Foundation (ONF).
Google, Telekom, AT&T und viele andere namhafte Konzerne beteiligen sich seit Jahren an der Weiterentwicklung von offenen SDN-Standards. Openflow ist die wohl bekannteste Entwicklung der ONF und wird inzwischen von diversen Herstellern unterstützt.
Das Openflow-Protokoll stellt eine herstellerunabhängige Schnittstelle zwischen der Daten- und Kontrollschicht dar. Im Prinzip handelt es sich um ein Application Programming Interface (API). Wir hatten bereits festgestellt, dass der Kerngedanke von SDN darin liegt, die Switching-Hardware sparsamer zu dimensionieren und die Kontrollstrukturen zu zentralisieren. Durch diese Umverteilung der Netzrechenlast können potentiell hohe Kosten bei der Switching-Hardware eingespart werden.
Nachteilig ist festzuhalten, dass bei Ausfall einer zentralen Kontrollstruktur die Gefahr besteht, dass das gesamte Netzwerk nicht mehr agieren kann.
Openflow stellt das Kommunikationsprotokoll zwischen diesen beiden Instanzen dar. Angeblich unterstützen Swítches von Broadcom (ehem. Brocade), Cisco, Extreme Networks, HPE und Juniper dieses offene Protokoll.
Die meisten Hersteller setzen jedoch auf ihre spezifischen Verfahren.
Google als Betreiber eines globalen Backbones mit einem Durchsatz von 9 Pb/s (1 Petabit entspricht 1000 Terabits) war maßgeblich an der Entwicklung von Openflow beteiligt. Da muss man sich doch wundern, warum dieses Protokoll noch immer so selten eingesetzt wird.
Shortest Path Bridging
Einige wenige Hersteller setzen die im Jahr 2012 vom IEEE standardisierte Technologie Shortest Path Bridging (SPB) ein. Trotz der geringen Verbreitung, die mein Kollege Dr. Moayeri in seinem Geleit erwähnt (Netzwerk Insider Ausgabe November 2019), ist SPB ein gutes Beispiel dafür, warum eine Optimierung aktueller Netze nicht völlig abwegig ist. Eine kurze Erläuterung der Beweggründe für SD-Campuslösungen erscheint mir angebracht.
Besonders in großen Campus-Netzen steigt die Zahl der anzubindenden Endgeräte kontinuierlich. Es sind nicht mehr nur PCs und Smartphones zu vernetzen, auch stoßen immer mehr IoT Geräte dazu. Über Sicherheitsaspekte im Zusammenhang mit diesen neuen Geräten können Sie in dem Artikel meiner Kollegin Tanja Ulmen (Netzwerk Insider Ausgabe November 2019) mehr erfahren.
Mit der Kennziffer IEEE802.1aq ordnet sich SPB als Erweiterung von 802.1Q (VLANs) in die Reihe der Technologien zur effizienteren Gestaltung von kabelgebundenen Netzen ein.
Schauen wir uns also die Grundzüge von Shortest Path Bridging an. Ohne allzu tief einsteigen zu wollen, ist eine grundlegende Erläuterung sicherlich hilfreich, um die Anwendung in Software-defined-Netzen besser einordnen zu können.
Da sich die Vorzüge von SPB deutlicher darstellen lassen, wenn die Alternativen aufgezeigt werden, muss ich ein bisschen ausholen. Im Prinzip zielt SPB auf eine Optimierung des Verkehrs auf der Netzschicht 2.
Um die Verfügbarkeit zu erhöhen, sind größere Netze immer in gewisser Weise vermascht. Von jedem Punkt im Netz zu jedem anderen Punkt sollten mindestens 2 physische Wege existieren, um bei Ausfällen einzelner Komponenten weiterhin die Verfügbarkeit des gesamten Netzes garantieren zu können.
Auf Schicht 2 gibt es jedoch ein Problem: Ethernet-basierte Netze reagieren extrem empfindlich auf Schleifen. Wie in Abbildung 1 dargestellt, führt jede Wege-Redundanz zu einer solchen Schleife. Die bisher am weitesten verbreitete Lösung dieses Problems ist das Spanning Tree Protocol (STP). Der rechte Teil von Abbildung 1 stellt dar, wie Schleifen hier vermieden werden. STP spannt tatsächlich Bäume in unseren Netzen auf. Bricht ein aktiver Ast weg, kann STP diesen zeitnah durch einen zuvor deaktivierten Link ersetzen. Einige STP-Versionen reduzieren die Zeit für dieses Umschalten auf Sekundenbruchteile.
Abbildung 1: Grundidee Spanning Tree
Um nicht zu sehr abzuschweifen, behaupte ich, dass die (automatische) Wegfindung auf Basis des Spanning-Tree-Verfahrens nicht optimal ist. Bei STP geht es einzig und allein um die Vermeidung von Schleifen.
Kommen wir also zurück zu unserem Shortest Path Bridging. Im Prinzip erklärt sich der Name von selbst: Nutze den kürzesten Pfad als Brücke. SPB nutzt – im Gegensatz zu STP – einen Algorithmus zur optimalen Wegfindung pro VLAN/Verbindung. Die Berechnung dieser Wege erfolgt durch IS-IS (Intermediate System to Intermediate System Protocol). Diese optimalen Wege werden über selbiges Protokoll im Netz propagiert, sodass alle teilnehmenden Knoten zu jeder Zeit wissen, was wohin muss und wie. Somit steigt in gewissem Maße die Intelligenz auf Schicht 2.
In unserem Kontext ist eine Erweiterung von SPB zu erwähnen.
SPBM bietet auf Schicht 2 eine Kapselung an, mit der „klassische“ VLAN-Informationen an den SPB-Randbereichen quasi nochmals gekapselt werden, um die gewünschte Interoperabilität zu gewährleisten.
Somit ist es möglich, direkte Kopplungen zu Netzsegmenten ohne SPB vorzunehmen.
MLAG / MC-LAG
Eine weitere Option zur Minimierung von STP-bedingten Nachteilen ist Link-Aggregation. Im Prinzip ist das nichts Neues. Zwei oder mehr physische Schnittstellen können zu einer logischen verbunden werden. Im Idealfall wird die Gesamtlast nun dynamisch auf alle teilhabenden Leitungen aufgeteilt.
MLAG bzw. MC-LAG steht für Multi-Chassis-Link-Aggregation, also Link-Aggregation über mehrere Chassis / Switches. Das hat den Vorteil, dass notwendige redundante Links zeitgleich (active/active) auch über die Grenzen eines Switches hinweg genutzt werden können.
Wie in Abbildung 2 dargestellt, bietet MLAG/MC-LAG eine Alternative zum Spanning-Tree-Protokoll, in der alle Leitungen parallel genutzt werden können.
Abbildung 2: MLAG
VXLAN
Virtual Extensible LAN (VXLAN) ist ein sogenanntes Overlay-Protokoll. Overlay bedeutet in diesem Kontext, dass ein virtuelles Netz über ein physisches gespannt wird. Im Prinzip reden wir hier von einem Tunnelmechanismus. VXLAN nimmt Ethernet-Pakete (Layer 2) und enkapsuliert diese in UDP-Datagramme (Layer 4). Diese verschachtelten Daten treten anschließend ihre Reise durch ein klassisches, IP-basiertes Netz (hier: Underlay) an.
Zum Vergleich: SPB hat ein Layer 2 Underlay; Ethernet-Frames werden in neue Ethernet-Frames enkapsuliert.
Der Vorteil von VXLAN liegt auch hier in der Skalierbarkeit. Im Gegensatz zu VLANs (ca. 4000) können mittels VXLAN ca. 16 Millionen voneinander unabhängige Netzsegmente parallel existieren.
Eingesetzt wird die im RFC 7348 spezifizierte Technologie u.a. von Cisco SDA und Openstack Neutron.
Was heißt das jetzt für SDNs?
Ich habe weiter oben festgestellt, dass SPB schon auf der zweiten Schicht die kürzesten Wege heraussucht. Ebenso kann MLAG redundante Wege effizienter nutzen als mit dem Spanning-Tree-Protokoll möglich.
Wozu also Routing? Einige Whitepapers versprechen, dass klassische Infrastruktur-Protokolle à la OSPF, RIP, VPLS oder PIM schlichtweg wegfallen, wenn SPB(m) eingesetzt wird.
Die Idee ist verlockend. Stellen wir uns also ein (Campus-/Access-)Netz vor. Hier sind wir wieder bei dem Begriff Overlay. Wir haben also eine SPB-Wolke, die quasi automatisch und ohne äußere Einflüsse ein Layer 2 Routing durchführt, um unsere Pakete von A nach B zu schicken. Abbildung 3 visualisiert dieses Overlay.
Abbildung 3: SPB
Zwischenfazit: Es gibt Verfahren, die den klassischen Netzverkehr intelligenter und effizienter steuern – und das im Prinzip automatisch.
SDN im Campus-Umfeld? Kennen wir!
SDN wird definiert als Trennung von Daten- und Kontrollschicht (abweichend von STP, MLAG und SPB). Eine zentralisierte Instanz trifft Wegewahl-Entscheidungen, die auf der Kenntnis des gesamten Netzes beruhen. Zugangskontrolle muss ebenfalls zentral verwaltet werden können. Die Endkomponenten (Edge-Devices) befolgen lediglich die Anweisungen der Kontrollschicht.
Im Prinzip entspricht diese Erläuterung exakt dem Konzept von WLAN-Controllern und Thin Access Points! Ein Controller (zentral im RZ platzierte, geballte Kompetenz) verwaltet die Zugriffskontrolle, legt Kanäle und Sendeleistungen fest, steuert den Verkehr und stellt Übergänge zu angrenzenden Netzen bereit. Die Access Points sind auf die Vorgaben des Controllers angewiesen und ohne diese völlig handlungsunfähig.
Interessant ist, dass tatsächlich immer mehr Hersteller von diesem zentralisierten Ansatz im WLAN abrücken und Controller-lose WLAN-Umgebungen mit zentralem Management, aber dezentralem Controlling anbieten…
Kommen wir zurück zum kabelgebundenen Netz.
Beweggründe für den Einsatz von SD-Lösungen
Es ist wichtig zu verstehen, welche technischen, wirtschaftlichen und betrieblichen Vorteile eine SD-Campus-Lösung bieten kann – und welche nicht. Software-defined-Netze sind bei korrektem Einsatz technisch ohne Zweifel effizienter.
Eine wirtschaftliche Betrachtung kann pauschal nicht erfolgen, da dies vom Anwendungsszenario und den technischen Gegebenheiten abhängt. Der Betrieb jedoch wird wesentlich effizienter. Das Gesamtnetz wird durch SDN zwar nicht zwingend schneller, aber durch die Abschaffung von STP und die Einführung einer zentralen Management-Instanz werden die vorhanden Leitungen besser genutzt und der Betrieb wird vereinfacht. Das Netz wird dadurch dynamischer, skalierbarer und prinzipiell günstiger im Betrieb.
Natürlich kann man auch mit klassischen Netzumgebungen und einer geregelten Netzzugangskontrolle den Access-Bereich implementieren.
Bei SDN geht es ja auch nicht um die Schaffung einer völlig neuen Infrastruktur. Das Ziel ist lediglich die (kosten-)effizientere Bereitstellung von Diensten und Kommunikationsschnittstellen.
Anwendungsfall Campus LAN
Nachdem wir nun wissen, dass SD-Lösungen bereits sinnvoll in Rechenzentren und Weitverkehrsnetzen eingesetzt werden, schafft eine Gegenüberstellung der Anforderungen eines Campus-Netzes und der Fähigkeiten von SD-Netzen Klarheit über die potentiellen Vorteile.
Ein typisches Campus-Access-Netz besteht im Regelfall aus drei logischen Ebenen: Access, Distribution und Core. Der Access-Bereich ist die physische Schnittstelle zu den jeweiligen Endgeräten (Laptops, PCs, usw.). Bei größeren Netzen lohnt sich eine Distributionsebene, die letztlich die Masse an Access-Switchen aggregiert. Das Routing zwischen den verschiedenen internen Netzen und zu externen Bereichen übernimmt der Netz-Core.
In Abbildung 4 ist dieser Aufbau vereinfacht grafisch dargestellt. Aufgrund einer im Regelfall benötigten logischen Trennung verschiedener Netzbereiche (z.B. aufgeteilt nach Abteilungen) werden auf den Access-Switches verschiedene VLANs bereitgestellt. Zur Erinnerung: ein VLAN stellt ein logisch getrenntes Netz über die physischen Grenzen eines Switches hinweg bereit.
Nach dem Grundaufbau einer solchen Architektur haben Netzadministratoren die Aufgabe, diese VLANs statisch oder dynamisch (z.B. via NAC/802.1X) auf den entsprechenden Switch-Ports bereitzustellen. Im Core müssen dann die entsprechenden Routen (Verkehrsnetze) aufgebaut werden, um die jeweils gewünschte Kommunikation zwischen den VLANs und mit anderen Netzbereichen zu etablieren.
Abbildung 4: Campus-Layer Architektur
Wofür benötige ich SDN?
Bessere Skalierung kann eine Motivation für die Anwendung des SDN-Ansatzes sein. Stellen wir uns das obige Netz nun nicht mit 4, sondern mit 400 Access-Switches vor. Der Administrationsaufwand steigt linear mit der Anzahl an Netzkomponenten.
Mit der eben genannten Network Access Control (NAC) lässt sich schon eine wichtige und potentiell zeitaufwändige Aufgabe zumindest teilweise automatisieren. Über dynamische VLAN-Zuweisungen ist es möglich, jedem Endgerät, das per NAC erkannt wird, an jedem Switch-Port automatisch das richtige VLAN bereitzustellen. Die Administration und Pflege solcher Endgeräte, die keine Identifizierung gemäß IEEE 802.1X unterstützen, sind nach wie vor zeitaufwändig
Eine SD-Campus-Lösung bietet die Möglichkeit eines zentralisierten Management-Ansatzes.
SD-Lite?
Generell lässt sich feststellen, dass alle aktuellen SD-Lösungen für Campus-Netze weniger mit der klassischen SDN-Definition zu tun haben, als die Namen vermuten lassen. Dennoch verfolgen alle Hersteller ähnliche Ansätze, die zwar nicht kompatibel zueinander, in homogenen Netzen jedoch anwendbar sind.
Überblick: einige Herstellerlösungen
Es folgt ein Überblick über einige Herstellerlösungen für SD-Campus-Netze.
Cisco
Als weltweit größter Hersteller von Netzkomponenten bietet Cisco im Campusbereich natürlich auch eine SD-Lösung an. Der Hersteller hat diese Lösung Software-Defined Access (SDA) getauft. Das Herzstück dieser Architektur ist das Cisco DNA Center. Das DNA Center vereint eine Vielzahl an Tools zur automatisierten Konfiguration des Netzes.
Technologisch setzt Cisco bei der Kontrollschicht auf LISP, in der Datenschicht auf VXLANs. Beide Protokolle sind von der IETF und nicht vom IEEE spezifiziert worden. Die Idee: Ein Overlay-Netz stellt eine effizientere und automatisierte Verkehrsregelung bereit.
Grundsätzlich bietet Cisco mit dem DNA Center und einem Teil der Switches im Portfolio des Herstellers eine Lösung zur erhöhten Netz-Effizienz im Access-Bereich an.
Die Gesamtlösung besteht bei Cisco aus fünf Bausteinen, zu denen es jeweils ausreichend Dokumentation gibt:
- Physische Schicht: Beschreibung der für die SD-Architektur notwendigen und unterstützten Hardware
- Netzschicht: Aufbau des Netz-Underlays und der Fabric-Overlays
- Kontrollschicht: Software-System zur Steuerung des Netzes
- Managementschicht: Schnittstellenverwaltung (Web Interface) für Management und zu anderen Diensten über APIs
- Partner Ecosystem: Einbindung der Lösungen von Drittanbietern in das DNA Center
Extreme Networks
Eine der von Extreme Networks angebotenen Campus-Lösungen basiert auf SPB. Geworben wird mit vielen erfolgreich implementierten SD-Netzen. Nennenswert ist unter anderem die Funktion des „auto-attach“ von Netzkomponenten. So können beispielsweise neue Switches eigenständig über LLDP ihren Standort im Netz bestimmen und von der zentralen Komponente automatisch ihre Konfiguration anfordern.
HPE Aruba
HPE setzt im Campus-Bereich u.a. auf die akquirierten Lösungen von Aruba. Der Fokus liegt hier auf kabelloser Arbeitsplatzbereitstellung gemäß einer „Mobile First“-Strategie. Obwohl bei der kabelgebundenen Kommunikation auf klassische Kommunikation gesetzt wird, sind mit Aruba Central, ClearPass und NetInsight viele Konfigurationseinstellungen zentralisiert. Vor allem netzweite und anbindungsunabhängige Sicherheitsrichtlinien (Policies) bieten ein hohes Maß an administrativem Komfort.
Den größten Fokus legt HPE bei der Werbung für die eigene Software-gesteuerte Infrastruktur auf Zweigstellen-Netze. Mit Arubas SD-Branch-Technologie erhält der Kunde die Funktionalitäten von SD-WAN mit nahtloser Integration ins eigene Campus-Netz.
Arista
Mit dem Cognitive Campus bietet Arista eine Lösung an, die auf einer MLAG-basierenden Architektur aufbaut. Im Prinzip geht es beim Cognitive Campus um die Reduzierung von Netz-Hierarchien (Access, Distribution, Core – siehe oben). Das Arista-CloudVision-System bietet – analog zu den zuvor beschriebenen Lösungen – ein automatisiertes Netzmanagement-System an.
SD-Lite!
Zusammenfassend bieten alle eben genannten Hersteller (und noch einige weitere) eigene SD-Campuslösungen an. Es muss jedoch festgehalten werden, dass diese Lösungen durchweg auf vollwertigen Netzkomponenten ohne reduzierte Ressourcen betrieben werden. Einer der Kerngedanken von SDN ist somit bisher von keinem namhaften Hersteller umgesetzt worden. Nichtsdestotrotz setzen die Hersteller auf intelligentere Netze als Marketing-Argument. Alle Lösungen verfolgen ähnliche Ziele, obgleich jede Lösung eine andere Kombination von Verfahren nutzt.
Jedes Unternehmen steht vor der Entscheidung, ob, wann und wie es auf ein Software-basiertes Netz setzt. Wir werden über die interessanten Entwicklungen im Bereich der Software-basierten Netzlösungen weiter berichten.
Teile diesen Eintrag