Ma première expérience avec un tunnel de superposition remonte à 2003, lorsque je travaillais sur un projet de création d'un proxy transparent basé sur Squid et le protocole Cisco WCCP (Web Cache Communication Protocol). Une partie de la configuration entre le routeur Cisco et le proxy Squid devait utiliser des tunnels GRE (Generic Routing Encapsulation) pour la communication. À l'époque, je ne comprenais pas tout à fait la nécessité des protocoles de tunnel, mais je connais maintenant leur importance, car les réseaux VLAN dans les grands clouds multi-clients sont défectueux.

Les VLAN ont été élaborés pour segmenter le trafic réseau en réseaux plus petits et moins complexes. L'inconvénient est qu'ils n'ont qu'un champ fixe de 12 bits, ce qui signifie qu'il ne peut y avoir qu'environ 4 000 VLAN dans une topologie de réseau. À la fin des années 90 et au début des années 2000, ces segments étaient largement suffisants pour gérer la mise en réseau. Cependant, avec l'avènement de l'ère du cloud et des environnements multi-clients, le besoin de tunnels réseau individuels est devenu beaucoup plus important.

Pour résoudre ce problème, divers fournisseurs ont proposé diverses solutions : VXLAN (Virtual Extensible LAN), NVGRE (Network Virtualization using Generic Routing Encapsulation) et STT (Stateless Transport Tunneling). Ces trois technologies encapsulent les données d'applications dans un nouveau champ d'en-tête fixe plus grand. La taille de l'en-tête est de 24 bits pour VXLAN et NVGRE, cette dernière technologie étant principalement utilisée par Microsoft, tandis que STT a une taille d'en-tête de 64 bits. Aucune de ces méthodes de tunnellisation d'encapsulation ne nécessite de modification de l'infrastructure réseau matérielle, bien que certains fournisseurs proposent du matériel qui améliore l'efficacité de la solution. Cependant, ces solutions ne sont pas compatibles entre elles.

Avec les grands clouds multi-clients actuels, tout n'est toutefois pas perdu. Une nouvelle norme de virtualisation du réseau a émergé : GENEVE (Generic Network Virtualization Encapsulation) qui promet de remédier aux limites perçues des spécifications précédentes et de prendre en charge toutes les capacités de VXLAN, NVGRE et STT. Beaucoup pensent que GENEVE pourrait finir par remplacer complètement ces anciens formats.

L'objectif déclaré de GENEVE est uniquement de définir un format de données d'encapsulation. Contrairement aux formats précédents, cette norme n'inclut aucune information ou spécification pour le plan de contrôle. Voici ce que déclarent les auteurs :

« Il y a un avantage évident à choisir un format de données : la plupart des protocoles ne sont différents qu'en surface et il y a peu d'avantages à dupliquer les efforts. Cependant, on ne peut pas en dire autant des plans de contrôle, qui présentent des différences fondamentales. Les arguments en faveur de la standardisation sont également moins évidents compte tenu de la grande diversité des exigences, des objectifs et des scénarios de déploiement. »

Pour atteindre ces objectifs, les auteurs de GENEVE ont convenu que le format des données devait être aussi flexible et extensible que possible. Bien que les champs d'identifiants de tunnel 24 bits actuels dans VXLAN et NVGRE et 64 bits dans STT soient plus que suffisants pour spécifier tous les réseaux virtuels qui seront requis, ils s'attendent à ce que les futurs développeurs souhaitent subdiviser ce champ pour transporter des informations autres que l'identifiant du réseau virtuel. Ils comparent les utilisations potentielles de ce champ aux informations sur l'état du système actuellement échangées au sein des serveurs virtualisés ou entre les cartes de ligne d'un commutateur de châssis. Ils observent qu'aucune taille de champ fixe suffisante pour toutes les futures utilisations possibles ne peut être spécifiée. De plus, les auteurs de GENEVE s'inspirent de nombreux autres protocoles qui se sont avérés durables. Des protocoles tels que BGP (Border Gateway Protocol), LLDP (Link Layer Discovery Protocol), IS-IS (Intermediate System - Intermediate System) et bien d'autres existent depuis plusieurs décennies et sont toujours aussi utilisés.

Et la raison est simple : ils sont extensibles. Ils évoluent au fil du temps avec l'ajout de nouvelles fonctionnalités qui sont optionnelles, sans révision des protocoles de base.

Les paquets encapsulés GENEVE sont conçus pour être transmis via un équipement réseau standard. Les paquets sont envoyés d'un point de terminaison du tunnel à un ou plusieurs points de terminaison du tunnel à l'aide de l'adressage unicast ou multicast. L'application cliente et l'hôte sur lequel elle s'exécute ne sont en aucun cas modifiés. Les applications génèrent des paquets IP identiques comme si elles communiquaient via des commutateurs matériels et des routeurs. L'adresse IP de destination incluse dans le paquet n'est significative que dans le réseau virtuel du client du cloud. Le point de terminaison du tunnel encapsule ensuite le paquet IP de l'utilisateur final dans l'en-tête GENEVE, en ajoutant l'identifiant de tunnel spécifiant le réseau virtuel du client, suivi d'éventuelles options. L'en-tête se compose de champs qui indiquent qu'il s'agit d'un paquet GENEVE, la longueur totale des options, le cas échéant, l'identifiant du tunnel et la liste d'options. Le paquet complet est ensuite transmis au point de terminaison de destination dans un paquet UDP standard qui est pris en charge via IPv4 et IPv6. Le point de terminaison du tunnel récepteur supprime l'en-tête, interprète les options incluses et dirige le paquet de l'utilisateur final vers sa destination dans le réseau virtuel indiqué par l'identifiant du tunnel.

Geneve_VxLAN Headers.jpg

 

La spécification GENEVE indique comment obtenir un fonctionnement efficace en évitant la fragmentation et en tirant parti des fonctions de déchargement matériel ECMP (Equal-cost multi-path) et NIC. La spécification propose également des options pour la prise en charge des services différenciés et de la notification d'encombrement explicite. Les auteurs ne prévoient aucun problème si GENEVE et une ou plusieurs autres méthodes d'encapsulation sont utilisées sur le même système. Les points de terminaison du tunnel GENEVE ne communiquent qu'entre eux et les paquets sont traités par l'infrastructure réseau comme n'importe quel autre paquet UDP. Le format de données prend en charge toutes les capacités de VXLAN, NVGRE et STT, de sorte que l'utilisation des trois anciens formats va finir par diminuer. Étant donné qu'aucun protocole de plan de contrôle n'est spécifié, les auteurs s'attendent à ce qu'il prenne en charge tout protocole utilisé avec les autres méthodes d'encapsulation. L'un des principaux avantages par rapport aux autres méthodes d'encapsulation est le format d'option flexible de GENEVE et le recours à l'IANA (Internet Assigned Numbers Authority) pour désigner les classes d'options. Les développeurs peuvent inclure des options de manière dynamique sans être limités à 24 bits ou s'exposer aux frais liés à un champ 64 bits lorsque seule une fraction de cette taille est nécessaire.

La transition vers GENEVE ne sera pas immédiate. Les autres méthodes d'encapsulation sont utilisées depuis un certain temps et plusieurs méthodes peuvent fonctionner au sein du même système. Cependant, la norme GENEVE est adoptée comme protocole de tunnellisation par défaut pour le projet OVN (Open Virtual Network), qui sera utilisé comme mise en œuvre d'OVS (OpenvSwitch) dans les futures versions d'OpenStack.

L'expérience avec les grands clouds multi-clients continue et aucune méthode d'encapsulation unique ne peut devenir la norme acceptée. Toutefois, GENEVE, avec son format d'option flexible et sa prise en charge de toutes les capacités des autres méthodes, sera un candidat solide pour une adoption à grande échelle.


Want to learn more about edge computing?

Edge computing is in use today across many industries, including telecommunications, manufacturing, transportation, and utilities. Visit our resources to see how Red Hat's bringing connectivity out to the edge.


Benjamin Schmaus est responsable de compte technique Red Hat cloud dans la région centrale d'Amérique du Nord. Il travaille avec Linux depuis 1998 et s'est occupé d'environnements d'entreprise dans divers secteurs : commerce de détail, défense, logiciels, finance, enseignement supérieur et enseignement secondaire. Dernièrement, il s'est attaché à aider nos clients à déployer, à exploiter et à prendre en charge Red Hat OpenStack Platform et Red Hat Ceph Storage.

Un responsable de compte technique Red Hat est un spécialiste produit qui travaille en collaboration avec les services informatiques afin d'établir une stratégie pour réussir les déploiements, ainsi que garantir un niveau optimal de performances et de croissance. Membres de l'excellente division Expérience et engagement des clients de Red Hat, les responsables de compte technique donnent des conseils proactifs pour identifier et résoudre les problèmes potentiels avant qu'ils ne surviennent. Si un problème se produit, votre responsable de compte technique le prendra en charge et y affectera les meilleures ressources afin de le résoudre aussi vite que possible en limitant les perturbations pour votre activité.


About the author

Benjamin Schmaus is a Red Hat Principle Product Manager for Edge Solutions. He has been involved with Linux since 1998 and has supported business environments in a variety of industries: retail, defense, software development, pharmacy, financial, higher education and K-12. His experience in those industries along with various positions within Red Hat have enabled him to have a broad and deep understanding of customer challenges. Most recently, he has been focused on enabling our customers at the edge by driving the Red Hat portfolio to deliver edge solutions that meet their ever diverse needs as they journey through modernization.

Read full bio