Le VXLAN permet d'étendre un niveau 2 à travers une liaison niveau 3 avec l'encapsulation Mac in UDP, l'idée est d'avoir des machines dans le même sous-réseau (le même vlan) à travers des liaisons entre les leafs et les Spines en Niveau 3. Pour cela, le VTEP encapsule le paquet (qui a déjà les entête IP et Ethernet des deux machines qui représente l'inner header) dans une nouvelle entête UDP/IP/MAC représentant le outer header. Le Outer Header IP est composée des adresses IP des VTEPs (LEAFS)
Le rôle du protocole de routage de l'Underlay, par exemple OSPF, est de fournir une connectivité entre les adresses IP VTEP. Les Spines routeront les paquets VXLAN en basant sur l'IP destination VTEP véhiculée dans le outer L3 header sans aucune connaissance de l'entête INNER niveau 3.
Le rôle du protocole de routage de l'Overlay (MP-BGP EVPN) est d'identifier derrière quelle VTEP se trouve la MAC/IP (c'est à dire le host), il joue le rôle de control plan pour le VXLAN tandis que ce dernier joue le rôle de data plan. Lorsque un VTEP fait l'apprentissage des hôtes comme l'IP/MAC (ARP) dans le segment local connecté directement, il annonce ensuite ses informations aux autres VTEP à travers le control plan avec le protocole MP-BGP EVPN avec les routes type 2. L'utilisation du MP-BGP EVPN est une optimisation de l'ancienne solution Learn and Flood.
Pour le trafic BUM, Broadcast, Unknown Unicast et Multicast, le VTEP source doit répliquer ce trafic vers plusieurs VTEPs, pour cela le protocole de multicast PIM est utilisé dans la solution VXLAN EVPN, un exemple de traitement d'un trafic BUM, c'est dans le cas ou un hôte ne connait pas l'adresse MAC de destination de l'hôte distant (dans le même sous-réseau, ce qui nécessite de générer une requête ARP broadcast) et en même temps le VTEP local n'a pas encore appris l'adresse MAC/IP de l'hôte de destination (afin d'appliquer ARP Suppression), dans cette situation le VTEP local enverra la requête ARP avec l'IP destination l'adresse Multicast group définit dans l'interface NVE, le paquet est envoyé au Point de Rendez Vous (Spine) et ce dernier répliquera le paquet multicast aux VTEPs configurés avec le même VXLAN L2 VNI qui ont rejoint le group multicast.
Le protocole de control plan MP-BGP EVPN annonce principalement trois Routes Type:
Route Type 2: cette route annonce le couple MAC/IP des machines, cette route type est le cœur de fonctionnement du VXLAN. Elle permet aux VTEP de faire l'apprentissage et l'échange des MAC et le binding MAC-IP.
Route Type 3: cette route est utilisée lorsqu'on utilise la méthode Ingress Replication pour le trafic BUM.
Route Type 5: cette route annonce les prefix (les sous réseaux) dans EVPN. Il y'a deux use case de cette route, elle est utilisée pour injecter des routes externes, émanant des réseaux traditionnels comme le WAN dans la fabric par le border node. La deuxième utilisation est lorsque nous avons les silents hosts pas encore découverts par les VTEPs.
Il y'a deux scenarios avec les silents hosts:
Scenario 1: Les deux hosts sont dans le même segment L2 VNI - Donc le trafic est bridgé
Scenario 2: Les deux hosts sont dans différents segment L2 VNI - Donc le trafic est routé
Dans le scenario 1, pour récupérer la mac de destination, un arp request est envoyé et le switch leaf se basera sur le protocole de multicast PIM dans l'underlay.
Dans le scenario 2, avec différents segments L2 VNI, nous avons deux cas:
Etude de cas:
Cas 1: Les deux segments L2 VNI sont configurés dans les deux leafs - ici il y'aura un routage inter-VNI asymétrique, une requête ARP est générée, le switch leaf se basera sur le protocole de multicast dans l'underlay pour le traitement du trafic BUM.
Cas 2: Les deux segments L2 VNI NE SONT PAS configurés dans les deux leafs - ici il y'aura un routage inter-VNI symétrique, ce qui nécessite un autre segment VNI de niveau 3, c'est à dire L3 VNI, et ici entre en jeu la route Type 5 pour les silents hosts, contrairement aux routes Type 2, par défaut les routes type 5 ne sont pas annoncés. Lorsqu'on annonce manuellement les prefix, des routes type 5 sont injecté avec MP-BGP EVPN, les leafs apprennent donc le prefix de l'hôte distant et pourront router le trafic.
Le routage IRB inter-VNI permet de faire du routage entre deux hôtes dans différent VLANs (sous réseaux) c'est à dire différent segment L2 VNI. Il existe deux types de routage IRB - le routage asymétrique ( Le premier VTEP réalise le Bridging du VLAN 10 au L2 VNI 100001 associé ensuite Routing de L2 VNI 100001 vers L2 VNI 200002 du VLAN 20, le deuxième VTEP réalise le bridging de L2 VNI 200002 vers VLAN 20). Le routage symétrique ( Le premier VTEP réalise le Bridging du VLAN 10 au L2 VNI 100001 ensuite Routing de L2 VNI 100001 vers L3 VNI 5000, le deuxième VTEP réalise le routing de L3 VNI 5000 vers L2 VNI 200002 ensuite bridging de L2 VNI 200002 vers le VLAN 20 ).
Dans le routage asymétrique, les leafs doivent être configurés avec tous les segment L2 VNI, ce qui permet de faire l'apprentissage de MAC/IP et de remplir la table MAC et la table ARP de tous les hôtes car y'a une préservation de l'entête ethernet Inner L2 (celle des hosts) dans le paquet VXLAN.
En termes d'évolutivité et de performance, cela peut générer une densité et une augmentation de la taille des deux tables. D'où la recommandation d'utiliser le routage symétrique qui lui ne préserve pas l'entête ethernet Inner L2 dans le paquet VXLAN, le leaf remplace l'entête ethernet Inner L2 avec une adresse spéciale appelée Router MAC (source router mac du VTEP local et destination router mac du VTEP distant).
