HowtoForge

Software Defined Networking (SDN) – Architektur und Rolle von OpenFlow

von ·

In unserem vorherigen Artikel hatten wir einen guten Überblick über die Technologie SDN, warum sie benötigt wird und wie die IT-Industrie sie einsetzt. Nun, lassen Sie uns eine Schicht tiefer gehen und die Architektur des SDN und die Rolle des Openflow-Protokolls bei der Implementierung der Technologie verstehen.

SDN besteht im Wesentlichen aus drei Schichten:

  1. Anwendungsschicht
  2. Kontrollschicht
  3. Infrastrukturschicht

Lassen Sie uns versuchen, diese Schichten im Bottom-to-Up-Ansatz zu verstehen.

Infrastrukturschichtbesteht aus verschiedenen Netzwerkgeräten, die das zugrunde liegende Netzwerk bilden, um den Netzwerkverkehr weiterzuleiten. Es könnte sich um eine Reihe von Netzwerk-Switches und Routern im Rechenzentrum handeln. Diese Schicht wäre die physische Schicht, über die die Netzwerkvirtualisierung durch die Steuerschicht (wo SDN-Controller sitzen und das zugrunde liegende physische Netzwerk verwalten) festgelegt würde.

Kontrollschichtist das Land der Kontrollebene, in dem sich eine intelligente Logik in SDN-Controllern zur Steuerung der Netzwerkinfrastruktur befindet. Dies ist der Bereich, in dem jeder Netzwerkanbieter daran arbeitet, eigene Produkte für SDN-Controller und Frameworks zu entwickeln. Hier in dieser Schicht wird eine Menge Geschäftslogik in den Controller geschrieben, um verschiedene Arten von Netzwerkinformationen, Zustandsdetails, Topologiedetails, Statistikdetails und mehr zu holen und zu pflegen.

Da der SDN-Controller für die Verwaltung von Netzwerken bestimmt ist, muss er über eine Steuerlogik für die reale Netzwerkanwendung verfügen – Fälle wie Switching, Routing, L2 VPN, L3 VPN, Firewall-Sicherheitsregeln, DNS, DHCP und Clustering. Mehrere Netzwerkanbieter und sogar Open-Source-Communities arbeiten an der Implementierung dieser Use-Cases in ihren SDN-Controllern. Sobald sie implementiert sind, stellen diese Dienste ihre APIs (typischerweise REST-basiert) der oberen Schicht (Application Layer) zur Verfügung, was Netzwerkadministratoren das Leben leicht macht, die dann Apps auf SDN-Controllern verwenden, um das zugrunde liegende Netzwerk zu konfigurieren, zu verwalten und zu überwachen.Die Steuerschicht liegt in der Mitte und zeigt zwei Arten von Schnittstellen – Northbound und Southbound.

  • Northbound-Schnittstelleist für die Kommunikation mit der oberen, Anwendungsschicht gedacht und wird im Allgemeinen durch REST-APIs von SDN-Controllern realisiert. SOutbound-Interfaceist für die Kommunikation mit der unteren, Infrastrukturschicht der Netzwerkelemente gedacht und wird im Allgemeinen durch southbound-Protokolle – Openflow, Netconf, Ovsdb, etc. realisiert.

Anwendungsschichtist ein offener Bereich, um so viele innovative Anwendungen wie möglich zu entwickeln, indem das gesamte Netzwerk genutzt wird.Informationen über Netzwerktopologie, Netzwerkstatus, Netzwerkstatistiken, etc. Es kann mehrere Arten von Anwendungen geben, die entwickelt werden können, wie z.B. Anwendungen in den Bereichen Netzwerkautomatisierung, Netzwerkkonfiguration und -management, Netzwerküberwachung, Netzwerkfehlerbehebung, Netzwerkrichtlinien und Sicherheit. Solche SDN-Anwendungen können verschiedene End-to-End-Lösungen für reale Unternehmens- und Rechenzentrumsnetzwerke bieten. Netzwerkanbieter entwickeln ihre SDN-Anwendungen. Zum Beispiel hat Brocade folgende sehr nützliche Anwendungen:

  • Brocade Strömungsoptimierer
  • Brocade Virtueller Router
  • Brocade Netzwerkberater

HPE ist auch ein Anbieter mit SDN App Store, der auch viele SDN Apps von verschiedenen Unternehmen enthält. Zum Beispiel:

  • HPE Netzwerkoptimierer
  • HPE Netzwerk-Protektor
  • HPE Netzwerk-Visualisierer
  • NEC UNC für HP SDN VAN Steuerung
  • Aricent SDN Lastausgleichsanlage
  • TechM Smart Flow Steuerung
  • TechM Server Load Balancer für den Lastenausgleich

Wie wir Openflow in einem früheren Artikel kurz angesprochen haben, möchten wir nun Details der southbound-Kommunikation von der Kontrollschicht zur Infrastrukturschicht (Netzwerk-Switches) über das Openflow-Protokoll behandeln.

Openflow ist die Standardspezifikation der Open Networking Foundation (ONF) und entwickelt sich im Laufe der Zeit mit Unterstützung verschiedener Anforderungen der aktuellen weltweiten Vernetzung. Die aktuelle Version des Openflow-Protokolls ist 1.5.1.

Openflow ist ein Protokoll, das eine Standardspezifikation für die Kommunikation zwischen SDN-Controller und Netzwerkgeräten (typischerweise Switches) enthält. Es ermöglicht Routerentscheidungen durch SDN-Controller und Weiterleitungsregeln, wobei Sicherheitsregeln auf Switches im zugrunde liegenden Netzwerk gedrückt werden.

SDN-Controller und -Switches müssen Openflow-Spezifikationen implementieren, damit sie die gemeinsame Sprache der Openflow-Nachrichten verstehen können. Um Netzwerk-Switches zu steuern, schiebt der SDN-Controller Regeln in Switches, so dass sie Entscheidungen treffen können, wenn der Netzwerkverkehr sie trifft. Switches müssen solche Regeln in der Openflow-Tabelle pflegen. Gemäß Openflow werden solche Regeln als „flows“ bezeichnet und in „flow tables“ gespeichert.

Im Großen und Ganzen tragen Flüsse drei Arten von Informationen:

  1. Abgleichsfelder: Sie definieren Kriterien für die Übereinstimmung von Paketen basierend auf ihren Headerfeldern – L2 (Quell-Ziel-Ethernet-Adressen, VLAN-ID, VLAN-Priorität, etc.), L3 (IPv4/IPv6 Quell-Zieladresse, Protokolltyp, DSCP, etc.), L4-Felder (TCP/UDP/SCTP Quell-Ziel-Port), ARP-Felder, ICMP-Felder, MPLS-Felder, etc.
  2. Aktionen: Sie definieren, was mit einem Paket zu tun ist, wenn es den Kriterien entspricht. Aktionen wären wie Drop, Forward auf irgendeinem Port des Switches, Paketmodifikation (Push/Pop VLAN ID, Push/Pop MPLS Label, Inkrement/Dekrement IP TTL), Forward auf bestimmte Warteschlangen des Ports, etc.
  3. Zähler: um zu verfolgen, wie viele Pakete dem Flow zugeordnet wurden.

Genauer gesagt, enthalten Bewegungen einige weitere Informationen, die in den Openflow-Spezifikationen weiter überprüft werden können.

Openflow-Kanal oder -Verbindung ist eine Einrichtung zwischen Switch und Controller, so dass der Controller mit dem Switch kommunizieren kann, um ihn zu konfigurieren, zu verwalten und zu überwachen. Gemäß der Openflow-Spezifikation läuft Openflow auf TCP- oder TLS-Verbindung und der Controller wartet auf die Verbindung auf dem 6653-Port, wobei erwartet wird, dass Switch die Verbindung initiiert und eine Verbindungsanforderung an den Controller sendet.

Optional kann die Verbindung auch von der Steuerungsseite aus initiiert werden, und in diesem Fall befindet sich der Switch im passiven Modus, um auf die Verbindung zu warten. Egal von welcher Seite, es wäre ein normaler TCP- oder TLS-Verbindungsaufbau, sobald er hergestellt ist, werden Openflow-Nachrichten über TCP- oder TLS-Verbindung ausgetauscht. Zum Beispiel, unten ist der Befehl von Open Source Openflow virtuellen Switch (OpenVswitch), um eine TCP-Verbindung mit dem Controller herzustellen:

ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653

Hier ist 192.168.56.101 die Controller-IP und 6653 der Controller-Port, an dem er auf die Verbindung wartet.

Openflow definiert verschiedene Nachrichten, um die Kommunikation zwischen Switch und Controller zu ermöglichen, einschließlich Verbindungsaufbau-Meldungen, Konfigurationsmeldungen, Switch-Statistikmeldungen, Keep-Alive-Meldungen, asynchrone Ereignismeldungen, Fehlermeldungen, Experimentiermeldungen und mehr.

Lassen Sie uns kurz über Openflow-Meldungen sprechen:

  • Sobald die TCP-Verbindung hergestellt ist, wird die Openflow HELLO-Nachricht zwischen beiden Entitäten ausgetauscht, um die Openflow-Version zu verhandeln, auf der die weitere Kommunikation stattfindet. Es ist notwendig, da es möglich sein kann, dass Switch und Controller auf verschiedenen Openflow-Versionen laufen. Beide werden sich auf die höchste unterstützte Version einigen.
  • Nachdem die Versionsverhandlung abgeschlossen ist, sendet die Steuerung zunächst eine Openflow-Feature-Anforderungsnachricht, um hauptsächlich die Datenpfad-ID des Switches als Antwortnachricht zu erhalten und zu bestimmen, welche Features der Switch unterstützt.
  • Um den Switch so zu konfigurieren, dass er den Netzwerkverkehr bewältigt, können Openflow-Nachrichten wie Flow-Einträge vom Controller gesendet werden. Diese werden in den Durchflusstabellen innerhalb der Schalter gepflegt.
  • Um Flow-Einträge zu gruppieren, können Gruppen vom Controller durch Gruppennachrichten konfiguriert werden, die in Gruppentabellen in Switches gespeichert werden können.
  • Um Statistikdetails vom Switch zu erhalten, können Openflow-Nachrichten wie Flow-Statistiken, Port-Statistiken, Warteschlangenstatistiken, Gruppenstatistiken, Tabellenstatistiken usw. vom Controller gesendet werden.
  • Um die Lebendigkeit der Verbindung zu überprüfen, können Echoanfragen und Antworten gesendet werden. Openflow-Meldungen können entweder von der Steuerung oder vom Switch gesendet werden.
  • Asynchrone Openflow-Meldungen wie das Entfernen von Flussregeln aus dem Switch, Konfiguration mit Fehler beim Switch, Port Up/Down-Status vom Switch, etc. können vom Switch an den Update Controller gesendet werden.

Bis jetzt haben wir die SDN-Architektur, ihre Schichten und die Rolle von Openflow durchlaufen, um das SDN-Kernprinzip zur Trennung der Steuerebene von der Datenebene zu realisieren. Jetzt müssen wir sehen, wie der Controller in der Lage wäre, Openflow zur Konfiguration und Verwaltung des zugrunde liegenden Netzwerks zu verwenden.

Grundsätzlich müsste der Controller einen Plugin-Code von Openflow implementieren, mit dem er Openflow-Nachrichten an und von Openflow-Switches im zugrunde liegenden Netzwerk senden, empfangen und verstehen kann.

Um Openflow-Switches zu konfigurieren, muss der Controller Flow-Regeln in Openflow-Tabellen von Switches einfügen, auf deren Grundlage letzterer den Netzwerkverkehr bewältigen kann, der sie trifft. Openflow-Nachrichten für Flow-Einträge haben einen großen Satz von Tupelfeldern für Abgleichskriterien (L2, L3, L4-Felder, etc.).) von Paketen, die aus dem Netzwerk kommen, was insgesamt bei der Konfiguration von ACL-Regeln, Sicherheitsrichtlinienregeln, QoS-Ratenbegrenzungsregeln, Routingregeln, Portspiegelungsregeln und Paketänderungsregeln helfen würde.

Um Openflow-Switches zu überwachen, stellt Openflow verschiedene Anforderungs- und Antwortnachrichten zur Verfügung, um Switch- und Netzwerkstatistiken-Informationen und Ereignismeldungen an den Controller zu holen, um ihn über manuelle Änderungen oder Fehler auf der Switch-Seite zu informieren, einschließlich Flow removed event, Portstatus UP/DOWN Änderungen und mehr.

Um einige herstellerspezifische Aufgaben an Openflow-Switches durchzuführen, stellt Openflow experimentelle Nachrichten zur Verfügung, bei denen die Hersteller die Freiheit haben, den Nachrichtentext zu definieren und benutzerdefinierte Informationen zwischen Steuerung und Switches auszutauschen. So wird Openflow von vielen SDN-Anwendungen genutzt, um Lösungen für eine einfache Netzwerksteuerung und -verwaltung bereitzustellen.

This article is co-authored by Tarun Thakur.

Referenzen:

Das könnte dich auch interessieren …