Warum Access Networking zu Software-defined Access wird
Nach Jahren des Stillstands braucht das Access-Layer-Netzwerk eine Rundumerneuerung. Die Implementierung von SDA-basierten Konfigurationen dürfte ein guter Ansatzpunkt sein.
In der Welt von Campus Access Networking sind Änderungen immer nur langsam gekommen. Die Protokolle und Paradigmen von Routing und Switching in den Schichten, die wir früher Core Layer und Distribution Layer nannten – sowie die Netzwerkverbindungen im weiteren Sinne –, haben ebenfalls kaum Änderungen erfahren. Doch diese wenigen Änderungen stachen umso mehr ins Auge.
Die vereinzelten und schrittweisen Änderungen beim Access Networking betrafen im Allgemeinen graduelle Geschwindigkeitssteigerungen. Sicherlich hat sich das Übertragungsmedium gewandelt – von Koax- über Twisted-Pair-Kabel bis hin zur Wireless-Kommunikation. Doch abgesehen davon werden Sie sonst nicht viel anderes bemerkt haben.
Noch auffallender sind die fehlenden Änderungen bei dem, was im Hintergrund der Bereitstellung des Access Layers geschieht. Wir sind zwischen verschiedenen Ideen hin- und hergesprungen, etwa Segmentierung und virtuelle LANs (VLAN), aber virtuelles Routing und Forwarding wurde in machen Kreisen favorisiert – jedenfalls zeitweilig. Darüber hinaus haben wir mit QoS-Paradigmen (Quality of Service) gespielt, als Voice over IP (VoIP) sich durchsetzte. Und viele Methoden, um 802.1x-Bereitstellungen zu erleichtern, sind gleichfalls populär geworden.
Doch erst in jüngerer Zeit beginnen wir, unsere Aufmerksamkeit in Richtung Access Delivery zu richten und darüber nachzudenken, welche Vorteile es uns bringen soll. Nach Jahren der Stagnation sind sich offenbar alle einig, dass wir Nachholbedarf haben, der möglichst schnell gedeckt werden muss.
Access Networking und der Wandel zu SDA
Es gab einmal eine Zeit, da konnte man allem Möglichen ein i voranstellen – iPhone, iPod, iPad –, das Ganze schick verpacken und verkaufen, völlig unabhängig von Qualität oder Nützlichkeit. Das entsprechende Paradigma in der IT-Welt ist seit geraumer Zeit das Prädikat Software-defined. Schmücken Sie beliebige Dinge mit diesem Begriff, und Sie können eine Menge Produkte verkaufen.
Bis vor kurzem allerdings war der Access Layer des Networking Stacks in der Regel immun gegen das Etikett Software-defined. Das änderte sich mit dem Aufkommen von Software-defined Access (SDA).
Marketing-Taktik einmal beiseitegelassen, spiegeln die aktuellen SDA-Tools und -Plattformen die Möglichkeit von sinnvoller Technologie mit soliden Anwendungsfällen, die sich unter der Oberfläche verbergen, wider. Um zu verstehen, warum die Produkte nützlich sind – und von so vielen Anbietern beworben werden –, muss man verstehen, was wir mit Software-defined Access meinen. Was versuchen diese Produkte zu erreichen, und welche Probleme wollen sie lösen?
Die Netzwerke der letzten 20 Jahre sind robust, solide und gut verstanden – und extrem schwerfällig, was Änderungen angeht.
Auf einer oberen Ebene kann SDA bedeuten, dass Access Switches nicht primär von Onboard-Software, sondern in Form einer zentralen Controller-Software konfiguriert und gesteuert werden. Demzufolge wird Software, die sich auf Hardware – den Switches – befindet, nun von einer anderen Software gesteuert, die sich auf einer anderen Hardware befindet. Das mag wie Wortklauberei klingen, aber der SDA-Ansatz besitzt deutliche Unterschiede, die ihn zu einem nützlichen Paradigma machen, das sich auf viele unserer modernen Policy-Herausforderungen anwenden lässt.
Neu gedacht: Access Networking mit einheitlichem Ansatz
Die Netzwerke der letzten 20 Jahre sind robust, solide und gut verstanden – und extrem schwerfällig, was Änderungen angeht. Wenn wir heutzutage über Agility, schnelle Problemlösungen und Flexibilität sprechen, erfüllen Netzwerke diese Anforderungen nicht ganz.
Die folgenden Beispiele verdeutlichen diesen Stillstand im Netzwerkbereich:
Richtlinien für drahtlose und drahtgebundene Kommunikation gelten als zwei unterschiedliche Sachen, selbst wenn es um denselben User auf demselben Gerät geht.
Die Bereitstellung neuer Geräte verläuft langsam bei der Erstkonfiguration und Integration in aktuelle Deployments.
Das Change Management ist überfrachtet.
Die Quality of Service (QoS) lässt sich fast nie korrekt anwenden oder ändern, nachdem sie einmal eingerichtet wurde.
Alle genannten Szenarien erfolgen manuell. Das heißt, wir führen unsere Aufgaben geräteweise durch und hoffen, dass wir unsere Konfiguration nicht verhunzen und das Netzwerk lahmlegen. Unsere Netzwerke haben in der Vergangenheit immer gut funktioniert, so ähnlich wie Pferdefuhrwerke gut funktioniert haben, bevor das Auto aufkam.
Durch die Auslagerung der Netzwerklogik an einen separaten Controller – sozusagen das Übertragen des Gehirns auf einen anderen Körper – ermöglichen wir eine gewisse Abstrahierung und Skalierung und können die zuvor angesprochenen Probleme möglicherweise lösen. Mit anderen Worten: Wir sind in der Lage, unsere Policies für das Netzwerk, anstatt für das Gerät zu entwickeln.
Das Resultat ist ein intuitiverer Ansatz, wenn wir die Befähigung unserer User als primäres Anliegen und nicht als notwendiges Übel betrachten. Unser Netzwerk kann jetzt zu einer Einheit werden. Unsere Zugriffs-, Audit-, Sicherheits- und Service-Policies können zusammenwirken, um den wahren Zweck von Netzwerk-Traffic zu unterstützen: Katzenvideos, Internetmeme und den gelegentlichen geschäftlichen Traffic.
Hinweis der Redaktion: Im nächsten Artikel dieser zweiteiligen Serie über Software-defined Access Networking werfen wir einen Blick auf die Vorteile und Nachteile von SDA.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
Nächste Schritte
Essential Guide: Einführung in Software-defined Networking
