VXLAN et EVPN expliqués : VNI, VTEP et routes BGP

Un VLAN ID tient sur 12 bits : environ quatre mille segments, dans un domaine de niveau 2 qu'il faut étendre à travers tous les switchs, avec le spanning tree qui bloque des liens.

VXLAN conserve le niveau 2 pour les serveurs, mais le construit au-dessus d'un underlay routé de niveau 3, où chaque lien transmet et où les chemins de coût égal se partagent la charge. Son identifiant de segment, le VNI, tient sur 24 bits : environ seize millions de segments.

Un VTEP, l'extrémité du tunnel, encapsule la trame d'origine. D'abord un en-tête VXLAN de 8 octets, avec le drapeau I positionné et le VNI sur 24 bits. Puis UDP, port de destination 4789, avec un port source calculé par hachage de la trame interne, pour que l'underlay répartisse les flux sur ses chemins.

Ensuite un en-tête IP externe, du VTEP local vers le VTEP distant, et un en-tête Ethernet externe. La RFC 7348 le définit, en tant que document informationnel et non en tant que norme.

Ces en-têtes coûtent 50 octets sur IPv4 : 14 d'Ethernet, 20 d'IP, 8 d'UDP et 8 de VXLAN. Cisco indique qu'un overlay à 1500 octets exige un transport d'au moins 1550. Juniper parle de 50 à 54 octets.

La RFC interdit au VTEP de fragmenter, et Juniper comme Aruba ne prennent pas en charge la path MTU discovery sur VXLAN. La MTU de l'underlay n'est donc pas un paramètre d'optimisation. C'est une exigence, et Aruba considère 9000 comme la valeur idéale.

Le VXLAN d'origine apprenait comme un switch : inonder le trafic inconnu vers un groupe multicast par VNI, et apprendre quelle MAC se trouve derrière quel VTEP à partir des paquets qui reviennent. Cela exige du routage multicast dans l'underlay, et cela inonde à grande échelle.

BGP EVPN le remplace par un plan de contrôle. Chaque VTEP annonce ses propres adresses MAC et IP dans BGP, et tous les autres VTEP les apprennent avant le premier paquet.

EVPN compte cinq types de routes que vous rencontrerez. Le Type 2 transporte une adresse MAC, et souvent son IP. Le Type 3 annonce un VTEP pour un VNI, afin que les autres sachent où envoyer le trafic broadcast et inconnu.

Les Types 1 et 4 servent au multihoming : Ethernet auto discovery, et Ethernet segment. Le Type 5 transporte des préfixes IP, des sous-réseaux entiers ou des routes externes. Avec VXLAN, le VNI est porté dans le champ label de ces routes.

Le trafic broadcast, unicast inconnu et multicast existe toujours. Avec l'ingress replication, le VTEP émetteur copie la trame vers chaque VTEP appris par les routes de Type 3, et Cisco précise que cela ne nécessite aucun multicast dans l'underlay. L'alternative est un groupe multicast par VNI.

Juniper prend en charge l'ingress replication, mais ni PIM bidir ni PIM SSM avec VXLAN. L'ARP suppression réduit encore l'inondation : le leaf répond aux requêtes ARP à partir de ce qu'EVPN lui a déjà appris.

Ce que chaque VTEP importe est décidé par les route targets. Cisco peut les dériver automatiquement du numéro d'AS et du VNI, mais la RFC 8365 limite cela aux numéros d'AS sur 2 octets, et Cisco exige des route targets manuels en eBGP.

Si l'un d'eux est faux, Huawei décrit le résultat : une extrémité accepte la route et construit un tunnel, l'autre non, et les paquets sont supprimés. Une fabric à sens unique.

Le routage entre sous-réseaux s'appelle l'IRB. Chaque leaf est la passerelle, avec la même adresse anycast et la même MAC, si bien qu'un serveur conserve sa passerelle où qu'il se déplace.

En IRB asymétrique, le leaf d'entrée route puis commute, donc chaque leaf doit porter tous les sous-réseaux. En IRB symétrique, les deux leafs routent, via un L3 VNI par VRF, et chaque leaf ne conserve que ses sous-réseaux locaux. Aruba utilise l'IRB symétrique pour les passerelles distribuées. Chez Juniper, le mode par défaut est asymétrique, le symétrique étant une option.

Un serveur peut se connecter à deux leafs avec un seul agrégat de liens. Les deux leafs partagent un Ethernet segment identifier (ESI) de dix octets, et l'annoncent avec des routes de Type 4 et de Type 1.

En mode all active, les deux leafs transmettent. L'un d'eux est élu designated forwarder pour le trafic broadcast sur chaque VLAN, et le split horizon empêche une trame de repartir dans le segment d'où elle vient.

Sur Cisco NX-OS, un VLAN est associé à un vn-segment, et l'interface nve porte les VNI, avec BGP pour la joignabilité des hôtes. Sur Huawei, un bridge domain reçoit un VNI, et l'interface NVE réplique grâce à une liste de pairs head end.

Sur Aruba, l'interface vxlan associe les VNI aux VLAN et à une VRF. Sur Juniper, une instance MAC VRF avec une encapsulation EVPN VXLAN.

Pour vérifier les tunnels : show nve peers sur Cisco, display vxlan tunnel sur Huawei, show interface vxlan vteps sur Aruba, et show ethernet-switching vxlan-tunnel-end-point remote sur Juniper.

Examinez ensuite les routes EVPN elles-mêmes. Pas de route de Type 3 depuis un VTEP signifie pas de tunnel vers lui. Pas de route de Type 2 pour une MAC signifie qu'elle n'a jamais été apprise.

Trois pannes classiques. Une MAC qui se déplace trop souvent : la RFC 7432 considère cinq déplacements en 180 secondes comme un doublon, Cisco la met alors en attente (hold down), et après trois fois dans la journée, la gèle.

Un route target incohérent : la fabric à sens unique. Et une MTU d'underlay trop petite : les petits pings passent, tandis que les gros paquets disparaissent.

NacTrack relève les sessions BGP EVPN de chaque leaf et de chaque spine via SSH, quel que soit le constructeur, et liste chacune avec son pair, son AS distant, son état, ses préfixes et son uptime. Une session tombée, ou un leaf qui a nettement moins de préfixes que ses voisins, saute aux yeux.