VXLAN et MP-BGP EVPN

Dans un précédent article nous avons présenté VLXAN.

STT, NVGRE et GENEVE sont d’autres exemples de protocoles d’encapsulation qui permettent de construire un overlay (à la manière d’IPSEC dans certains déploiements de Kubernetes sur un Cloud public) pour des réseaux de type SDN.

Un point d’attention particulier est la façon dont les points de terminaison (VTEP : VXLAN Tunnel EndPoint) découvrent leurs pairs et renseignent la table de correspondance (ou mapping) @MAC <=> VTEP.

 Topologie simpliste VXLAN (les switches sont VTEP, nombre limité à 2)

Dans un environnement limité, les premières solutions constitaient à :

  • configurer un mapping statique ; assez peu pertinent quand les workloads sont censés être parfaitement mobiles entre VTEP, et éphèmère
  • construire une mapping dynamique en s’appuyant sur du Multicast IP. Cette solution n’est en général pas possible sur du cloud public (OVH, AWS..) car le Multicast est interdit (ou plus exactement pas tranmis/routé)
  • construire un mapping pseudo dynamique à base de scripts PowerShell.

Une solution d’envergure et interopérable, consiste à utiliser BGP pour faire transiter ces mappings @MACs <=> VTEP. BGP est réputé pour être robuste, extensible et sclable. Les messages Route Type 2 et Route Type 5 sont utilisés pour transmettre les @MAC et les @IP avec leurs mappings VNI,VTEP.

Ansi est né MP-BGP EVPN, RFC7348. « MP » fait référence à « Multi-Protocol ».

 Topologie VXLAN BGP VPN avec Route Reflectors

On peut notamment  utiliser toutes les techniques de mise à l’échelle de BGP, par l’utilisation de Route Reflector.

La table de correspondance ainsi construite prend cette forme :

[email protected]:~$ net show evpn arp-cache vni 10100

Number of ARPs (local and remote) known for this VNI: 9IP              Type   MAC               Remote VTEP          50.1.1.11       local  00:02:00:00:00:01 50.1.1.12       local  00:02:00:00:00:02 50.1.1.22       remote 00:02:00:00:00:04 110.0.0.2            2001:50:1:1::11 local  00:02:00:00:00:01 50.1.1.31       remote 00:02:00:00:00:05 110.0.0.3            50.1.1.42       remote 00:02:00:00:00:08 110.0.0.4            50.1.1.21       remote 00:02:00:00:00:03 110.0.0.2            50.1.1.32       remote 00:02:00:00:00:06 110.0.0.3            50.1.1.41       remote 00:02:00:00:00:07 110.0.0.4

Cisco fournit un ebook gratuit sur ce large sujet (A Modern, Open, and Scalable Fabric: VXLAN EVPN). Les autres constructeurs (par ex Arista, Juniper) ou bien éditeurs commerciaux (par ex. VMWARE NSX, plus exactement au niveau des Edge) ou OpenSource (ex Quagga et Cumulus Linux) supportent également BGP EVPN.

Contrairement aux schémas précédents issus de la documentation Cisco, dans les déploiements que nous effectuons en Cloud Public, comme dans la plupart des cas réels, la fonction VTEP est directement portée par l’Hyperviseur, soit nativement soit par le biais d’un container (exemple direct de NFV).

Bien que la RFC date de 2014, nous n’en sommes encore qu’au début de l’implémentation dans les équipements; l’interopérabilité devrait être assurée à terme, des travaux sont en cours à l’IETF.

N’hésitez pas à nous faire vos remarques dans les commentaires ou à nous contacter si vous souhaitez plus de détails ou de l’accompagnement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.