Benötigen Software-Defined-Networks noch Routing-Protokolle?

Software-Defined-Networks (SDNs) arbeiten nicht unabhängig voneinander und müssen mit anderen SDN-Netzen zusammenarbeiten. Über welche Schnittstellen kommunizieren die unterschiedlichen SDNs und welche Informationen teilen die Netze miteinander?

Ein SDN besteht in der Regel aus einer oder mehreren Weiterleitung-Domänen. Auf einem Unternetzwerk lassen sich beliebige Overlay-Netzwerke einrichten. Die darunter liegenden Netzstrukturen basieren entweder auf der Layer-2- (Switches) oder der Layer-3- (Router) Technologie. Das SDN-Netzwerk sorgt oberhalb der Netzwerkebene für eine logische Overlay-Struktur zwischen den angeschlossenen Netz- und Rechnerressourcen. Es können mehrere logische Netzwerke von einem einzelnen SDN-Steuerungssystem verwaltet werden. Somit entkoppelt die logische Overlay-Domaine von den physikalischen Strukturen der darunter liegenden Technologien.

board-1709190_1920Innerhalb einer Overlay-Domäne trifft der SDN-Controller alle Weiterleitungsentscheidungen. Jede logische Weiterleitungs-Domain funktioniert somit wie ein Layer-2-bis-7-Switch bei der die Weiterleitungsentscheidungen anhand der in jedem Paket enthaltenen Layer-2-bis-7-Informationen ermittelt werden.

Jede logische Weiterleitungs-Domain arbeitet folglich wie ein großer Switch und benötigt für die Kommunikation mit anderen Netzwerken die entsprechenden Schnittstellen. Deshalb müssen wir uns folgende Frage stellen: Welche Informationen müssen zwischen der lokalen Weiterleitungs-Domain und dem Rest des Netzes ausgetauscht werden, damit eine reibungslose Kommunikation zwischen den Netzelementen möglich wird?

Die einfachste Antwort lautet: Die auf der Schicht 2 verfügbaren Erreichbarkeitsinformationen werden hierfür genutzt. Dies bedeutet jedoch nicht, dass das Spanning-Tree-Protocol (STP) oder das Rapid-Spanning-Tree-Protocol (RSTP) zum Einsatz kommen. Diese Protokolle weisen in der Praxis große Probleme auf und sind inzwischen auch völlig veraltet. Nutzen die benachbarten Teile des Netzes die TRILL- oder Fabricpath-Mechanismen, dann sollte das SDN mit diesen Protokollen interagieren. Dieses Szenario wird beispielsweise in einem größeren Datenzentrum genutzt, in dem die SDN-Domänen nur ein ein kleiner Teil des Gesamtnetzes umfasst. Darüber hinaus können die eingesetzten Anwendungen den Einsatz der jeweiligen Weiterleitungsmechanismen (Layer 2 oder Layer 3) vorschreiben.

Deshalb lautet die andere Antwort auf die Frage: Die Erreichbarkeitsinformationen werden auf der Ebene 3 (Routing) zwischen den angeschlossenen Netzwerken geteilt. Hierzu stehen die üblichen Layer-3-Routing-Protokolle wie beispielsweise RIPv2, OSPF, EIGRP oder BGP zur Verfügung.

Die Auswahl des infrage kommenden Routing-Protokolls bestimmt die Stellung der SDN-Domänen zum Rest des Netzwerks. Agiert der Rest des Netzes zu den SDN-Domänen als eine Reihe von Peer-Routern bzw. 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, 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 externen 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 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. (mh)