Dans un réseau VXLAN, chaque VTEP (VXLAN Tunnel Endpoint) peut avoir des hôtes connectés sur différents VLANs. Pour que ces hôtes puissent communiquer avec d’autres VLANs ou avec le réseau extérieur, il faut une passerelle L3 (Layer 3 Gateway).
Traditionnellement, chaque VTEP aurait sa propre adresse IP de passerelle pour chaque VLAN, ce qui complique la gestion et peut créer des boucles ou des dépendances sur certains VTEP.
Dans le réseaux ci-dessous, nous avons créé une passerelle par défaut sur chaque VTEP pour le VNI local desservi. Ainsi, pour le VNI 6501, nous avons créé une SVI avec l’adresse IP 192.168.12.1.
Tout cela fonctionne correctement si nous supposons que nos VNIs sont locaux à chaque VTEP.
Cependant, le grand avantage de VXLAN est de pouvoir étendre vos réseaux de niveau 2 à l’aide des VNIs sur l’ensemble du tissu VXLAN.
Alors, que se passe-t-il si nous configurons ce VXLAN pour que le VNI 6501 s’étende également au VTEP2 ?
Et que se passe-t-il si nous connectons le PC3 et le configurons pour qu’il soit sur le VNI 6501, c’est-à-dire dans le même sous-réseau que le PC1 ?
Quelle passerelle par défaut utilisera-t-il pour communiquer en dehors de son propre sous-réseau ?
Disons que le PC3 veut envoyer un paquet au PC2.
Si nous utilisions la même SVI du VLAN 12 sur le VTEP1 comme passerelle par défaut pour le PC3, alors le trafic devrait traverser la topologie VXLAN via le VNI 6501 pour atteindre cette SVI, être routé, puis repartir à nouveau sur le VNI de transit 6500 pour arriver au PC2.
On voit bien que cette solution n’est ni efficace ni évolutive.
Une solution alternative consiste à utiliser la fonctionnalité EVPN Anycast Distributed Gateway. Voyons ce que c’est et comment cela fonctionne.
Anycast Distributed Gateway
Ce que fait l’anycast distributed gateway, c’est essentiellement créer une SVI locale sur chaque VTEP qui servira de passerelle locale pour le VNI correspondant. Et on utilise la même adresse IP que celle de la SVI correspondante sur le VTEP1.
C’est là qu’intervient le terme « distributed » : la passerelle par défaut pour le sous-réseau desservi par le VNI 6501 est distribuée entre tous les VTEPs qui desservent ce VNI. Le terme « anycast » vient du fait qu’on utilise la même adresse IP sur toutes les passerelles par défaut de tous les VTEPs qui servent ce VNI.
On pourrait penser qu’avoir une adresse IP dupliquée sur le réseau poserait problème, mais la fonctionnalité anycast d’IPv4 permet de mettre en œuvre cette solution.
Quand le PC3 essaie de communiquer avec le PC2, il sera routé vers la passerelle par défaut locale. Une fois routé par cette passerelle locale, l’opération MP-BGP EVPN VXLAN sera utilisée pour déterminer où se trouve l’hôte de destination.
Si l’hôte se trouve sur le VTEP local, comme c’est le cas pour le PC2 ici, le paquet sera directement routé via la SVI du VLAN 13 pour atteindre le PC2. En effet, le VTEP local peut gérer le routage inter-VNI directement grâce à la fonctionnalité d’anycast gateway, qui permet le routage de couche 3 entre deux VNIs locaux.
En revanche, si l’hôte de destination se trouve sur un VTEP distant, alors le paquet sera routé vers le VNI de transit via la SVI du VLAN 1213 afin d’être envoyé vers le VTEP distant correspondant.
Ici, nous avons plusieurs VTEPs avec les PC1, PC3 et PC4 configurés sur le même sous-réseau 192.168.1.0/24. Ils appartiennent tous au VNI 6501, mais chaque PC se trouve sur un VTEP différent.
Chaque VTEP est configuré une passerelle par défaut en utilisant la SVI du VLAN 12, et toutes ces passerelles par défaut utilisent la même adresse IP. C’est del’anycast .
Chacun de ces VTEPs est également configuré avec le VNI de transit 6500, qui correspond à la SVI du VLAN 1213 sur chaque appareil.
Maintenant, lorsque le PC1 veut communiquer avec le PC2, qui est sur un autre VNI (par exemple le VNI 6502), il va passer par sa passerelle par défaut locale. Un lookup VXLAN est alors effectué, et on détermine que pour atteindre la destination, il doit passer par la SVI locale qui correspond au VNI de transit 6500.
Le paquet est donc routé localement, puis envoyé à travers le VXLAN vers le VTEP2. Là, il est routé via la SVI du VLAN 1213 puis celle du VLAN 13 pour finalement atteindre le PC2.
Quand le PC2 répond, le routage a également lieu localement, d’abord via la SVI du VLAN 13, puis à travers le VNI 6500 pour revenir au VTEP1 et atteindre le PC1.
Le même processus se produit pour chaque VTEP qui contient le VNI 6501. Par exemple, le PC3 communiquera avec sa passerelle par défaut locale, effectuera un lookup VXLAN et déterminera qu’il doit passer par le VNI de transit pour atteindre le VTEP2 et être routé vers le PC2.
Le grand avantage ici est que le routage a toujours lieu localement avant que le paquet ne soit envoyé dans le fabric VXLAN. Ainsi, il n’est pas nécessaire que les paquets traversent toute la fabric pour être routés, puis renvoyés : cela se fait localement dans tous les cas, ce qui rend la solution beaucoup plus efficace.
Mais il y a un autre avantage important : imaginons que nous voulions déplacer le PC3 duVTEP3 vers cet autre VTEP. C’est aussi simple que de le débrancher de l’un et de le rebrancher sur l’autre. Il n’y a aucune configuration à changer sur le PC. La seule chose à vérifier est que le port auquel il est connecté sur le nouveau VTEP appartient bien au VLAN associé au VNI 6501.
Cohérence des adresses MAC
Il reste une dernière chose à aborder lorsqu’on parle de la fonctionnalité distributed gateway.
Vous avez peut-être déjà remarqué que, bien que l’adresse IP de la passerelle par défaut soit la même pour toutes les SVIs du VLAN 12 (associées au VNI 6501), elles ont par définition des adresses MAC différentes.
Or, dans les centres de données modernes et les environnements cloud, les machines virtuelles, les conteneurs et d’autres workloads se déplacent souvent dynamiquement entre serveurs et emplacements (pour des raisons comme l’équilibrage de charge, la montée en charge ou la maintenance).
Dans un tel environnement, il est donc nécessaire de maintenir la cohérence des adresses MAC des passerelles par défaut distribuées dans tout le fabric VXLAN.
Regardons cet exemple :
- Lorsque le conteneur 3 envoie une requête ARP pour découvrir l’adresse MAC de sa passerelle par défaut locale, il obtient une réponse et enregistre l’adresse MAC correspondante dans sa table ARP.
- Imaginons maintenant que ce conteneur soit déplacé dynamiquement du VTEP3 vers le VTEP4. Sa table ARP contient encore l’adresse MAC de la SVI du VTEP3, et non celle de la SVI locale du VTEP4 (qui devrait maintenant être la passerelle anycast locale).
- Résultat : juste après le déplacement, ce conteneur ne pourra plus accéder aux réseaux en dehors de son sous-réseau tant que sa table ARP n’est pas actualisée !
Solution 1 : Configuration manuelle des adresses MAC
Dans ce cas, on configure manuellement la même adresse MAC pour la SVI correspondante sur tous les VTEPs contenant le VNI 6501.Ainsi, quelle que soit la SVI du VLAN 12 qui répond à la requête ARP, elle renverra toujours la même adresse MAC.
Mais, comme vous pouvez l’imaginer, cette approche n’est pas très scalable.
Exemple de configuration sur Nexus:
On définit une MAC Anycast globale utilisée par tous les SVIs configurés en Anycast Gateway :
Puis, sur chaque interface VLAN (SVI) :
👉 Ici :
0001.0001.0001= MAC Anycast commune à tous les VTEP.fabric forwarding mode anycast-gateway: force l’utilisation d’une MAC Anycast unique
Solution 2 : MAC Address Aliasing
Une meilleure solution, plus évolutive, consiste à utiliser ce qu’on appelle le MAC Aliasing.
Dans le schéma, chaque Gateway possède la même adresse IP (grâce à l’Anycast Distributed Gateway), mais des adresses MAC différentes.
Le MAC Aliasing permet aux VTEPs de communiquer entre eux pour s’échanger leurs adresses MAC.
Ainsi, chaque VTEP dispose d’une liste de toutes les adresses MAC de toutes les autres passerelles distribuées et peut utiliser l’une d’elles pour répondre.
Par exemple, sur le VTEP4, on trouve la liste de toutes les adresses MAC des passerelles par défaut des autres VTEPs.
Donc, si le conteneur 3 est déplacé du VTEP3 au VTEP4, il conserve dans sa table ARP l’adresse MAC de la passerelle du VTEP3. Mais le VTEP4 connaît également cette adresse MAC, associée à la même adresse IP anycast.
En conséquence, le VTEP4 peut traiter immédiatement tout trafic destiné à cette passerelle par défaut.
Cisco supporte le MAC aliasing via l’option mac-move ou fwd mode anycast-gateway avec aliasing activé, souvent de manière implicite sur les leafs EVPN.
Exemple :
fabric forwarding mode anycast-gateway → active le mode Anycast IP pour la passerelle.fabric forwarding mac-aliasing → permet que chaque VTEP utilise sa MAC locale et que EVPN annonce cette MAC comme alias pour l’IP.
Remarque : sur certains NX-OS, le MAC aliasing est activé par défaut dès qu’on active l’Anycast Gateway.
Et c’est ainsi que fonctionne EVPN VXLAN Anycast Distributed Gateway !