Comprendre les VXLAN

La technologie VXLAN vous permet de segmenter vos réseaux (à l’instar des VLAN), mais elle offre des avantages que ces derniers n’offrent pas. Voici les principaux avantages de l’utilisation des VXLAN :

• En théorie, vous pouvez créer jusqu’à 16 millions de VXLAN dans un domaine administratif (contre 4 094 VLAN sur un équipement Juniper Networks).

  • Les routeurs MX Series et les commutateurs EX9200 prennent en charge jusqu’à 32 000 VXLAN, 32 000 groupes de multicast et 8 000 points de terminaison de tunnel virtuel (VTEP). Cela signifie que les VXLAN basés sur des routeurs MX Series offrent une segmentation réseau à l’échelle requise par les constructeurs de cloud pour prendre en charge un très grand nombre de locataires.

  • Les commutateurs QFX10000 Series prennent en charge 4 000 VXLAN et 2 000 VTEP distants.

  • Les commutateurs QFX5100, QFX5110, QFX5200, QFX5210 et EX4600 prennent en charge 4 000 VXLAN, 4 000 groupes de multicast et 2 000 VTEP distants.

  • Les commutateurs EX4300-48MP prennent en charge 4 000 VXLAN.

• Vous pouvez activer la migration de machines virtuelles entre des serveurs existant dans des domaines de couche 2 distincts en tunnelisant le trafic sur les réseaux de couche 3. Cette fonctionnalité vous permet d’allouer dynamiquement des ressources dans ou entre les centres de données sans être limité par les limites de la couche 2 ni être obligé de créer des domaines de couche 2 grands ou géographiquement étendus.

L’utilisation de VXLAN pour créer des domaines de couche 2 plus petits connectés sur un réseau de couche 3 signifie que vous n’avez pas besoin d’utiliser le protocole STP (Spanning Tree Protocol) pour faire converger la topologie, mais que vous pouvez utiliser des protocoles de routage plus robustes dans le réseau de couche 3. En l’absence de STP, aucune de vos liaisons n’est bloquée, ce qui signifie que vous pouvez tirer pleinement parti de tous les ports que vous achetez. L’utilisation de protocoles de routage pour connecter vos domaines de couche 2 vous permet également d’équilibrer la charge du trafic afin de vous assurer d’utiliser au mieux la bande passante disponible. Étant donné la quantité de trafic est-ouest qui circule souvent dans ou entre les datacenters, il est très important d’optimiser les performances de votre réseau pour ce trafic.

La vidéo Pourquoi utiliser un réseau overlay dans un datacenter ? présente un bref aperçu des avantages des VXLAN.

Le VXLAN est souvent décrit comme une technologie de superposition, car il permet d’étirer des connexions de couche 2 sur un réseau intermédiaire de couche 3 en encapsulant (tunneling) des trames Ethernet dans un paquet VXLAN comprenant des adresses IP. Les appareils qui prennent en charge les VXLAN sont appelés points de terminaison de tunnel virtuels (VTEP), c’est-à-dire qu’il peut s’agir d’hôtes finaux, de commutateurs réseau ou de routeurs. Les VTEP encapsulent le trafic VXLAN et le déencapsulent lorsqu’il quitte le tunnel VXLAN. Pour encapsuler une trame Ethernet, les VTEP ajoutent un certain nombre de champs, notamment les champs suivants :

• Adresse de destination MAC externe (adresse MAC du point de terminaison du tunnel VTEP)

• Adresse source MAC externe (adresse MAC du VTEP source du tunnel)

• Adresse IP de destination externe (adresse IP du point de terminaison de tunnel VTEP)

• Adresse IP source externe (adresse IP du VTEP source du tunnel)

• En-tête UDP externe

• En-tête de VXLAN qui inclut un champ 24 bits, appelé identifiant de réseau VXLAN (VNI), utilisé pour identifier de manière unique le VXLAN. Le VNI est similaire à un ID de VLAN, mais le fait d’avoir 24 bits vous permet de créer beaucoup plus de VXLAN que de VLAN.

La figure 1 illustre le format de paquet VXLAN.

Figure 1 : Format de paquet VXLAN

Junos OS prend en charge l’implémentation de VXLAN dans les environnements suivants :

• VXLAN manuel : dans cet environnement, un équipement Juniper Networks agit comme un équipement de transit pour les équipements en aval agissant comme des VTEP, ou une passerelle qui fournit une connectivité pour les serveurs en aval qui hébergent des machines virtuelles (VM), qui communiquent sur un réseau de couche 3. Dans cet environnement, les contrôleurs de réseau défini par logiciel (SDN) ne sont pas déployés.

  Remarque :

  Les commutateurs QFX10000 ne prennent pas en charge les VXLAN manuels.

• OVSDB-VXLAN : dans cet environnement, les contrôleurs SDN utilisent le protocole de gestion OVSDB (Open vSwitch Database) pour permettre aux contrôleurs (tels qu’un contrôleur VMware NSX ou Juniper Networks Contrail) et aux périphériques Juniper Networks prenant en charge OVSDB de communiquer.

• EVPN-VXLAN : dans cet environnement, Ethernet VPN (EVPN) est une technologie de plan de contrôle qui permet de placer des hôtes (serveurs physiques et machines virtuelles) n’importe où sur un réseau et de rester connectés au même réseau logique superposé de couche 2, et VXLAN crée le plan de données du réseau superposé de couche 2.

Vous pouvez configurer les commutateurs pour qu’ils remplissent les rôles suivants :

• (Tous les commutateurs sauf EX4300-48MP) Dans un environnement sans contrôleur SDN, agir comme un commutateur de couche 3 de transit pour les hôtes en aval agissant comme des VTEP. Dans cette configuration, vous n’avez pas besoin de configurer de fonctionnalité VXLAN sur le commutateur. Vous devez configurer IGMP et PIM afin que le commutateur puisse former les arborescences de multicast pour les groupes de multicast VXLAN. (Voir Manuel Les VXLAN nécessitent PIM pour plus d’informations.)

• (Tous les commutateurs sauf EX4300-48MP) Dans un environnement avec ou sans contrôleur SDN, agir comme une passerelle de couche 2 entre des réseaux virtualisés et non virtualisés dans le même datacenter ou entre des datacenters. Par exemple, vous pouvez utiliser le commutateur pour connecter un réseau qui utilise des VXLAN à un réseau qui utilise des VLAN.

• (Commutateurs EX4300-48MP) Agir comme une passerelle de couche 2 entre les réseaux virtualisés et non virtualisés dans un réseau de campus. Par exemple, vous pouvez utiliser le commutateur pour connecter un réseau qui utilise des VXLAN à un réseau qui utilise des VLAN.

• (Tous les commutateurs sauf EX4300-48MP) Agir comme une passerelle de couche 2 entre des réseaux virtualisés dans le même datacenter ou des datacenters différents et permettre aux machines virtuelles de se déplacer (VMotion) entre ces réseaux et les datacenters. Par exemple, si vous souhaitez autoriser VMotion entre des périphériques de deux réseaux différents, vous pouvez créer le même VLAN dans les deux réseaux et placer les deux périphériques sur ce VLAN. Les commutateurs connectés à ces appareils, agissant comme des VTEP, peuvent mapper ce VLAN au même VXLAN, et le trafic VXLAN peut ensuite être acheminé entre les deux réseaux.

• (Commutateurs QFX5110 et QFX5120 avec EVPN-VXLAN) Agir comme une passerelle de couche 3 pour acheminer le trafic entre différents VXLAN dans le même datacenter.

• (Commutateurs QFX5110 et QFX5120 avec EVPN-VXLAN) Agir comme une passerelle de couche 3 pour acheminer le trafic entre différents VXLAN dans différents datacenters sur un WAN ou Internet à l’aide de protocoles de routage standard ou de tunnels VPLS (Virtual Private LAN Service).

Étant donné que les en-têtes supplémentaires ajoutent 50 à 54 octets, vous devrez peut-être augmenter la MTU sur un VTEP pour prendre en charge des paquets plus volumineux. Par exemple, si le commutateur utilise la valeur de MTU par défaut de 1514 octets et que vous souhaitez transférer des paquets de 1500 octets sur le VXLAN, vous devez augmenter la MTU pour tenir compte de la taille accrue des paquets causée par les en-têtes supplémentaires.

À partir de la version 14.1X53-D25 de Junos OS sur les commutateurs QFX5100, de la version 15.1X53-D210 de Junos OS sur les commutateurs QFX5110 et QFX5200, de la version 18.1R1 de Junos OS sur les commutateurs QFX5210 et de la version 18.2R1 de Junos OS sur les commutateurs EX4600, vous pouvez configurer le port UDP utilisé comme port de destination pour le trafic VXLAN. Pour configurer le port de destination VXLAN afin qu’il soit autre que le port UDP par défaut de 4789, entrez l’instruction suivante :

set protocols l2-learning destination-udp-port port-number

Le port que vous configurez sera utilisé pour tous les VXLAN configurés sur le commutateur.

Par défaut, lorsque la table hôte atteint sa capacité, des entrées d’hôte supplémentaires débordent dans la table LPM (Longest Prefix Match). Cela peut entraîner une dégradation des performances de routage résultant de petites entrées d’hôte qui consomment un espace précieux dans la table LPM.

À partir de la version 25.2R1 de Junos OS, vous pouvez empêcher les entrées de l’hôte de déborder dans la table LPM en configurant l’instruction set forwarding-options no-host-as-lpm . Lorsque vous activez cette option, les entrées d’hôte ne peuvent pas entrer dans la table LPM et un message d’erreur est consigné pour vous avertir de la condition complète de la table d’hôte. Cette restriction maintient l’intégrité de la table LPM pour les routes de sous-réseau plus importantes, qui sont généralement plus critiques pour un fonctionnement efficace du réseau. Cette configuration nécessite un redémarrage du PFE pour effacer toutes les entrées hôtes existantes de la table LPM, ce qui garantit que la table est dédiée uniquement aux routes de sous-réseau à l’avenir. Le redémarrage est crucial pour maintenir un état propre, car il empêche les entrées d’hôte résiduelles d’affecter l’utilisation de l’espace table.

La prévention des dépassements d’entrée d’hôte est particulièrement utile pour les environnements où les exigences d’entrée d’hôte sont élevées. Cette fonctionnalité prend en charge les routes IPv4 et IPv6 et s’applique aux environnements VXLAN et non VXLAN, ce qui la rend polyvalente pour divers scénarios de déploiement. La séparation des routes hôtes et de sous-réseau évite la dégradation des performances de routage résultant du débordement des entrées hôtes sur la table LPM. En outre, le système génère un message de journal système chaque fois que vous activez l’option CLI, fournissant une piste d’audit pour la gestion des modifications et le dépannage. En tirant parti de cette fonctionnalité, vous pouvez améliorer la gestion des tables de routage, améliorer l’efficacité du routage et assurer un contrôle systématique des entrées de table de routage.

Reportez-vous à l’explorateur de fonctionnalités pour obtenir la liste complète des produits qui prennent en charge la fonctionnalité de prévention de débordement d’entrée hôte.

Lorsque le commutateur agissant en tant que VTEP reçoit un paquet de diffusion, d’unicast inconnu ou de multicast, il effectue les actions suivantes sur le paquet :

1. Il déencapsule le paquet et le livre aux hôtes connectés localement.

2. Il ajoute ensuite à nouveau l’encapsulation du VXLAN et envoie le paquet aux autres VTEP du VXLAN.

Ces actions sont effectuées par l’interface de bouclage utilisée comme adresse de tunnel VXLAN et peuvent donc avoir un impact négatif sur la bande passante disponible pour le VTEP. À partir de la version Junos OS 14.1X53-D30 pour les commutateurs QFX5100, Junos OS version 15.1X53-D210 pour les commutateurs QFX5110 et QFX5200, Junos OS version 18.1R1 pour les commutateurs QFX5210 et Junos OS version 18.2R1 pour les commutateurs EX4600, si vous savez qu’aucun récepteur multicast n’est connecté à d’autres VTEP dans le VXLAN qui souhaitent le trafic d’un groupe de multicast spécifique, Vous pouvez réduire la charge de traitement sur l’interface de bouclage en entrant l’instruction suivante :

Dans ce cas, aucun trafic ne sera transféré pour le groupe spécifié, mais tout le reste du trafic multicast sera transféré. Si vous ne souhaitez pas transférer de trafic de multicast à d’autres VTEP du VXLAN, entrez l’instruction suivante :

Vous pouvez configurer un routeur MX Series, un commutateur EX9200 ou un commutateur QFX10000 pour qu’il agisse en tant que VTEP et remplisse tous les rôles suivants :

• Agir comme une passerelle de couche 2 entre des réseaux virtualisés et non virtualisés dans le même datacenter ou entre des datacenters. Par exemple, vous pouvez utiliser un routeur MX Series pour connecter un réseau qui utilise des VXLAN à un réseau qui utilise des VLAN.

• Agir comme une passerelle de couche 2 entre des réseaux virtualisés dans le même datacenter ou des datacenters différents et permettre aux machines virtuelles de se déplacer (VMotion) entre ces réseaux et les datacenters.

• Agir comme une passerelle de couche 3 pour acheminer le trafic entre différents VXLAN dans le même datacenter.

• Agir comme une passerelle de couche 3 pour acheminer le trafic entre différents VXLAN dans différents datacenters sur un WAN ou Internet à l’aide de protocoles de routage standard ou de tunnels VPLS (Virtual Private LAN Service).

Dans un environnement doté d’un contrôleur (tel qu’un contrôleur VMware NSX ou Juniper Networks Contrail), vous pouvez provisionner des VXLAN sur un équipement Juniper Networks. Un contrôleur fournit également un plan de contrôle que les VTEP utilisent pour annoncer leur accessibilité et en savoir plus sur l’accessibilité des autres VTEP. Vous pouvez également créer manuellement des VXLAN sur des appareils Juniper Networks au lieu d’utiliser un contrôleur. Si vous utilisez cette approche, vous devez également configurer Protocol Independent Multicast (PIM) sur les VTEP afin qu’ils puissent créer des tunnels VXLAN entre eux.

Vous devez également configurer chaque VTEP d’un VXLAN donné pour qu’il soit membre du même groupe de multicast. (Si possible, vous devez affecter une adresse de groupe de multicast différente à chaque VXLAN, bien que cela ne soit pas obligatoire. Plusieurs VXLAN peuvent partager le même groupe de multicast.) Les VTEP peuvent ensuite transférer les requêtes ARP qu’ils reçoivent de leurs hôtes connectés au groupe de multicast. Les autres VTEP du groupe déencapsulent les informations du VXLAN et (en supposant qu’ils sont membres du même VXLAN) ils transmettent la requête ARP à leurs hôtes connectés. Lorsque l’hôte cible reçoit la demande ARP, il répond avec son adresse MAC et son VTEP transmet cette réponse ARP au VTEP source. Grâce à ce processus, les VTEP apprennent les adresses IP des autres VTEP du VXLAN et les adresses MAC des hôtes connectés aux autres VTEP.

Les groupes et arborescences de multicast sont également utilisés pour transférer le trafic de diffusion, d’unicast inconnu et de multicast (BUM) entre VTEP. Cela permet d’éviter que le trafic BUM ne soit inutilement inondé en dehors du VXLAN.

Les routes de couche 3 qui forment les tunnels VXLAN utilisent par défaut l’équilibrage de charge par paquet, ce qui signifie que l’équilibrage de charge est implémenté s’il existe des chemins ECMP vers le VTEP distant. Ceci est différent du comportement de routage normal dans lequel l’équilibrage de charge par paquet n’est pas utilisé par défaut. (Le routage normal utilise par défaut l’équilibrage de charge par préfixe.)

Le champ port source dans l’en-tête UDP est utilisé pour activer l’équilibrage de charge ECMP du trafic VXLAN sur le réseau de couche 3. Ce champ est défini sur un hachage des champs de paquet internes, ce qui génère une variable qu’ECMP peut utiliser pour distinguer les tunnels (flux).

Aucun des autres champs habituellement utilisés par ECMP basé sur les flux ne se prête aux VXLAN. Tous les tunnels entre les deux mêmes VTEP ont les mêmes adresses IP source et de destination externes, et le port de destination UDP est défini sur le port 4789 par définition. Par conséquent, aucun de ces champs ne fournit un moyen suffisant pour ECMP de différencier les flux.

Lorsqu’un commutateur QFX5120 tente de tunnel le trafic sur des interfaces centrales balisées de couche 3 ou des interfaces IRB, il abandonne les paquets. Pour éviter ce problème, vous pouvez configurer un pare-feu simple à deux termes basé sur des filtres sur l’interface balisée de couche 3 ou IRB.

Par exemple :

Le terme 1 correspond et accepte le trafic destiné au commutateur QFX5210, qui est identifié par l’adresse IP VTEP source (192.168.0.1/24) affectée à l’interface de bouclage du commutateur. Pour le terme 1, notez que lorsque vous spécifiez une action, vous pouvez également compter le trafic au lieu de l’accepter.

Le terme 2 correspond et transfère tout le reste du trafic de données à une instance de routage (route 1), qui est configurée interface et-0/0/3.

Dans cet exemple, notez que l’interface et-0/0/3 est référencée par l’instance de routage route1. Par conséquent, vous devez inclure la set firewall family inet filter vxlan100 term 2 then routing-instance route1 commande. Sans cette commande, le filtre du pare-feu ne fonctionnera pas correctement.

Sur les commutateurs QFX5100 et QFX5110, vous pouvez utiliser les commandes et traceroute pour dépanner le ping flux de trafic dans un tunnel VXLAN en incluant le paramètre et diverses overlay options. Vous utilisez ces options pour forcer les ping paquets ou traceroute à suivre le même chemin que les paquets de données dans le tunnel VXLAN. En d’autres termes, vous faites en sorte que les paquets sous-jacents (ping et traceroute) empruntent le même chemin que les paquets superposés (trafic de données). Pour plus d’informations, consultez Overlay ping et overlay traceroute.

RFC et projets Internet qui définissent les normes pour VXLAN :

• RFC 7348, Virtual eXtensible Local Area Network (VXLAN) : une structure pour superposer des réseaux virtualisés de couche 2 sur des réseaux de couche 3

• Internet draft draft-ietf-nvo3-vxlan-gpe, Extension de protocole générique pour VXLAN