Im vorangegangenen Ausgabe Ich habe ein Framework zur Netzwerkautomatisierung beschrieben. Laut Rückmeldungen einiger Personen hat dieser erste Ansatz das Problem bereits in gewisser Weise aufgedröselt. Und das freut mich sehr, denn unser Ziel im Prozess ist es nicht, Ansible mit Python-Skripten zu überladen, sondern ein System aufzubauen.

Dieses Framework legt die Reihenfolge fest, in der wir uns mit dem Thema auseinandersetzen werden.
Und die Netzwerkvirtualisierung, der dieser Bericht gewidmet ist, passt nicht wirklich in das Thema ADSM, wo wir die Automatisierung untersuchen.

Aber lassen Sie uns einen anderen Blickwinkel einnehmen.

Schon lange nutzen viele Dienste ein und dasselbe Netzwerk. Im Fall eines Kommunikationsanbieters sind das 2G, 3G, LTE, DSL und B2B zum Beispiel. Im Beispiel eines Rechenzentrums: Konnektivität für verschiedene Kunden, Internet, Blockspeicher, Objektspeicher.

Und alle Dienste verlangen, dass sie voneinander isoliert sind. So entstanden Overlay-Netzwerke.

Und alle Dienste wollen nicht darauf warten, dass eine Person sie manuell konfiguriert. So entstanden Orchestratoren und SDN.

Der erste Ansatz zur systematischen Netzwerkautomatisierung, genauer gesagt eines Teils davon, wurde schon lange unternommen und in vielen Bereichen umgesetzt: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

Damit werden wir uns heute beschäftigen.

Inhalt

Gründe
Terminologie
Underlay – physisches Netzwerk
Overlay – virtuelles Netzwerk
- Overlay von ToR
- Overlay vom Host
- Am Beispiel von Tungsten Fabric
  - Kommunikation innerhalb einer einzigen physischen Maschine
  - Kommunikation zwischen VMs, die auf verschiedenen physischen Maschinen liegen
  - Ausgang zur Außenwelt
FAQ
Fazit
Nützliche Links

Gründe

Und da wir gerade darüber sprechen, sollten wir die Voraussetzungen für die Netzwerkvirtualisierung erwähnen. Tatsächlich begann dieser Prozess nicht erst gestern.

Wahrscheinlich haben Sie schon oft gehört, dass das Netzwerk immer der trägste Teil eines jeden Systems war. Und das stimmt in jeder Hinsicht. Das Netzwerk ist die Basis, auf die alles aufbaut, und Veränderungen daran sind ziemlich schwierig – die Dienste tolerieren es nicht, wenn das Netzwerk ausfällt. Oft kann die Stilllegung eines Knotens einen großen Teil der Anwendungen betreffen und viele Kunden beeinträchtigen. Aus diesem Grund kann das Network-Team Widerstand gegen Veränderungen leisten – weil es derzeit irgendwie funktioniert (wir möglicherweise sogar nicht wissen, wie), und nun muss etwas Neues konfiguriert werden, und es ist unklar, wie sich das auf das Netzwerk auswirken wird.

Um nicht darauf warten zu müssen, dass Netzwerktechniker VLANs bereitstellen und Dienste nicht an jedem Knoten im Netzwerk konfigurieren müssen, haben die Menschen Overlay-Netze erfunden — überlagerte Netzwerke — von denen es eine große Vielfalt gibt: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE usw.

Ihre Anziehungskraft liegt in zwei einfachen Dingen:

Es müssen nur die Endknoten konfiguriert werden — die Transitknoten müssen nicht berührt werden. Dies beschleunigt den Prozess erheblich und ermöglicht es manchmal sogar, die Abteilung für Netzwerkinfrastruktur aus dem Prozess der Einführung neuer Dienste herauszuhalten.
Die Last ist tief in den Headern verborgen — die Transitknoten müssen nichts darüber wissen, über die Adressierung auf den Hosts, über die Routen des Overlay-Netzes. Das heißt, es müssen weniger Informationen in den Tabellen gespeichert werden, was bedeutet, dass einfachere/günstigere Geräte verwendet werden können.

In dieser nicht ganz vollständigen Ausgabe plane ich nicht, alle möglichen Technologien zu analysieren, sondern eher den Rahmen der Funktionsweise von Overlay-Netzen im Rechenzentrum zu beschreiben.

Die gesamte Serie wird ein Rechenzentrum beschreiben, das aus Reihen homogener Racks besteht, in denen die gleiche Serverhardware installiert ist.

Auf dieser Hardware werden virtuelle Maschinen/Container/serverlose Dienste betrieben, die die Dienste realisieren.

Terminologie

Im Verlauf Server werde ich das Programm benennen, das die Serverseite der Client-Server-Kommunikation umsetzt.

Physische Maschinen in Racks werden wir "Server" nennen nicht machen wir.

Eine physische Maschine ist ein x86-Computer, der im Rack installiert ist. Der am häufigsten verwendete Begriff Hostist.Lass uns sie „Maschine Host.

Hypervisor nennen oder

Virtuelle Maschine eine Anwendung, die auf einer physischen Maschine läuft und physische Ressourcen emuliert, auf denen virtuelle Maschinen betrieben werden. Manchmal wird in der Literatur und im Internet das Wort „Hypervisor“ als Synonym für „Host“ verwendet.ist das Betriebssystem, das auf einer physischen Maschine über dem Hypervisor läuft. Für uns im Rahmen dieses Zyklus ist es nicht so wichtig, ob es sich tatsächlich um eine virtuelle Maschine oder einfach um einen Container handelt. Wir werden dies „«

VM nennen.

Multitenancy oder Multi-Hosting ist die Nutzung einer und derselben Anwendung durch verschiedene Clients/Dienste. Dabei wird die Isolation der Clients durch die Architektur der Anwendung und nicht durch separat gestartete Instanzen erreicht.

ToR — Top of the Rack Switch — Ein Rack-Switch, an den alle physischen Maschinen angeschlossen sind.

Neben der ToR-Topologie praktizieren verschiedene Anbieter End of Row (EoR) oder Middle of Row (obwohl Letzteres eine vernachlässigbare Seltenheit ist, und ich habe die Abkürzung MoR nicht gesehen).

Unterliegendes Netzwerk oder unterliegendes Netzwerk oder Underlay — physische Netzwerkinfrastruktur: Switches, Router, Kabel.

Overlay-Netzwerk oder überlagertes Netzwerk oder Overlay — ein virtuelles Netzwerk von Tunneln, das über der physischen Infrastruktur arbeitet.

L3-Fabrik oder IP-Fabrik — eine beeindruckende menschliche Erfindung, die es ermöglicht, bei Gesprächen STP nicht zu wiederholen und TRILL nicht zu lernen. Ein Konzept, in dem das gesamte Netzwerk bis zur Zugangsebene ausschließlich L3 ist, ohne VLANs und folglich ohne große, ausgedehnte Broadcast-Domänen. Woher das Wort „Fabrik“ kommt, werden wir im nächsten Teil klären.

SDN — Software Defined Network. Bedarf kaum einer Einführung. Ein Ansatz zur Netzwerkverwaltung, bei dem Änderungen im Netzwerk nicht von einem Menschen, sondern von einem Programm vorgenommen werden. Bedeutet normalerweise, dass der Control Plane außerhalb der Endnetzgeräte auf einen Controller ausgelagert wird.

NFV — Network Function Virtualization — Virtualisierung von Netzwerkgeräten, die davon ausgeht, dass Teile der Netzwerkfunktionen als virtuelle Maschinen oder Container betrieben werden können, um die Einführung neuer Dienste zu beschleunigen, Service Chaining zu organisieren und eine einfachere horizontale Skalierbarkeit zu ermöglichen.

VNF — Virtuelle Netzwerkfunktion. Ein spezifisches virtuelles Gerät: Router, Switch, Firewall, NAT, IPS/IDS usw.

Ich vereinfache die Beschreibung absichtlich auf eine spezifische Umsetzung, um den Leser nicht zu verwirren. Für eine gründlichere Lektüre verweise ich auf den Abschnitt Links. Außerdem verspricht Roma Gorgi, der diesen Artikel wegen Ungenauigkeiten kritisiert, eine separate Ausgabe über Technologien der Server- und Netzwerkvirtualisierung zu schreiben, die tiefer und aufmerksamer auf Details eingeht.

Die meisten Netzwerke heute lassen sich klar in zwei Teile unterteilen:

Unterlage — ein physisches Netzwerk mit stabiler Konfiguration.
Overlay — eine Abstraktion über der Unterlage zur Isolierung von Mandanten.

Das gilt sowohl für den Fall von Rechenzentren (die wir in diesem Artikel behandeln werden) als auch für ISPs (die wir nicht behandeln werden, weil dies bereits in SDN). Bei Unternehmensk Netzwerken ist die Situation natürlich etwas anders.

Bild mit Fokus auf Netzwerk:

Unterlage

Underlay ist ein physikalisches Netzwerk: Hardware-Switches und Kabel. Geräte im Underlay wissen, wie sie zu den physischen Maschinen gelangen.

Es basiert auf standardisierten Protokollen und Technologien. Nicht zuletzt deshalb, weil Hardware-Geräte bis heute mit proprietärer Software arbeiten, die weder die Programmierung des Chips noch die Implementierung eigener Protokolle zulässt, was eine Kompatibilität mit anderen Anbietern und eine Standardisierung erforderlich macht.

Aber jemand wie Google kann es sich leisten, eigene Switches zu entwickeln und von gängigen Protokollen abzuweichen. Aber LAN_DC ist nicht Google.

Underlay ändert sich vergleichsweise selten, da seine Aufgabe die grundlegende IP-Konnektivität zwischen physischen Maschinen ist. Underlay weiß nichts über die darüber laufenden Dienste, Clients oder Tenants – es muss nur das Paket von einer Maschine zur anderen transportieren.
Underlay könnte beispielsweise so aussehen:

IPv4+OSPF
IPv6+ISIS+BGP+L3VPN
L2+TRILL
L2+STP

Das Underlay-Netzwerk wird klassisch konfiguriert: CLI/GUI/NETCONF.

Manuell, per Skripten, mit proprietären Tools.

In der nächsten Artikelreihe wird Underlay ausführlicher behandelt.

Overlay

Overlay ist ein virtuelles Netzwerk von Tunneln, das über das Underlay gezogen wird. Es ermöglicht den VMs eines Kunden die Kommunikation untereinander und gewährleistet gleichzeitig die Isolation von anderen Kunden.

Die Daten des Kunden werden in irgendwelche tunneling Headers inkapsuliert, um über das gemeinsame Netzwerk übertragen zu werden.

So können die VMs eines Kunden (eines Dienstes) über Overlay miteinander kommunizieren, ohne zu wissen, welchen tatsächlichen Weg das Paket nimmt.

Overlay könnte beispielsweise so aussehen, wie ich oben bereits erwähnt habe:

GRE-Tunnel
VXLAN
EVPN
L3VPN
GENEVE

Das Overlay-Netzwerk wird normalerweise über einen zentralen Controller konfiguriert und verwaltet. Von dort aus werden Konfiguration, Control Plane und Data Plane an die Geräte geliefert, die für das Routing und die Inkapsulierung des Kundenverkehrs verantwortlich sind. Etwas unten lassen Sie uns das anhand von Beispielen betrachten.

Ja, das ist SDN in reinster Form.

Es gibt zwei grundlegend unterschiedliche Ansätze zur Organisation von Overlay-Netzwerken:

Overlay von ToR
Overlay vom Host

Overlay von ToR

Overlay kann auf einem Zugriffsswitch (ToR) beginnen, der in einem Rack steht, wie es beispielsweise im Fall einer VXLAN-Fabrik der Fall ist.

Es handelt sich um einen bewährten Mechanismus in ISP-Netzen, den alle Hersteller von Netzwerkgeräten unterstützen.

In diesem Fall muss der ToR-Switch in der Lage sein, verschiedene Dienste entsprechend zu trennen, und der Netzwerkadministrator muss in gewissem Maße mit den Administratoren von virtuellen Maschinen zusammenarbeiten und Änderungen (wenn auch automatisch) an der Gerätekonfiguration vornehmen.

Hier verweise ich den Leser auf den Artikel über VxLAN auf Habré unseren alten Freund @bormoglotx.
In diesem Präsentationen von ENOG beschreibt detailliert Ansätze zum Bau eines Rechenzentrumsnetzwerks mit einer EVPN VXLAN-Fabrik.

Für ein umfassenderes Eintauchen in die Realität kann das Buch von Cisco gelesen werden A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Ich weise darauf hin, dass VXLAN nur eine Methode zur Kapselung ist und die Tunnelterminierung nicht am ToR, sondern am Host stattfinden kann, wie es beispielsweise im Falle von OpenStack der Fall ist.
Allerdings ist eine VXLAN-Fabrik, bei der der Overlay am ToR beginnt, eines der etablierten Designs für Overlay-Netze.

Overlay vom Host

Ein anderer Ansatz ist es, Tunnel an den Endhosts zu beginnen und zu terminieren.
In diesem Fall bleibt das Netzwerk (Underlay) so einfach wie möglich und statisch.
Und der Host führt alle erforderlichen Kapselungen selbst durch.

Hierfür wird es ohne Zweifel erforderlich sein, eine spezielle Anwendung auf den Hosts auszuführen, aber es lohnt sich.

Erstens ist es einfacher, einen Client auf einer Linux-Maschine zu starten oder sagen wir einfach - überhaupt möglich - während man beim Switch wahrscheinlich zunächst auf proprietäre SDN-Lösungen zurückgreifen muss, was die Idee der Multivendor-Fähigkeit untergräbt.

Zweitens kann der ToR-Switch in diesem Fall so einfach wie möglich bleiben, sowohl hinsichtlich des Control Plane als auch des Data Plane. Tatsächlich muss er dann nicht mit dem SDN-Controller kommunizieren und die Netzwerke/ARP-Tabellen aller angeschlossenen Clients speichern - es reicht, die IP-Adresse der physischen Maschine zu kennen, was die Switching/Routing-Tabellen erheblich vereinfacht.

In der ADS-M-Serie wähle ich den Overlay-Ansatz vom Host - im Folgenden werden wir nur darüber sprechen und zur VXLAN-Fabrik nicht zurückkehren.

Am einfachsten lässt sich dies anhand von Beispielen betrachten. Als Versuchsträger nehmen wir die Open-Source-SDN-Plattform OpenContrail, die heute als Tungsten Fabric.

Am Ende des Artikels werde ich einige Überlegungen zur Analogie mit OpenFlow und OpenvSwitch anstellen.

Am Beispiel von Tungsten Fabric

Auf jeder physischen Maschine gibt es vRouter — ein virtueller Router, der über die an ihn angeschlossenen Netzwerke und die zugehörigen Clients Bescheid weiß — im Grunde genommen ein PE-Router. Für jeden Client unterstützt er eine isolierte Routing-Tabelle (lies: VRF). Und tatsächlich ermöglicht der vRouter Overlay-Tunneling.

Ein wenig mehr über den vRouter — am Ende des Artikels.

Jede VM, die auf dem Hypervisor läuft, verbindet sich über den vRouter dieser Maschine über TAP-Schnittstelle.

TAP — Terminal Access Point — eine virtuelle Schnittstelle im Linux-Kernel, die Netzwerkinteraktionen ermöglicht.

Wenn hinter dem vRouter mehrere Netzwerke liegen, wird für jedes von ihnen eine virtuelle Schnittstelle erstellt, der eine IP-Adresse zugewiesen wird — dies wird die Standard-Gateway-Adresse sein.
Alle Netzwerke eines Clients werden in eine VRF (eine Tabelle) eingeordnet, unterschiedliche in verschiedene.
Ich möchte hier einen Vorbehalt machen, dass nicht alles so einfach ist, und sende den neugierigen Leser ans Ende des Artikels.

Damit vRouter miteinander kommunizieren können, und somit auch die dahinterliegenden VMs, tauschen sie Routing-Informationen über den SDN-Controller.

Um in die Außenwelt zu gelangen, gibt es einen Ausgangspunkt aus der Matrix — das Gateway des virtuellen Netzwerks VNGW — Virtual Network Gateway (mein Terminus).

Lassen Sie uns einige Kommunikationsbeispiele betrachten — und es wird klarer.

Kommunikation innerhalb einer einzigen physischen Maschine

VM0 möchte ein Paket an VM2 senden. Angenommen, dies sind VMs eines Clients.

Data Plane

VM-0 hat eine Standardroute zu ihrer Schnittstelle eth0. Das Paket wird dorthin gesendet.
Diese Schnittstelle eth0 ist tatsächlich virtuell mit dem virtuellen Router vRouter über die TAP-Schnittstelle tap0 verbunden.
Der vRouter analysiert, über welche Schnittstelle das Paket eingegangen ist, also zu welchem Client (VRF) es gehört, und vergleicht die Empfängeradresse mit der Routing-Tabelle dieses Clients.
Festgestellt, dass der Empfänger auf demselben Gerät über einen anderen Port ist, sendet der vRouter das Paket einfach ohne zusätzliche Header an ihn — dafür gibt es bereits einen ARP-Eintrag auf dem vRouter.

Das Paket gelangt in diesem Fall nicht ins physische Netzwerk — es wird innerhalb des vRouters geroutet.

Control Plane

Der Hypervisor informiert die virtuelle Maschine beim Start:

Ihre eigene IP-Adresse.
Die Standardroute — über die IP-Adresse des vRouters in diesem Netzwerk.

Dem vRouter wird über eine spezielle API vom Hypervisor mitgeteilt:

Dass eine virtuelle Schnittstelle erstellt werden muss.
Welche Virtuelle Netzwerk sie (VM) erstellen soll.
An welches VRF ihr (VN) zugeordnet werden soll.
Der statische ARP-Eintrag für diese VM – hinter welchem Interface sich ihre IP-Adresse befindet und an welche MAC-Adresse sie gebunden ist.

Und erneut wurde das tatsächliche Interaktionsverfahren zum besseren Verständnis der Konzepte vereinfacht.

Somit sieht der vRouter alle VMs eines Kunden auf dieser Maschine als direkt verbundene Netzwerke und kann selbst zwischen ihnen routen.

VM0 und VM1 gehören jedoch verschiedenen Kunden an und befinden sich somit in unterschiedlichen vRouter-Tabellen.

Ob sie direkt miteinander kommunizieren können, hängt von den vRouter-Einstellungen und dem Netzwerkdesign ab.
Wenn beide Kunden-VMs öffentliche Adressen nutzen oder NAT auf dem vRouter erfolgt, kann direkte Routen auf dem vRouter hergestellt werden.

Andernfalls könnte es zu Überlappungen der Adressräume kommen – man muss über den NAT-Server gehen, um eine öffentliche Adresse zu erhalten, was dem Zugang zu externen Netzwerken ähnelt, die weiter unten behandelt werden.

Kommunikation zwischen VMs, die auf verschiedenen physischen Maschinen liegen

Data Plane

Der Anfang ist genau der gleiche: VM-0 sendet ein Paket an den Empfänger VM-7 (172.17.3.2) über ihr Default-Gateway.
Der vRouter empfängt es und sieht diesmal, dass der Empfänger auf einer anderen Maschine ist und über den Tunnel Tunnel0 erreichbar ist.
Zuerst fügt er ein MPLS-Label hinzu, das das entfernte Interface identifiziert, damit der vRouter auf der anderen Seite bestimmen kann, wohin dieses Paket weitergeleitet werden soll, ohne zusätzliche Loopbacks.
Tunnel0 hat die Quelle 10.0.0.2, der Empfänger: 10.0.1.2.
Der vRouter fügt GRE- (oder UDP-) Header und eine neue IP-Adresse zum ursprünglichen Paket hinzu.
In der Routing-Tabelle des vRouters gibt es eine Standardroute über die Adresse ToR1 10.0.0.1. Dorthin wird es gesendet.
ToR1, als Teil des Underlay-Netzes, weiß (zum Beispiel über OSPF), wie man zu 10.0.1.2 gelangt, und sendet das Paket auf der Route. Beachten Sie, dass hier ECMP aktiviert ist. In der Abbildung gibt es zwei Next-Hops, und unterschiedliche Datenströme werden anhand des Hashs aufgeteilt. In einer echten Fabrik wären es wahrscheinlich eher 4 Next-Hops.
Er weiß dabei nicht, was sich unter dem externen IP-Header befindet. Das bedeutet, dass tatsächlich unter der IP ein Sandwich aus IPv6 über MPLS über Ethernet über MPLS über GRE über über über GRE liegen kann.
Auf der empfangenden Seite entfernt der vRouter GRE und versteht anhand des MPLS-Labels, an welches Interface dieses Paket weitergeleitet werden soll, zerlegt es und sendet es in originaler Form an den Empfänger.

Control Plane

Beim Start der Maschine geschieht alles, was oben beschrieben wurde.

Und zusätzlich passiert noch Folgendes:

Für jeden Kunden weist der vRouter ein MPLS-Label zu. Dies ist ein Service-Label für L3VPN, nach dem die Kunden innerhalb einer physikalischen Maschine getrennt werden.
Tatsächlich wird das MPLS-Label vom vRouter immer ohne Ausnahme zugewiesen – schließlich ist im Voraus nicht bekannt, dass die Maschine nur mit anderen Maschinen hinter demselben vRouter interagiert, und wahrscheinlich ist das sogar nicht der Fall.
Der vRouter verbindet sich mit dem SDN-Controller über das BGP-Protokoll (oder ein ähnliches – im Fall von TF ist es XMPP 0_o).
Über diese Sitzung informiert der vRouter den SDN-Controller über die Routen zu den angeschlossenen Netzwerken:
- Netzwerkadresse
- Kapselungsmethode (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS-Label des Kunden
- Seine IP-Adresse als nexthop
Der SDN-Controller erhält solche Routen von allen angeschlossenen vRoutern und spiegelt sie an andere. Das heißt, er fungiert als Route Reflector.

Das Gleiche passiert auch in umgekehrter Richtung.

Overlay kann sich jede Minute ändern. So geschieht es in öffentlichen Clouds, wenn Kunden regelmäßig ihre virtuellen Maschinen starten und stoppen.

Der zentrale Controller übernimmt alle komplexen Aufgaben zur Aufrechterhaltung der Konfiguration und zur Kontrolle der Switching/Routing-Tabellen auf dem vRouter.

Grob gesagt, verbindet sich der Controller mit allen vRoutern über BGP (oder ein ähnliches Protokoll) und überträgt einfach die Routing-Informationen. BGP hat beispielsweise bereits eine Address-Family zur Übertragung der Kapselungsmethode. MPLS-in-GRE oder MPLS-in-UDP.

Dabei wird die Konfiguration des Underlay-Netzwerks auf keinen Fall verändert, die übrigens um ein Vielfaches schwieriger zu automatisieren ist, und es ist einfacher, es mit einem ungeschickten Handgriff kaputt zu machen.

Ausgang zur Außenwelt

Irgendwo muss die Simulation enden, und die virtuelle Welt muss die reale Welt betreten. Und es wird ein Telefondienst benötigt.

Es werden zwei Ansätze verfolgt:

Ein Hardware-Router wird installiert.
Ein Appliance, das die Funktionen eines Routers implementiert, wird gestartet (ja, ja, nach SDN haben wir auch mit VNF zu tun). Nennen wir es virtuellen Gateway.

Der Vorteil des zweiten Ansatzes liegt in der kostengünstigen horizontalen Skalierbarkeit – wenn die Leistung nicht ausreicht, wird einfach eine weitere virtuelle Maschine mit einem Gateway gestartet. Auf jeder physikalischen Maschine, ohne die Notwendigkeit, nach freien Racks, Einheiten, Stromanschlüssen zu suchen, Hardware zu kaufen, zu transportieren, zu installieren, zu verkabeln, zu konfigurieren und dann auch noch defekte Komponenten auszutauschen.
Die Nachteile eines virtuellen Gateways bestehen darin, dass eine physische Routereinheit dennoch um ein Vielfaches leistungsstärker ist als eine mehrkernige virtuelle Maschine, und ihre Software, die an die Hardwarebasis angepasst ist, deutlich stabiler funktioniert (nein). Es ist schwer zu leugnen, dass eines der Software-Hardware-Komplexe einfach funktioniert und nur Konfigurationen benötigt, während der Start und die Wartung eines virtuellen Gateways eine Aufgabe für starke Ingenieure sind.

Mit einem Fuß blickt das Gateway in das virtuelle Overlay-Netzwerk, ähnlich wie eine gewöhnliche virtuelle Maschine, und kann mit allen anderen VMs interagieren. Dabei kann es die Netzwerke aller Kunden terminieren und entsprechend die Routing zwischen ihnen durchführen.

Mit dem anderen Fuß blickt das Gateway bereits in das Backbone-Netzwerk und weiß, wie es ins Internet gelangt.

Data Plane

Der Prozess sieht also so aus:

VM-0, mit dem Standard weiterhin auf denselben vRouter, sendet ein Paket mit einem Ziel im äußeren Netzwerk (185.147.83.177) an das Interface eth0.
Der vRouter empfängt dieses Paket und führt eine Lookup des Zieladresses in der Routingtabelle durch – er findet die Standardeinstellung über das Gateway VNGW1 über Tunnel 1.
Er sieht auch, dass es sich um einen GRE-Tunnel mit SIP 10.0.0.2 und DIP 10.0.255.2 handelt und dass zunächst das MPLS-Label dieses Kunden gesetzt werden muss, das VNGW1 erwartet.
Der vRouter verpackt das ursprüngliche Paket in die MPLS-, GRE- und neuen IP-Header und sendet es an die Adresse ToR1 10.0.0.1 standardmäßig.
Das Underlay-Netzwerk liefert das Paket an das Gateway VNGW1.
Das Gateway VNGW1 entfernt die tunneling Header GRE und MPLS, sieht die Zieladresse, konsultiert seine Routingtabelle und erkennt, dass sie ins Internet führt – also über Full View oder Default. Bei Bedarf führt es eine NAT-Übersetzung durch.
Zwischen VNGW und dem Border kann ein gewöhnliches IP-Netzwerk existieren, was kaum der Fall ist.
Es kann ein klassisches MPLS-Netzwerk (IGP+LDP/Rsvp TE) sein, es kann eine Rückfabrik mit BGP LU oder ein GRE-Tunnel von VNGW zum Border durch ein IP-Netzwerk sein.
Wie dem auch sei, VNGW1 führt die notwendigen Kapselungen durch und sendet das ursprüngliche Paket in Richtung Border.

Der Datenverkehr in die entgegengesetzte Richtung durchläuft die gleichen Schritte in umgekehrter Reihenfolge.

Der Border wirft das Paket bis zu VNGW1.
Dieser entpackt es, schaut auf die Zieladresse und sieht, dass sie über Tunnel Tunnel1 (MPLSoGRE oder MPLSoUDP) erreichbar ist.
Entsprechend wird ein MPLS-Label, der GRE/UDP-Header und eine neue IP angehängt und an sein ToR3 10.0.255.1 gesendet.
Die Zieladresse des Tunnels ist die IP-Adresse des vRouters, hinter dem die Ziel-VM steht – 10.0.0.2.
Das Underlay-Netzwerk liefert das Paket an den entsprechenden vRouter.
Der Ziel-vRouter entfernt GRE/UDP, bestimmt über das MPLS-Tag das Interface und sendet das reine IP-Paket an sein TAP-Interface, das mit eth0 der VM verbunden ist.

Control Plane

VNGW1 etabliert eine BGP-Nachbarschaft mit dem SDN-Controller, von dem er alle Routing-Informationen zu den Clients erhält: hinter welcher IP-Adresse (vRouter) sich welcher Client befindet und mit welchem MPLS-Tag er identifiziert wird.

Analog informiert er den SDN-Controller über die Standardroute mit dem Tag dieses Clients und gibt sich selbst als nexthop an. Diese Standardroute gelangt anschließend zu den vRoutern.

Auf VNGW erfolgt in der Regel die Aggregation von Routen oder NAT-Übersetzung.

Und in die andere Richtung gibt er in der Sitzung mit den Border Routern oder Route Reflectoren genau diese aggregierte Route weiter. Von ihnen erhält er die Standardroute oder Full-View oder etwas anderes.

Was die Kapselung und den Verkehrsaustausch angeht, unterscheidet sich VNGW nicht vom vRouter.
Wenn man den Bereich etwas erweitert, können zu VNGW und vRoutern auch andere Netzwerkgeräte hinzugefügt werden, wie Firewalls, Traffic-Bereinigungs- oder Anreicherungsfarmen, IPS und so weiter.

Und durch die schrittweise Erstellung von VRF und die korrekte Ankündigung von Routen kann man den Verkehr so leiten, wie man möchte, was als Service Chaining bezeichnet wird.

Das heißt, auch hier fungiert der SDN-Controller als Route Reflector zwischen VNGW, vRoutern und anderen Netzwerkgeräten.

Aber tatsächlich übermittelt der Controller auch Informationen über ACL und PBR (Policy Based Routing), wodurch bestimmte Datenströme nicht dem vorgegebenen Routing folgen.

FAQ

Warum machst du immer einen Kommentar zu GRE/UDP?

Nun, das kann man sagen, ist spezifisch für Tungsten Fabric – man kann es auch ganz ignorieren.

Aber wenn man davon ausgeht, hat selbst TF, als es noch OpenContrail war, beide Kapselungen unterstützt: MPLS in GRE und MPLS in UDP.

UDP hat den Vorteil, dass man im Source Port des Headers sehr einfach eine Hash-Funktion von den ursprünglichen IP+Proto+Port kodieren kann, was eine Lastverteilung ermöglicht.

Im Fall von GRE gibt es leider nur die externen IP- und GRE-Header, die für den gesamten eingekapselten Verkehr gleich sind, und von Lastverteilung kann nicht gesprochen werden – nur wenige können so tief in das Paket schauen.

Bis vor kurzem konnten Router, wenn sie dynamische Tunnel unterstützen, nur MPLSoGRE, und erst kürzlich haben sie MPLSoUDP gelernt. Daher muss man immer einen Hinweis zur Möglichkeit zweier verschiedener Kapselungen geben.

Um gerecht zu sein, sollte erwähnt werden, dass TF auch L2-Konnektivität über VXLAN unterstützt.

Du hast versprochen, Parallelen zu OpenFlow zu ziehen.
Die drängen sich wirklich auf. Der vSwitch im gleichen OpenStack macht sehr ähnliche Dinge, verwendet VXLAN, das übrigens auch einen UDP-Header hat.

Im Data Plane arbeiten sie ungefähr gleich, der Control Plane unterscheidet sich jedoch erheblich. Tungsten Fabric nutzt XMPP zur Übertragung von Routing-Informationen an den vRouter, während in OpenStack OpenFlow verwendet wird.

Kannst du ein wenig mehr über den vRouter erzählen?
Er teilt sich in zwei Teile: vRouter Agent und vRouter Forwarder.

Ersterer wird im User Space des Host-Betriebssystems gestartet und kommuniziert mit dem SDN-Controller, indem er Informationen zu Routen, VRF und ACL austauscht.

Der zweite implementiert das Data Plane – normalerweise im Kernel Space, kann aber auch auf SmartNICs – Netzwerkarten mit CPU und einem separaten programmierbaren Switching-Chip – gestartet werden, was die CPU-Last des Host-Servers verringert und das Netzwerk schneller und vorhersehbarer macht.

Es ist auch möglich, dass der vRouter eine DPDK-Anwendung im User Space ist.

Der vRouter Agent überträgt die Einstellungen an den vRouter Forwarder.

Was ist das für ein Virtual Network?
Ich erwähnte zu Beginn des Artikels das VRF, dass jeder Tenant an sein eigenes VRF gebunden ist. Und wenn dies für ein oberflächliches Verständnis der Funktionsweise des Overlay-Netzwerks ausreichend war, müssen bei der nächsten Iteration weitere Erklärungen gegeben werden.

In der Regel wird in Virtualisierungsmechanismen die Entität Virtual Network (dies kann als Eigenname betrachtet werden) getrennt von den Clients/Tenants/virtuellen Maschinen eingeführt – es ist ein ganz eigenständiges Element. Und dieses Virtual Network kann über Schnittstellen an einen Tenant, einen anderen, zwei oder wohin auch immer angeschlossen werden. So wird zum Beispiel Service Chaining realisiert, wenn der Datenverkehr durch bestimmte Knoten in der richtigen Reihenfolge geleitet werden muss, indem die Virtual Networks einfach in der richtigen Reihenfolge erstellt und zugewiesen werden.

Deshalb gibt es keine direkte Entsprechung zwischen Virtual Network und Tenant.

Fazit

Dies ist eine eher oberflächliche Beschreibung der Funktionsweise eines virtuellen Netzwerks mit Overlays von einem Host und einem SDN-Controller. Aber welche Virtualisierungsplattform Sie auch immer nehmen, sie wird ähnlich arbeiten, ob es sich um VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric oder Juniper Contrail handelt. Sie werden sich hinsichtlich der Arten von Kapselungen und Headern sowie der Protokolle zur Lieferung von Informationen an die Endgeräte unterscheiden, aber das Prinzip des programmierbar konfigurierbaren Overlay-Netzwerks, das über einem vergleichsweise einfachen und statischen Underlay-Netzwerk arbeitet, bleibt gleich.
Man kann sagen, dass im Bereich der Schaffung privater Clouds heutzutage SDN auf Basis von Overlay-Netzen gesiegt hat. Das bedeutet jedoch nicht, dass OpenFlow keinen Platz in der modernen Welt hat – es wird in OpenStack und auch in VMWare NSX verwendet, soweit ich weiß, nutzt Google es zur Konfiguration des Underlay-Netzes.

Weiter unten habe ich Links zu detaillierteren Materialien eingefügt, falls Sie das Thema vertiefen möchten.

Und was ist mit unserem Underlay?

Im Grunde genommen nichts. Es hat sich die ganze Zeit über nicht verändert. Alles, was es im Falle eines Overlays von einem Host tun muss, ist, die Routen und ARP-Einträge zu aktualisieren, wenn vRouter/VNGW erscheinen oder verschwinden, und die Pakete zwischen ihnen zu transportieren.

Lassen Sie uns eine Liste von Anforderungen an das Underlay-Netzwerk formulieren.

Es muss in der Lage sein, ein Routing-Protokoll zu implementieren, in unserem Fall – BGP.
Es sollte eine breite Bandbreite haben, idealerweise ohne Over-Subscription, um zu vermeiden, dass Pakete aufgrund von Überlastungen verloren gehen.
Die Unterstützung von ECMP ist ein integraler Bestandteil der Fabrik.
Es muss QoS garantieren können, einschließlich ausgeklügelter Funktionen wie ECN.
Die Unterstützung von NETCONF ist eine Investition in die Zukunft.

Ich habe der Funktionsweise des Underlay-Netzwerks hier nur wenig Zeit gewidmet. Das liegt daran, dass ich mich in dieser Serie genau darauf konzentrieren werde, während wir das Overlay nur am Rande berühren werden.

Offensichtlich schränke ich uns alle stark ein, indem ich als Beispiel ein Rechenzentrumsnetzwerk verwende, das auf der Clos-Fabrik mit reiner IP-Routing und einem Overlay von einem Host basiert.

Ich bin jedoch überzeugt, dass man jedes Netzwerk mit einem Design formal beschreiben und automatisieren kann. Ich verfolge hier nur das Ziel, Ansätze zur Automatisierung zu verstehen, und nicht, um alle generell zu verwirren, während ich das Problem im Allgemeinen löse.

Im Rahmen von ADS-M planen Roman Gorge und ich, eine eigene Ausgabe zur Virtualisierung von Rechenressourcen und deren Wechselwirkungen mit der Netzwerkvirtualisierung zu veröffentlichen. Bleiben Sie dran.

Nützliche Links

Tungsten Fabric Architektur.
about:cloud. 6 Stunden über Yandex.Cloud, einschließlich der Behandlung des virtuellen Netzwerks auf TF.
Was ist Open vSwitch?
Einführung in VxLAN.
RFC 7348. Virtual eXtensible Local Area Network (VXLAN): Ein Rahmen für die Overlay virtueller Layer 2 Netzwerke über Layer 3 Netzwerke.
Scaleway-Ansatz zu VXLAN EVPN Fabric. Hier wird das gesamte DC-Netzwerk behandelt, einschließlich Underlay, Overlay, Ansätze zum Multi-Homing und Management.

Danke

Roman Gorge — ehemaliger Moderator des Podcasts linkmeup und jetzt Experte für Cloud-Plattformen. Für Kommentare und Korrekturen. Wir erwarten bald seinen vertieften Artikel über Virtualisierung.
Alexander Shalimov — mein Kollege und Experte für die Entwicklung virtueller Netzwerke. Für Kommentare und Korrekturen.
Valentin Sinitsin — mein Kollege und Experte für Tungsten Fabric. Für Kommentare und Korrekturen.
Artem Tschernobaj — Illustrator bei linkmeup. Danke für das KDPV.
Alexander Limonov. Für das Meme «automato».

Quelle: habr.com