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.
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 ».
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 :
cumulus@switch:~$ 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.