Dans VXLAN, un hôte connecté à un VTEP doit pouvoir communiquer avec un autre hôte connecté à un autre VTEP situé dans le même segment de couche 2.
En d’autres termes, si les deux hôtes communiquent sur le même VNI, cette communication doit réussir.
Mais comment ce VTEP trouve-t-il l’autre VTEP afin d’établir cette communication de couche 2 ?
C’est la responsabilité du plan de contrôle VXLAN.
Il existe une solution consistant à mapper manuellement les pairs VTEP en fonction des VNI configurés sur chacun , ce qu'on appelle VXLAN static peer mapping.
- Chaque VTEP (VXLAN Tunnel End Point) doit connaître les adresses IP des autres VTEP qui participent au même VNI (VXLAN Network Identifier).
- Au lieu de passer par un plan de contrôle automatique (multicast, EVPN, etc.), on configure statiquement les adresses des VTEP pairs dans chaque switch.
- Ainsi, quand un VTEP encapsule un paquet VXLAN pour un VNI donné, il sait directement à quels autres VTEP il doit l’envoyer.
Exemple de configuration (Cisco Nexus ou équivalent NX-OS)
nve1= interface VXLAN tunnel (Network Virtualization Edge)source-interface= l’IP locale qui représente le VTEPmember vni 6501= on associe le VNI 6501ingress-replication protocol static= on dit que le VTEP va envoyer en unicast aux pairs configuréspeer-ip 192.168.0.x= adresses IP des autres VTEP
Inconvénients de cette méthode
- Non scalable : si vous avez 100 VTEP dans un même VNI, il faut configurer 99 peers sur chacun.
- Administration lourde : toute modification de topologie oblige à mettre à jour manuellement toutes les configurations.
- Pas de découverte automatique : contrairement au multicast underlay ou à EVPN, où les pairs s’apprennent automatiquement
Dans cet article , nous allons examiner une option plus évolutive : la solution multicast underlay.
Il est important de noter que la RFC 7348, qui définit VXLAN, inclut dans sa définition ce mécanisme multicast spécifique pour le plan de contrôle ( Recommandé par la RFC 7348).
Plan de contrôle multicast étape par étape
Voici une topologie VXLAN où nous avons plusieurs VTEP.
Certains sont configurés avec le VNI 6501, tandis que d’autres ne le sont pas.
Avec une solution multicast underlay, chaque VNI est associé à une adresse IP multicast spécifique.
Ainsi, tous les VTEP qui contiennent le VNI 6501 rejoignent un groupe multicast particulier.
Par exemple, dans notre topologie, nous configurons l’adresse multicast 239.1.1.1.
Au départ, avant toute autre transmission, PC1 envoie une requête ARP comme d’habitude pour trouver l’adresse MAC de PC2, en fonction de son adresse IP (192.168.12.2).
Rappelez-vous que les PC eux-mêmes ignorent totalement la topologie VXLAN et son fonctionnement. Ils se comportent comme sur n’importe quel segment réseau.
Cette requête ARP atteint le VTEP1. Celui-ci encapsule la requête ARP :
- il ajoute l’en-tête VXLAN contenant le VNI,
- un en-tête UDP avec les bons numéros de port,
- et un en-tête IP pour le routage sur le réseau underlay.
Il place donc cette adresse multicast dans le champ de destination IP de l’en-tête IP.
Résultat : dans une topologie multicast, un seul paquet envoyé à une adresse IP multicast est transmis uniquement aux hôtes inscrits à ce groupe multicast.
Dans notre topologie, le VTEP1 envoie donc cette trame VXLAN encapsulée à tous les VTEP contenant le VNI 6501.
Chaque VTEP reçoit la requête ARP, la décapsule et la diffuse (Broadcast) à tous ses hôtes appartenant à ce VNI.
Ainsi, PC2 reçoit la requête ARP, ce qui était l’objectif.
C’est beaucoup plus simple et évolutif que de devoir indiquer dans chaque VTEP la liste de tous les autres VTEP contenant le VNI 6501.
Ensuite, PC2 répond avec une réponse ARP. Cette fois, le VTEP2 encapsule la réponse ARP avec un en-tête IP unicast, car il connaît maintenant l’adresse IP du VTEP d’origine .
La réponse atteint le VTEP1, qui la transmet à PC1.
PC1 met alors à jour sa table ARP avec l’adresse MAC de PC2.
Pendant ce temps, les VTEP ont mis à jour leurs tables de pairs VXLAN et leurs tables d’adresses MAC, associant les adresses aux interfaces réseau correspondant aux adresses IP des VTEP.
Ce processus est parfois appelé « flood and learn » multicast control plane pour VXLAN.
Multicast Flood and Learn
Lorsqu’une nouvelle requête ARP est envoyée, le VTEP émetteur inonde la requête vers tous les VTEP inscrits à l’adresse multicast associée au VNI concerné.
Il s’attend à recevoir une réponse uniquement de l’hôte recherché.
Une fois l’hôte trouvé, une encapsulation VXLAN spécifique entre les VTEP concernés est établie et la communication ultérieure se fait en unicast.
Bien sûr, cela suppose que tous les équipements de l’underlay soient correctement configurés pour le multicast. Sinon, l’ensemble ne fonctionnera pas.