4. VXLAN
VXLAN (réseau local virtuel eXtensible, Virtual eXtensible Local Area Network) répond aux exigences ci-dessus de l'infrastructure réseau de centre de données de couche 2 et de couche 3 en présence de VM dans un environnement multi-locataires. Il fonctionne sur l'infrastructure réseau existante et fournit un moyen d'"étendre" un réseau de couche 2. En bref, VXLAN est un schéma de superposition de couche 2 sur un réseau de couche 3. Chaque superposition est appelée segment VXLAN (VXLAN Segment). Seules les VM au sein du même segment VXLAN peuvent communiquer entre elles. Chaque segment VXLAN est identifié par un ID de segment de 24 bits, appelé "identifiant de réseau VXLAN (VXLAN Network Identifier, VNI)". Cela permet jusqu'à 16 M de segments VXLAN de coexister au sein du même domaine administratif.
Le VNI identifie la portée de la trame MAC interne provenant de la VM individuelle. Ainsi, vous pouvez avoir des adresses MAC qui se chevauchent entre les segments mais ne jamais avoir de trafic qui "se croise" puisque le trafic est isolé en utilisant le VNI. Le VNI se trouve dans un en-tête externe qui encapsule la trame MAC interne provenant de la VM. Dans les sections suivantes, le terme "segment VXLAN" est utilisé de manière interchangeable avec le terme "réseau de superposition VXLAN".
En raison de cette encapsulation, VXLAN pourrait également être appelé un schéma de tunneling pour superposer des réseaux de couche 2 sur des réseaux de couche 3. Les tunnels sont sans état, donc chaque trame est encapsulée selon un ensemble de règles. Le point de terminaison du tunnel (point de terminaison de tunnel VXLAN, VXLAN Tunnel End Point ou VTEP) discuté dans les sections suivantes est situé dans l'hyperviseur sur le serveur qui héberge la VM. Ainsi, le VNI et l'encapsulation de tunnel/en-tête externe liés à VXLAN ne sont connus que du VTEP -- la VM ne le voit jamais (voir Figure 1). Notez qu'il est possible que les VTEP puissent également se trouver sur un commutateur physique ou un serveur physique et puissent être implémentés en logiciel ou en matériel. Un cas d'utilisation où le VTEP est un commutateur physique est discuté dans la section 6 sur les scénarios de déploiement VXLAN.
Les sections suivantes discutent des scénarios de flux de trafic typiques dans un environnement VXLAN utilisant un type de schéma de contrôle -- l'apprentissage du plan de données (Data Plane Learning). Ici, l'association du MAC de la VM à l'adresse IP du VTEP est découverte via l'apprentissage de l'adresse source. Le multicast est utilisé pour transporter les trames de destination inconnue, de diffusion et de multicast.
En plus d'un plan de contrôle basé sur l'apprentissage, il existe d'autres schémas possibles pour la distribution des informations de mappage IP VTEP vers MAC VM. Les options pourraient inclure une recherche basée sur une autorité centrale/un répertoire par les VTEP individuels, la distribution de ces informations de mappage aux VTEP par l'autorité centrale, et ainsi de suite. Ceux-ci sont parfois caractérisés comme des modèles push et pull, respectivement. Ce document se concentrera sur le schéma d'apprentissage du plan de données comme plan de contrôle pour VXLAN.
4.1. Unicast VM-to-VM Communication (Communication unicast VM à VM)
Considérez une VM dans un réseau de superposition VXLAN. Cette VM n'est pas consciente de VXLAN. Pour communiquer avec une VM sur un hôte différent, elle envoie une trame MAC destinée à la cible comme d'habitude. Le VTEP sur l'hôte physique recherche le VNI auquel cette VM est associée. Il détermine ensuite si le MAC de destination est sur le même segment et s'il existe un mappage de l'adresse MAC de destination vers le VTEP distant. Si c'est le cas, un en-tête externe comprenant un MAC externe, un en-tête IP externe et un en-tête VXLAN (voir Figure 1 dans la section 5 pour le format de trame) sont ajoutés en tête de la trame MAC d'origine. Le paquet encapsulé est transmis vers le VTEP distant. À la réception, le VTEP distant vérifie la validité du VNI et s'il existe une VM sur ce VNI utilisant une adresse MAC qui correspond à l'adresse MAC de destination interne. Si c'est le cas, le paquet est dépouillé de ses en-têtes d'encapsulation et transmis à la VM de destination. La VM de destination ne connaît jamais le VNI ni le fait que la trame a été transportée avec une encapsulation VXLAN.
En plus de transmettre le paquet à la VM de destination, le VTEP distant apprend le mappage du MAC source interne à l'adresse IP source externe. Il stocke ce mappage dans une table de sorte que lorsque la VM de destination envoie un paquet de réponse, il n'est pas nécessaire d'effectuer un débordement de "destination inconnue" du paquet de réponse.
La détermination de l'adresse MAC de la VM de destination avant la transmission par la VM source est effectuée comme avec les environnements non-VXLAN, sauf comme décrit dans la section 4.2. Les trames de diffusion sont utilisées mais sont encapsulées dans un paquet multicast, comme détaillé dans la section 4.2.
4.2. Broadcast Communication and Mapping to Multicast (Communication broadcast et mappage vers multicast)
Considérez la VM sur l'hôte source tentant de communiquer avec la VM de destination en utilisant IP. En supposant qu'elles soient toutes les deux sur le même sous-réseau, la VM envoie une trame de diffusion ARP (Address Resolution Protocol). Dans l'environnement non-VXLAN, cette trame serait envoyée en utilisant la diffusion MAC à travers tous les commutateurs transportant ce VLAN.
Avec VXLAN, un en-tête incluant le VNI VXLAN est inséré au début du paquet avec l'en-tête IP et l'en-tête UDP. Cependant, ce paquet de diffusion est envoyé au groupe multicast IP sur lequel ce réseau de superposition VXLAN est réalisé.
Pour effectuer cela, nous devons avoir un mappage entre le VNI VXLAN et le groupe multicast IP qu'il utilisera. Ce mappage est effectué au niveau de la couche de gestion et fourni aux VTEP individuels via un canal de gestion. En utilisant ce mappage, le VTEP peut fournir des rapports d'adhésion IGMP au commutateur/routeur en amont pour rejoindre/quitter les groupes multicast IP liés à VXLAN selon les besoins. Cela permettra l'élagage des nœuds feuilles pour des adresses de trafic multicast spécifiques en fonction de la disponibilité d'un membre sur cet hôte utilisant l'adresse multicast spécifique (voir [RFC4541]). De plus, l'utilisation de protocoles de routage multicast comme le multicast indépendant du protocole - mode sparse (Protocol Independent Multicast - Sparse Mode, PIM-SM voir [RFC4601]) fournira des arbres multicast efficaces au sein du réseau de couche 3.
Le VTEP utilisera des jonctions (*,G). Cela est nécessaire car l'ensemble des sources de tunnel VXLAN est inconnu et peut changer souvent, car les VM montent/descendent sur différents hôtes. Une note secondaire ici est que puisque chaque VTEP peut agir à la fois comme source et destination pour les paquets multicast, un protocole comme PIM bidirectionnel (BIDIR-PIM -- voir [RFC5015]) serait plus efficace.
La VM de destination envoie une réponse ARP standard en utilisant l'unicast IP. Cette trame sera encapsulée vers le VTEP connectant la VM d'origine en utilisant l'encapsulation VXLAN unicast IP. Cela est possible car le mappage du MAC de destination de la réponse ARP vers l'IP du point de terminaison de tunnel VXLAN a été appris plus tôt via la requête ARP.
Notez que les trames multicast et les trames "destination MAC inconnue" sont également envoyées en utilisant l'arbre multicast, similairement aux trames de diffusion.
4.3. Physical Infrastructure Requirements (Exigences d'infrastructure physique)
Lorsque le multicast IP est utilisé au sein de l'infrastructure réseau, un protocole de routage multicast comme PIM-SM peut être utilisé par les routeurs/commutateurs IP de couche 3 individuels au sein du réseau. Cela est utilisé pour construire des arbres de transmission multicast efficaces de sorte que les trames multicast ne soient envoyées qu'aux hôtes qui ont demandé à les recevoir.
De même, il n'y a aucune exigence que le réseau réel connectant la VM source et la VM de destination doive être un réseau de couche 3 : VXLAN peut également fonctionner sur des réseaux de couche 2. Dans les deux cas, une réplication multicast efficace au sein du réseau de couche 2 peut être réalisée en utilisant l'écoute IGMP.
Les VTEP ne doivent pas (MUST NOT) fragmenter les paquets VXLAN. Les routeurs intermédiaires peuvent fragmenter les paquets VXLAN encapsulés en raison de la taille de trame plus grande. Le VTEP de destination peut (MAY) rejeter silencieusement de tels fragments VXLAN. Pour garantir la livraison du trafic de bout en bout sans fragmentation, il est recommandé (RECOMMENDED) que les MTU (unités de transmission maximale, Maximum Transmission Units) à travers l'infrastructure réseau physique soient configurées à une valeur qui accommode la taille de trame plus grande due à l'encapsulation. D'autres techniques comme la découverte de MTU de chemin (voir [RFC1191] et [RFC1981]) peuvent (MAY) également être utilisées pour répondre à cette exigence.