In unserem vorherigen Artikel hatten wir einen guten Überblick über SDN als Technologie, warum es benötigt wird und wie die IT-Branche es annimmt. Lassen Sie uns nun eine Ebene tiefer gehen und die Architektur von SDN und die Rolle des Openflow-Protokolls bei der Implementierung der Technologie verstehen.
SDN besteht im Großen und Ganzen aus drei Schichten:
- Anwendungsebene
- Steuerungsebene
- Infrastrukturebene
Lassen Sie uns versuchen, diese Schichten von unten nach oben zu verstehen.
Infrastrukturebene besteht 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 würden) gelegt würde.
Steuerungsebene ist das Land der Kontrollebene, in dem sich intelligente Logik in SDN-Controllern befinden würde, um die Netzwerkinfrastruktur zu steuern. Dies ist der Bereich, in dem jeder Netzwerkanbieter daran arbeitet, seine eigenen Produkte für SDN-Controller und -Frameworks zu entwickeln. Hier in dieser Schicht wird viel Geschäftslogik in den Controller geschrieben, um verschiedene Arten von Netzwerkinformationen, Zustandsdetails, Topologiedetails, Statistikdetails und mehr abzurufen und zu verwalten.
Da der SDN-Controller zum Verwalten von Netzwerken dient, muss er über eine Steuerlogik für reale Netzwerkanwendungsfälle wie Switching, Routing, L2-VPN, L3-VPN, Firewall-Sicherheitsregeln, DNS, DHCP und Clustering verfügen. Mehrere Netzwerkanbieter und sogar Open-Source-Communities arbeiten an der Implementierung dieser Anwendungsfälle in ihren SDN-Controllern. Sobald sie implementiert sind, legen diese Dienste ihre APIs (normalerweise REST-basiert) der oberen Schicht (Anwendungsschicht) offen, was Netzwerkadministratoren das Leben erleichtert, 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 stellt zwei Arten von Schnittstellen bereit – Northbound und Southbound.
- Northbound-Schnittstelle :ist für die Kommunikation mit der oberen Anwendungsschicht gedacht und würde im Allgemeinen durch REST-APIs von SDN-Controllern realisiert. S Ausgangsschnittstelle :ist für die Kommunikation mit der unteren Infrastrukturschicht von Netzwerkelementen gedacht und würde im Allgemeinen durch Southbound-Protokolle realisiert – Openflow, Netconf, Ovsdb usw.
Anwendungsebene ist ein offener Bereich, um so viele innovative Anwendungen wie möglich zu entwickeln, indem alle Netzwerkinformationen über Netzwerktopologie, Netzwerkstatus, Netzwerkstatistiken usw. genutzt werden. Es kann verschiedene Arten von Anwendungen geben, die entwickelt werden können, z. B. solche im Zusammenhang mit 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 bereitstellen. Netzwerkanbieter entwickeln ihre eigene Reihe von SDN-Anwendungen. Brocade hat zum Beispiel folgende sehr nützliche Anwendungen:
- Brocade Flow Optimizer
- Virtueller Brocade-Router
- Brocade-Netzwerkberater
HPE ist auch ein Anbieter mit SDN App Store, der viele SDN-Apps von verschiedenen Unternehmen enthält. Zum Beispiel:
- HPE Network Optimizer
- HPE Network Protector
- HPE Network Visualizer
- NEC UNC für HP SDN VAN-Controller
- Aricent SDN-Load-Balancer
- Intelligente TechM-Flusssteuerung
- TechM-Server-Load-Balancer
Da wir Openflow im vorherigen Artikel kurz angesprochen haben, würden wir jetzt Details der Southbound-Kommunikation von der Steuerungsebene zur Infrastrukturebene (Netzwerk-Switches) über das Openflow-Protokoll behandeln.
Openflow war maßgeblich an der Revolution von SDN in dem Sinne beteiligt, dass es der Schlüssel zur Demonstration der Trennung der Steuerungsebene von der Datenebene war. Openflow ist die von der Open Networking Foundation (ONF) bereitgestellte Standardspezifikation und entwickelt sich im Laufe der Zeit mit Unterstützung für verschiedene Anforderungen der aktuellen weltweiten Vernetzung weiter. Die aktuelle Version des Openflow-Protokolls ist 1.5.1.
Openflow ist ein Protokoll, das Standardspezifikationen für die Kommunikation zwischen SDN-Controller und Netzwerkgeräten (normalerweise Switches) vorgibt. Es ermöglicht, dass Routing-Entscheidungen von SDN-Controllern getroffen werden und Weiterleitungsregeln und Sicherheitsregeln auf Switches im zugrunde liegenden Netzwerk übertragen werden.
SDN-Controller und -Switches müssen Openflow-Spezifikationen implementieren, damit sie die gemeinsame Sprache von Openflow-Nachrichten verstehen können. Um Netzwerk-Switches zu steuern, schiebt der SDN-Controller Regeln in Switches, damit sie entscheiden können, wann Netzwerkverkehr auf sie trifft. Switches müssen solche Regeln in der Openflow-Tabelle verwalten. Laut Openflow werden solche Regeln als „Flows“ bezeichnet und in „Flow-Tabellen“ gespeichert.
Im Allgemeinen transportieren Flüsse drei Arten von Informationen:
- Match-Felder:Sie definieren Kriterien für den Abgleich von Paketen basierend auf ihren Header-Feldern – L2 (Ethernet-Adressen des Quellziels, VLAN-ID, VLAN-Priorität usw.), L3 (IPv4/ IPv6-Quellzieladresse, Protokolltyp, DSCP usw.), L4-Felder (TCP/UDP/SCTP-Quellzielport), ARP-Felder, ICMP-Felder, MPLS-Felder usw.
- Aktionen:Sie definieren, was mit einem Paket zu tun ist, wenn es den Kriterien entspricht. Aktionen wären wie Verwerfen, Weiterleiten an einem Port des Switches, Ändern des Pakets (Push/Pop-VLAN-ID, Push/Pop-MPLS-Label, Inkrementieren/Dekrementieren der IP-TTL), Weiterleiten an eine bestimmte Warteschlange des Ports usw.
- Zähler:um zu verfolgen, wie viele Pakete mit dem Fluss übereinstimmen
Um genau zu sein, Flows enthalten einige weitere Informationen, die in den Openflow-Spezifikationen näher überprüft werden können.
Openflow-Kanal oder -Verbindung ist eine Einrichtung zwischen Switch und Controller, damit der Controller mit dem Switch kommunizieren kann, um ihn zu konfigurieren, zu verwalten und zu überwachen. Gemäß der Openflow-Spezifikation läuft Openflow auf einer TCP- oder TLS-Verbindung und der Controller wartet auf eine Verbindung auf Port 6653. Es wird erwartet, dass der Switch die Verbindung initiiert und eine Verbindungsanfrage an den Controller sendet.
Optional kann die Verbindung auch von der Controller-Seite initiiert werden, und in diesem Fall befindet sich der Schalter im passiven Modus, um auf die Verbindung zu warten. Unabhängig davon, ob es sich um einen normalen TCP- oder TLS-Verbindungsaufbau handelt, werden Openflow-Nachrichten über eine TCP- oder TLS-Verbindung ausgetauscht. Unten sehen Sie beispielsweise den Befehl des virtuellen Open-Source-Switches Openflow (OpenVswitch), um eine TCP-Verbindung mit dem Controller zu initiieren:
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 eine Verbindung warten würde.
Openflow definiert verschiedene Nachrichten, um die Kommunikation zwischen Switch und Controller zu ermöglichen, darunter Verbindungsaufbaunachrichten, Konfigurationsnachrichten, Nachrichten zum Abrufen von Switch-Statistiken, Keep-Alive-Nachrichten, Nachrichten zu asynchronen Ereignissen, Fehlermeldungen, Experimentatornachrichten und mehr.
Lassen Sie uns kurz etwas über Openflow-Nachrichten verstehen:
- Sobald die TCP-Verbindung hergestellt ist, wird eine Openflow-HELLO-Nachricht zwischen beiden Einheiten ausgetauscht, um die Openflow-Version auszuhandeln, auf der die weitere Kommunikation stattfinden wird. Es ist erforderlich, da es möglich ist, dass Switch und Controller auf unterschiedlichen Openflow-Versionen ausgeführt werden. Beide werden sich auf die höchste unterstützte Version einigen.
- Nachdem die Versionsverhandlung abgeschlossen ist, sendet der Controller zuerst eine Openflow-Feature-Request-Nachricht, um hauptsächlich die Datenpfad-ID des Switch in der Antwortnachricht zu erhalten und zu bestimmen, welche Features der Switch unterstützt.
- Um den Schalter so zu konfigurieren, dass er den Netzwerkverkehr handhabt, können Openflow-Nachrichten wie Flow-Einträge vom Controller gesendet werden. Diese werden in Flusstabellen innerhalb von Switches verwaltet.
- 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 von Switch zu erhalten, können Openflow-Nachrichten wie Flussstatistiken, Portstatistiken, Warteschlangenstatistiken, Gruppenstatistiken, Tabellenstatistiken usw. vom Controller gesendet werden.
- Um die Verbindungslebendigkeit zu überprüfen, können Echo-Anforderungen und Antwort-Openflow-Nachrichten entweder von Controller oder Switch gesendet werden.
- Asynchrone Openflow-Meldungen wie das Entfernen der Flussregel vom Switch, Fehler beim Anwenden der Konfiguration vom Switch, Port-Up/Down-Status vom Switch usw. können vom Switch an den Update-Controller gesendet werden.
Bis jetzt haben wir die SDN-Architektur, ihre Schichten und die Rolle von Openflow durchgegangen, um das SDN-Kernprinzip zur Trennung der Steuerungsebene von der Datenebene zu realisieren. Jetzt müssen wir sehen, wie der Controller Openflow verwenden kann, um das zugrunde liegende Netzwerk zu konfigurieren und zu verwalten.
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 Flussregeln in Openflow Tabellen von Switches übertragen, auf deren Grundlage letztere den sie treffenden Netzwerkverkehr verarbeiten können. Die Openflow-Nachricht für Flow-Einträge verfügt über eine große Anzahl von Tupelfeldern für übereinstimmende Kriterien (L2-, L3-, L4-Felder usw.) von Paketen, die aus dem Netzwerk kommen, was insgesamt bei der Konfiguration von ACL-Regeln, Sicherheitsrichtlinienregeln, QoS-Ratenbegrenzungsbandbreitenregeln helfen würde, Routingregeln, Portspiegelungsregeln und Paketänderungsregeln.
Um Openflow-Switches zu überwachen, bietet Openflow verschiedene Anfrage- und Antwortnachrichten zum Abrufen von Switch- und Netzwerkstatistikinformationen und Ereignisnachrichten, um den Controller über manuelle Änderungen oder Fehler zu informieren, die auf der Switch-Seite aufgetreten sind, einschließlich Flow-Entfernungsereignis, Portstatus-UP/DOWN-Änderungen und mehr.
Um einige anbieterspezifische Aufgaben auf Openflow-Switches auszuführen, bietet Openflow experimentelle Nachrichten, bei denen Anbieter die Freiheit haben, den Nachrichtentext zu definieren und benutzerdefinierte Informationen zwischen Controller und Switches auszutauschen. Auf diese Weise wird Openflow von vielen SDN-Anwendungen verwendet, um Lösungen für eine einfache Netzwerksteuerung und -verwaltung bereitzustellen.
This article is co-authored by Tarun Thakur.
Referenzen:
- https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
- https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
- http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/