Kommentar: Software-Defined-Networking
Braucht es noch Routing-Protokolle?
Fortsetzung des Artikels von Teil 1
Welches Routing-Protokoll ist noch sinnvoll in Software-Defined-Networks
Die Auswahl des infrage kommenden Routing-Protokolls wird durch die Stellung der SDN-Domänen zum Rest des Netzwerks bestimmt. Agiert der Rest des Netzes zu den SDN-Domänen als eine Reihe von Peer-Routern beziehungsweise Switches (und umgekehrt), dann sind die klassischen Routing-Protokolle sicher die richtige Wahl. Erfordert die Netzwerkarchitektur jedoch eine saubere Trennung der Routing-Funktionalitäten, dann ist das BGP-Protokoll sicher die bessere Wahl.
In jedem der genannten Fälle arbeiten die Routing- oder Switching-Protokolle auf dem SDN-Controller. Jede SDN-Domain nutzt möglicherweise seine eigenen Routing-Protokolle für die Verbindung mit externen Netzwerken. Auf einem SDN-Controller arbeiten eine oder mehrere Routing/Switching-Instanzen und der Controller verfügt darüber hinaus über virtuelle Schnittstellen in jede Weiterleitungs-Domäne. Aus Sicht der Fehlertoleranz wäre es jedoch besser, wenn die Protokollinstanzen auf separate Hardware-Plattformen arbeiten würden.
Einige Hersteller gehen davon aus, dass die Routing-Protokolle auf dem Controller arbeiten werden. Dies ist so nicht richtig. In der Praxis ist es durchaus denkbar, dass die Routing/Switching-Protokolle als externe Anwendungen ins Netzwerk integriert werden und die Kommunikationsprozesse über den SDN-Controller steuern. In diesem Fall müssen die Routenaktualisierungen von den Switches an den Controller und von dort an die externe Routing-Anwendung weitergeleitet werden. Über das API der Anwendung aktualisiert der externe Routing-Prozess die im Controller integrierte Routing-Information-Base (RIB).
Die Routing-Protokolle können auch in einem SDN Hybridsystem integriert sein. Jeder im Netz integrierte Switch wird dabei entweder durch einen SDN-Controller oder auf Basis eines verteilten Routing-Protokolls gesteuert. Auf ein paar Core-Switches wird das Routing-Protokoll aktiviert und diese tauschen die Routing-Informationen mit externen Systemen aus. Interhalb der SDN-Domaine befüllt der SDN-Controller die Forwarding-Information-Base (FIB). Nur die Core-Switches verfügen in dieser Konfiguration über die Routing-Informationen der externe Ziele. Auf allen Switches außer den Core-Switches werden die Standard-FIB-Einträge durch den SDN-Controller vorgenommen. Kann kein FIB-Eintrag für das entsprechende Ziel gefunden werden, wird das Paket an einen der Core-Switches übermittelt. Dies wirkt wie die Default-Route bei traditionellen Routing-Protokollen.
Natürlich wird es sicher Kritiker der oben beschriebenen Ansätze geben. Einige Leute sehen keine Notwendigkeit für den Einsatz von Routing-Protokollen in SDN-Umgebungen. Stattdessen soll ein statisches Routing auf den SDN-Links konfiguriert werden und die SDN-Default Routen zeigen auf den Übergangspunkt zwischen den Netzinstanzen. Diese Konfiguration hat in der Praxis jedoch einige Probleme, da die statische Konfiguration zur Außenseite der Netzinstanz nicht redundant ausgelegt werden kann. Der SDN-Controller könnte intelligent genug sein, um eine Lastverteilung über mehrere Ausgangs-Links vorzunehmen, aber die statischen Routen würden eine solche Lösung verhindern.
Welchen Lösungsansatz sollte ein Unternehmen bei der Realisierung von SDN in mehreren Teilen des Netzes (beispielsweise in zwei Rechenzentren) verfolgen? Einige Netzarchitekten werden sicher argumentieren, dass nur ein SDN realisiert werden sollte, weil nur dadurch ein optimales Routing zwischen den Rechenzentren gewährleistet ist. Andere Netzarchitekten argumentieren mit dem Gegenteil, trennen die beiden SDN-Domänen und begrenzen dadurch die Größe der Fehlerdomänen.
Netzausfälle haben unter Umständen triviale Ursachen (man denke an Routing- oder STP-Schleifen oder Routen in schwarze Löcher) und trotzdem extreme Auswirkungen. Momentan verfügt der Markt über zu wenige Erfahrung mit Software-Defined-Networks und deren Verhalten in der Praxis. Die individuellen SDN-Störungen müssen erst noch analysiert und deren Auswirkungen verstanden werden.
Fazit
In der Netzwerktechnik gibt es für jedes Problem mehrere Lösungen. Mühsam haben wir gelernt, dass jedes Protokoll seine Vor- und Nachteile aufweist. Bei Software-Defined-Networks wird dies nicht anders sein, als bei den klassischen Netzwerktechnologien. SDN ist kein revolutionär neues Konzept, deshalb werden die „alten“ Technologien weiterhin genutzt werden. Zur Kopplung unterschiedlicher SDN-Instanzen stehen die bekannten Layer-3- und Layer-2-Technologien zur Verfügung. Mit der Realisierung größerer SDN-Netze werden die Netzwerker lernen, wie man SDN-Domänen miteinander sinnvoll koppelt.
- Braucht es noch Routing-Protokolle?
- Welches Routing-Protokoll ist noch sinnvoll in Software-Defined-Networks
Lesen Sie mehr zum Thema
