Was ist GENEVE?

Meine erste Erfahrung mit einem Overlay-Tunnel machte ich im Jahr 2003, als ich an einem Projekt zur Erstellung eines transparenten Proxys auf Basis von Squid und dem Cisco WCCP (Web Cache Communication Protocol) arbeitete. Ein Teil der Konfiguration zwischen dem Cisco-Router und dem Squid-Proxy musste GRE-Tunnel (Generic Routing Encapsulation) für die Kommunikation verwenden. Damals war mir die Notwendigkeit von Tunnelprotokollen noch nicht ganz klar. Doch heute weiß ich, wie wichtig VLANs in großen mandantenfähigen Clouds sind.

VLANs wurden entwickelt, um den Netzwerkdatenverkehr in kleinere, weniger komplexe Netzwerke zu segmentieren. Der Nachteil besteht darin, dass sie nur über ein festes 12-Bit-Feld verfügen, was bedeutet, dass Sie nur etwa 4000 VLANs in einer Netzwerktopologie haben können. In den späten 1990er und frühen 2000er Jahren waren dies mehr als genug Segmente, um Networking zu unterstützen. Mit dem Anbruch des Cloud-Zeitalters und von Multi-Tenant-Umgebungen entstand jedoch der Bedarf an viel mehr individuellen Netzwerktunneln.

Um dieses Problem anzugehen, haben verschiedene Anbieter verschiedene Lösungen vorgeschlagen: VXLAN (Virtual Extensible LAN), NVGRE (Network Virtualization using Generic Routing Encapsulation) und STT (Stateless Transport Tunneling). Alle drei kapseln Anwendungsdaten in einem neuen größeren festen Header-Feld. Diese Header-Größe beträgt 24 Bit für VXLAN und NVGRE, wobei letzteres hauptsächlich von Microsoft verwendet wird, während STT eine 64-Bit-Header-Größe hat. Keine dieser Kapselungs-Tunneling-Methoden erfordert eine Änderung der Hardware-Netzwerkinfrastruktur, obwohl einige Anbieter Hardware anbieten, mit der die Effizienz der Lösung beschleunigt werden kann. Die Lösungen sind jedoch nicht miteinander kompatibel.

Im aktuellen Zeitalter großer mandantenfähiger Clouds gibt es jedoch Hoffnung. Ein neuer Netzwerkvirtualisierungsstandard ist entstanden: GENEVE (Generic Network Virtualization Encapsulation), der verspricht, die vermeintlichen Einschränkungen der früheren Spezifikationen zu beheben und sämtliche Funktionen von VXLAN, NVGRE und STT zu unterstützen. Viele glauben, dass GENEVE diese früheren Formate schließlich vollständig ersetzen könnte.

Das erklärte Ziel von GENEVE besteht darin, nur ein Encapsulation-Datenformat zu definieren. Im Gegensatz zu den früheren Formaten enthält es keine Informationen oder Spezifikationen für die Control Plane. Die Autoren sagen dazu:

„Die Entscheidung für ein Datenformat hat einen klaren Vorteil: Die meisten Protokolle unterscheiden sich nur oberflächlich, und der doppelte Aufwand ist kaum von Vorteil. Dies gilt jedoch nicht für Control Planes, die sich in sehr grundlegender Weise unterscheiden. Auch die Argumente für eine Standardisierung sind angesichts der großen Vielfalt an Anforderungen, Zielen und Bereitstellungsszenarien weniger klar.

Um diese Ziele zu erreichen, waren sich die GENEVE-Autoren einig, dass das Datenformat so flexibel und erweiterbar wie möglich sein sollte. Während die aktuellen 24-Bit-Tunnel-ID-Felder in VXLAN und NVGRE und 64-Bit in STT mehr als ausreichend sind, um die erforderlichen virtuellen Netzwerke zu spezifizieren, erwarten sie, dass zukünftige Entwicklungsteams dieses Feld so unterteilen werden, dass es außer der Kennung des virtuellen Netzwerks noch weitere Informationen enthalten kann. Sie vergleichen die potenzielle Verwendung dieses Felds mit den Systemstatusinformationen, die derzeit innerhalb von virtualisierten Servern oder zwischen Linecards in einem Chassis-Switch ausgetauscht werden. Sie stellen fest, dass keine feste Feldgröße angegeben werden kann, die für alle möglichen zukünftigen Verwendungen ausreicht. Darüber hinaus orientieren sich die Autoren von GENEVE an vielen anderen Protokollen, die sich als langlebig erwiesen haben. Protokolle wie BGP (Border Gateway Protocol), LLDP (Link Layer Discovery Protocol), IS-IS (Intermediate System – Intermediate System) und viele andere gibt es seit mehreren Jahrzehnten, und sind immer noch so beliebt wie nie zuvor.

Der Grund dafür ist einfach: Sie sind erweiterbar. Sie entwickeln sich im Laufe der Zeit mit neuen Funktionen weiter, nicht durch Überarbeitung der Basisprotokolle, sondern durch das Hinzufügen neuer optionaler Funktionen.

GENEVE-gekapselte Pakete sind für die Übertragung über Standard-Netzwerkgeräte konzipiert. Pakete werden mit Unicast- oder Multicast-Adressierung von einem Tunnel-Endpunkt an einen oder mehrere Tunnel-Endpunkte gesendet. Die Client-Anwendung und der Host, auf dem sie ausgeführt wird, werden in keiner Weise geändert. Anwendungen generieren identische IP-Pakete, so als ob sie über Hardware-Switches und -Router kommunizieren würden. Die im Paket enthaltene Ziel-IP-Adresse ist nur innerhalb des virtuellen Netzwerks des Cloud-Mandanten von Bedeutung. Der Tunnel-Endpunkt kapselt dann das Endbenutzer-IP-Paket im GENEVE-Header und fügt die Tunnel-ID mit der Angabe des virtuellen Netzwerks des Mandanten hinzu, gefolgt von unterschiedlichsten Optionen. Der Header besteht aus Feldern, die angeben, dass es sich um ein GENEVE-Paket handelt, die Gesamtlänge der Optionen, falls vorhanden, die Tunnel-ID und die Optionenreihe. Das fertige Paket wird dann in einem standardmäßigen UDP-Paket, das über IPv4 und IPv6 unterstützt wird, an den Zielendpunkt übertragen. Der empfangende Tunnel-Endpunkt entfernt den Header, interpretiert die enthaltenen Optionen und leitet das Endbenutzerpaket innerhalb des durch die Tunnel-ID angegebenen virtuellen Netzwerks an sein Ziel.

Die GENEVE-Spezifikation bietet Empfehlungen zur Erzielung eines effizienten Betriebs durch Vermeidung von Fragmentierung und Nutzung von ECMP (Equal-Cost Multi-Path) sowie NIC-Hardware-Offload-Funktionen. Die Spezifikation bietet auch Optionen zur Unterstützung von differenzierten Services und expliziten Datenstau-Benachrichtigungen. Die Autoren erwarten keine Probleme, wenn GENEVE und eine oder mehrere der anderen Kapselungsmethoden auf demselben System verwendet werden. GENEVE-Tunnelendpunkte kommunizieren nur untereinander, und Pakete werden von der Netzwerkinfrastruktur genauso wie andere UDP-Pakete verarbeitet. Das Datenformat unterstützt die Funktionen von VXLAN, NVGRE und STT, sodass die Verwendung der drei früheren Formate möglicherweise zurückgeht. Da kein Control Plane-Protokoll angegeben ist, erwarten die Autoren, dass es auch andere Protokolle unterstützt, die mit den anderen Kapselungsmethoden verwendet werden. Ein wesentlicher Vorteil gegenüber anderen Kapselungsmethoden ist das flexible Optionsformat von GENEVE und die Verwendung der IANA (Internet Assigned Numbers Authority) zur Bezeichnung von Optionsklassen. Entwicklungsteams können beliebig viele oder wenige Optionen dynamisch hinzufügen, ohne auf 24-Bit beschränkt zu sein oder den Overhead eines 64-Bit-Felds zu verursachen, wenn nur ein Bruchteil dieser Größe benötigt wird.

Der Übergang zu GENEVE erfolgt nicht schlagartig. Die anderen Kapselungsmethoden werden seit einiger Zeit verwendet, und mehrere Methoden können innerhalb desselben Systems ausgeführt werden. GENEVE wird jedoch als Standard-Tunneling-Protokoll für OVN (Open Virtual Network) übernommen, das wiederum in zukünftigen OpenStack-Releases als Implementierung von OVS (OpenvSwitch) beworben wird.

Die Erfahrung mit großen mandantenfähigen Clouds wächst weiter, und keine einzelne Kapselungsmethode kann sich zum akzeptierten Standard durchsetzen. GENEVE wird jedoch mit seinem flexiblen Optionsformat und der Unterstützung der Funktionen anderer Methoden ein starker Kandidat für eine breite Akzeptanz sein.

Benjamin Schmaus ist Red Hat Cloud TAM in der Region NA Central. Er beschäftigt sich seit 1998 mit Linux und hat Geschäftsumgebungen in einer Vielzahl von Branchen unterstützt: Einzelhandel, Verteidigung, Software, Finanzwesen, Schul- und Hochschul-Bildungseinrichtungen. Zuletzt konzentrierte er sich darauf, unseren Kunden die Bereitstellung, den Betrieb und den Support von Red Hat OpenStack Platform und Red Hat Ceph Storage zu ermöglichen.

Ein Red Hat Technical Account Manager (TAM) ist ein spezialisierter Produktexperte, der mit IT-Organisationen zusammenarbeitet, um erfolgreiche Implementierungen strategisch zu planen und optimale Performance und Wachstum zu ermöglichen. Der TAM ist Teil der erstklassigen Organisation für Customer Experience and Engagement von Red Hat und bietet proaktive Beratung und Anleitung, damit Sie potenzielle Probleme erkennen und lösen können, bevor sie auftreten. Sollte ein Problem auftauchen, kümmert sich Ihr TAM darum und stellt die besten Ressourcen bereit, um es so schnell wie möglich und mit minimalen Unterbrechungen für Ihr Unternehmen zu lösen.