EVPN-VXLAN permet de construire des réseaux de centres de données où l’infrastructure physique fonctionne de bout en bout sur IP, tandis que les segments clients, les réseaux virtuels et les politiques sont créés dans un plan superposé. Ce modèle ne supprime pas la couche 2, mais évite de l’étendre physiquement à tous les commutateurs, réduit la dépendance au Spanning Tree Protocol (STP) et fournit un plan de contrôle capable de distribuer les adresses MAC, IP et préfixes via BGP.

Les clés d’EVPN-VXLAN en 30 secondes

• Le underlay est un réseau IP routé, généralement avec une topologie leaf-spine.
• VXLAN encapsule Ethernet sur UDP et assigne un identifiant VNI à chaque réseau virtuel.
• BGP EVPN distribue la localisation des endpoints, des passerelles et des préfixes entre les VTEP.
• Le tissu peut utiliser tous les liens disponibles via ECMP, sans bloquer de chemins comme le ferait STP.
• EVPN-VXLAN améliore l’isolement et la scalabilité, mais nécessite de faire attention à la MTU, la conception BGP, le trafic BUM et l’automatisation.

Pendant des années, de nombreux centres de données ont évolué en ajoutant VLAN, trunks et paires de commutateurs avec des technologies d’agrégation multichassis. Ce modèle reste valable pour des environnements de petite et moyenne taille, mais commence à montrer ses limites lorsqu’il faut connecter des centaines de racks, héberger de nombreux clients ou maintenir une mobilité des charges sans élargir le domaine de défaillance.

EVPN-VXLAN modifie la question. Au lieu de chercher comment faire parvenir chaque VLAN dans tous les recoins du centre de données, il s’agit de définir où chaque service doit exister et comment l’annoncer sur un réseau IP stable.

Le problème des grands domaines de couche 2

Un réseau Ethernet traditionnel apprend la localisation des équipements en observant les adresses MAC des trames qu’il reçoit. Lorsqu’il ne connaît pas la position d’une destination, il duplique le trafic sur les ports correspondants. Les messages de broadcast et une partie du multicast sont également distribués dans le domaine de couche 2.

Tant que l’environnement reste limité, ce comportement est gérable. Les difficultés augmentent lorsque la même VLAN traverse plusieurs racks, voire plusieurs bâtiments :

• Augmentation de la portée des broadcasts.
• Une erreur de configuration peut affecter une zone plus étendue.
• Le trafic vers des destinations inconnues augmente.
• STP peut laisser des liens inutilisés pour prévenir les boucles.
• Le diagnostic dépend de la traçabilité des VLAN, trunks et tables MAC à travers de nombreux équipements.
• Les modifications affectent un domaine opérationnel de plus en plus vaste.

Le problème ne réside pas dans l’existence d’Ethernet, mais dans la transformation de tout le centre de données en un grand réseau commuté. La couche 2 reste nécessaire pour l’accès aux serveurs et certains services, mais elle ne doit pas forcément constituer le réseau de transport entre tous les commutateurs.

EVPN-VXLAN établit cette séparation. La connectivité physique entre les nœuds est gérée via le routage IP. Les services Ethernet ou IP de chaque client circulent au-dessus, encapsulés et isolés.

Underlay et overlay : deux réseaux aux fonctions différentes

L’architecture est mieux comprise en la divisant en deux plans.

L’underlay IP

L’underlay est le réseau physique qui connecte les commutateurs. Dans un centre de données, il adopte souvent une topologie leaf-spine basée sur une architecture clos :

• Les commutateurs leaf connectent serveurs, racks, pare-feux ou autres équipements.
• Chaque leaf est relié à tous les spine.
• Les spine transportent le trafic entre leafs et n’ont pas besoin de connaître les VLAN des clients.

Cette topologie offre plusieurs chemins de coût équivalent. Le trafic peut être réparti via ECMP, permettant d’utiliser simultanément tous les liens disponibles et de conserver des chemins alternatifs en cas de défaillance.

Le protocole de l’underlay peut être eBGP, OSPF ou IS-IS, selon la plateforme et la conception. Son exigence essentielle est de fournir une connectivité IP stable entre les VXLAN Tunnel Endpoints (VTEP), qui utilisent généralement des adresses de boucle de contrôle (loopback) comme extrémités des tunnels.

L’underlay doit fonctionner avant de pouvoir construire l’overlay. Si deux VTEP ne peuvent communiquer en IP, VXLAN ne pourra pas transporter les services entre eux.

L’overlay de services

L’overlay contient les réseaux virtuels utilisés par les serveurs et clients. Il peut offrir une connectivité de couche 2, un routage entre sous-réseaux ou une séparation via VRF.

Les leafs qui agissent comme VTEP encapsulent le trafic à l’entrée de l’overlay et le décapsulent à la sortie. Pour les spine, ces paquets sont du trafic IP ordinaire : ils n’ont pas besoin de connaître MAC, VLAN ou client transportés à l’intérieur.

Cette indépendance permet de modifier les services de l’overlay sans refaire toute la topologie physique. Elle facilite également la réutilisation d’un même réseau IP de fabric pour de nombreux clients isolés.

Que fournit VXLAN

VXLAN, acronyme de Virtual eXtensible Local Area Network, encapsule une trame Ethernet dans un paquet UDP. L’en-tête extérieur contient les adresses IP des VTEP d’origine et de destination, permettant à l’underlay de le router comme n’importe quel autre paquet.

Chaque segment utilise un Identifiant de Réseau VXLAN (VNI) de 24 bits. Cela offre près de 16,7 millions d’identifiants possibles, contre un espace de 12 bits pour les VLAN IEEE 802.1Q, pratiquement limité à 4094 valeurs utilisables.

Une association simple pourrait être :

VXLAN est le plan de données. Il indique comment transporter le trafic, mais à lui seul, il ne détermine pas efficacement où se trouve chaque endpoint. La conception originale, décrite dans la RFC 7348, permet des mécanismes de flood and learn, où le réseau duplique une partie du trafic pour découvrir les destinations.

BGP EVPN incorpore le plan de contrôle permettant d’éviter une grande partie de cet apprentissage par inondation.

Comment fonctionne BGP EVPN

Ethernet VPN (EVPN) utilise BGP multiprotocole pour échanger des informations sur les services de l’overlay. Les VTEP annoncent quels endpoints ils ont connectés, et le reste du fabric apprend comment les atteindre.

Parmi les types de routes les plus courants, on trouve :

• Type 2, MAC/IP Advertisement : annonce une adresse MAC et, si disponible, son IP associée.
• Type 3, Inclusive Multicast Ethernet Tag : informe de la appartenance d’un VTEP à un domaine et aide à construire la distribution du trafic broadcast, unknown unicast et multicast.
• Type 5, IP Prefix : publie des préfixes IP d’une VRF sans besoin de leur associer une adresse MAC de hôte.

Les routes portent des attributs tels que Route Distinguisher et Route Target. Le premier permet d’unicifier des routes potentiellement identiques dans le cadre de BGP. Les Route Target contrôlent quelles VRF ou instances EVPN importent et exportent chaque information.

Dans un fabric de taille moyenne, il n’est généralement pas pratique de créer une session BGP complète entre tous les leafs. Les spine peuvent agir comme route reflectors, recevant et redistribuant les routes EVPN sans nécessairement participer comme VTEP dans le trafic de données.

Cette séparation améliore aussi l’observabilité. L’opérateur peut consulter dans BGP où une MAC a été annoncée, quel VTEP l’origine, et à quelle VNI elle appartient, plutôt que de dépendre uniquement de tables apprises de saut en saut.

Un exemple de communication entre deux racks

Supposons que le serveur A se connecte au leaf 1 et le serveur B au leaf 4. Tous deux appartiennent au VNI 10100.

Le processus simplifié est le suivant :

1. Le leaf 1 apprend localement la MAC et l’IP du serveur A.
2. Il publie ces informations via une route EVPN de type 2.
3. Le leaf 4 fait de même avec le serveur B.
4. Les deux VTEP connaissent ainsi la localisation distante de chaque endpoint.
5. Lorsque A envoie une trame à B, le leaf 1 l’associe au VNI 10100.
6. Il encapsule la trame en VXLAN et y ajoute les IP extérieures des VTEP.
7. L’underlay route le paquet par l’un des chemins ECMP disponibles.
8. Le leaf 4 désencapsule et livre la trame au serveur B.

Du point de vue des serveurs, ils restent dans le même segment logique. Cependant, entre racks, les liens ne transportent pas cette VLAN par trunks Ethernet, mais des paquets IP encapsulés.

On dit donc qu’EVPN-VXLAN évite d’étendre physiquement la couche 2 sur tout le fabric. Le overlay peut néanmoins offrir une extension logique de couche 2 lorsque l’application le nécessite.

Moins de flooding, mais pas de flooding zéro

BGP EVPN réduit le flooding du trafic, mais ne l’élimine pas complètement.

Le trafic BUM, correspondant à broadcast, unknown unicast et multicast, nécessite toujours une méthode de distribution. Cela peut être résolu via multicast dans l’underlay ou par ingress replication, où le VTEP d’entrée envoie une copie à tous les VTEP intéressés.

EVPN peut aussi faciliter la suppression d’ARP et de Neighbor Discovery. En connaissant via les routes de type 2 la relation entre adresses IP et MAC, un VTEP peut répondre localement à certaines requêtes au lieu de les diffuser dans tout le segment.

Cependant, l’efficacité dépend de l’implémentation, de la configuration et de la qualité des informations apprises. Concevoir EVPN-VXLAN ne consiste pas simplement à activer un protocole en espérant que tout flooding disparaîtra.

Routage distribué et gateway anycast

Une des fonctionnalités les plus utiles est la possibilité de placer la passerelle d’un sous-réseau directement dans les leafs.

Avec une passerelle anycast, plusieurs leafs présentent aux serveurs la même adresse IP et la même MAC virtuelle comme passerelle. Chaque charge utilise la passerelle locale, permettant un routage proche de la source sans passer par un ou plusieurs routers centraux.

Le standard de l’Integrated Routing and Bridging (IRB) prévoit des modèles asymétriques et symétriques. Dans de grands fabrics multi-locataires, le IRB symétrique est souvent employé :

• Le VTEP d’entrée route le paquet vers la VRF correspondante.
• Le trafic traverse l’overlay via un VNI de couche 3.
• Le VTEP de sortie le livre au segment du destinataire.

Ce modèle évite que tous les leafs doivent héberger toutes les VLAN d’une VRF, offrant généralement une meilleure scalabilité. Sa conception requiert une bonne compréhension des VNI de couche 2, VNI de couche 3, VRF et politiques d’import/export.

Multihoming actif-actif sans dépendre de STP

EVPN supporte aussi des connexions redondantes d’un serveur, firewall ou commutateur vers plusieurs leafs. Via un Ethernet Segment Identifier (ESI), les VTEP peuvent annoncer qu’ils partagent le même segment.

Le mode all-active permet d’utiliser simultanément plusieurs liens et de coordonner des fonctions telles que :

• Sélection du Designated Forwarder pour le trafic BUM.
• Éviter les duplicats.
• Apprentissage coordonné des MAC.
• Retrait rapide des routes en cas de défaillance d’un lien ou d’un leaf.

Ce mode offre une alternative normalisée à certains schémas propriétaires MLAG. Il ne signifie pas que MLAG devient obsolète ni que tous les équipements prennent en charge les mêmes fonctions EVPN, mais il réduit la nécessité de bâtir le fabric autour de grands domaines STP.

STP peut continuer à exister en périphérie, par exemple pour des équipements Ethernet capables de créer des boucles. Ce qui disparaît, c’est son rôle principal comme mécanisme pour décider quels liens du backbone restent actifs.

La MTU et autres éléments pouvant compromettre le fabric

VXLAN ajoute des en-têtes au paquet original. En IPv4, la surcharge est généralement d’environ 50 octets, mais peut varier selon le scénario. Si l’underlay maintient une MTU de 1500 octets et que les serveurs envoient aussi des trames de cette taille, le paquet encapsulé peut dépasser cette limite.

Comme beaucoup de commutateurs de centre de données ne fragmentent pas VXLAN comme on pourrait l’attendre, une MTU incohérente peut provoquer des pertes difficiles à diagnostiquer. C’est pourquoi l’underlay est souvent configuré avec des jumbo frames et testé de bout en bout avant le déploiement de l’overlay.

Il faut également prévoir :

• Le paramétrage des loopbacks et liens point à point.
• Les ASN utilisés dans l’underlay et l’overlay.
• Les route reflectors et la redondance du plan de contrôle.
• Les limites du matériel concernant MAC, routes, VNI et VRF.
• La gestion du trafic BUM.
• La convergence en cas de défaillance.
• Le filtrage des routes et politiques entre clients.
• La compatibilité réelle entre fabricants.
• L’automatisation et la cohérence des configurations.

Les RFC définissent les procédures, mais les plateformes peuvent présenter des différences en capacités, en échelles, en valeurs par défaut ou en fonctions optionnelles. L’interopérabilité doit être vérifiée avec les versions exactes qui seront déployées en production.

Comment évolue le diagnostic des incidents

EVPN-VXLAN organise le réseau en couches, et le diagnostic doit suivre cet ordre.

1. Vérifier l’underlay

Avant d’analyser EVPN, il convient de vérifier :

• Les voisinages du protocole de routage.
• Les routes vers les loopbacks des VTEP.
• ECMP et chemins disponibles.
• La MTU et la perte de paquets.
• La latence et les erreurs physiques.

2. Examiner le plan de contrôle EVPN

Ensuite, vérifier :

• Les sessions MP-BGP.
• Les familles d’adresses EVPN actives.
• Les routes de type 2, 3 et 5.
• Les Route Target importés et exportés.
• Le(s) saut(s) suivant(s) et le VTEP initiateur.
• Les routes retirées ou mobiles.

3. Valider l’overlay

Enfin, examiner :

• La correspondance VLAN, domaine bridge et VNI.
• VNI de couche 3 et VRF.
• La passerelle anycast.
• Les tables MAC et IP.
• La suppression ARP ou ND.
• L’encapsulation et la décapsulation VXLAN.
• Les listes de VTEP participants dans chaque segment.

Le niveau de complexité ne disparaît pas. On passe d’un grand plan 2 difficile à limiter à plusieurs plans aux responsabilités définies. Cette séparation facilite la localisation des défaillances, à condition que l’équipe opérationnelle dispose de la télémétrie, des procédures et de la formation appropriées.

Quand déployer EVPN-VXLAN en valeur

L’architecture est particulièrement adaptée lorsque le centre de données doit :

• Gérer de nombreux segments ou clients isolés.
• Couvrir une croissance horizontale par de nouveaux racks.
• Optimiser la utilisation de multiples chemins actifs.
• Disposer de passerelles distribuées.
• Mettre en œuvre un multihoming actif-actif.
• Automatiser avec des modèles reproductibles.
• Gérer la mobilité contrôlée des charges.
• Faire la séparation entre infrastructure physique et services.

Ce n’est pas toujours la solution la plus adaptée. Un petit environnement avec peu de VLAN, des exigences stables et quelques commutateurs peut parfaitement fonctionner avec une architecture conventionnelle. Introduire BGP EVPN, VTEP, VRF, et politiques d’importation sans besoin réel peut compliquer inutilement l’exploitation.

La décision doit prendre en compte non seulement la taille actuelle, mais aussi la croissance prévue, la compétence de l’équipe et les fonctionnalités supportées par le matériel.

EVPN-VXLAN ne doit pas être adopté simplement parce qu’il s’agit d’une technologie moderne, mais lorsque la séparation entre underlay et overlay répond à des problèmes concrets d’échelle, de redondance, d’isolement ou d’exploitation.

Questions fréquentes

EVPN-VXLAN élimine-t-il complètement la couche 2 ?

Non. Les serveurs peuvent continuer à utiliser Ethernet et appartenir au même segment logique. La différence est que la VLAN n’a pas besoin de traverser physiquement tout le fabric via des trunks : VXLAN la transporte sur un réseau IP.

VXLAN et EVPN sont-ils la même technologie ?

Non. VXLAN définit l’encapsulation et agit comme plan de données, tandis qu’EVPN utilise BGP comme plan de contrôle pour distribuer les informations MAC, IP, préfixes et appartenance aux segments.

EVPN-VXLAN élimine-t-il le STP ?

Il en réduit le rôle puisqu’il exploite le routage IP et ECMP dans l’underlay. Néanmoins, STP peut rester nécessaire dans certains segments d’accès ou pour des équipements externes qui pourraient créer des boucles.

Que faut-il vérifier en premier lorsqu’un tunnel VXLAN échoue ?

La connectivité IP entre les VTEP, les routes vers leurs loopbacks et la MTU de l’underlay. Ensuite, il faut aussi analyser les sessions BGP EVPN, les VNI et les routes annoncées.