Vincent Bernat nous présente VXLAN : un « protocole permettant de superposer un réseau virtuel L2 au-dessus d’un réseau IP existant avec quasiment aucune configuration. […] Par rapport aux VLAN, tout en gardant le principe d’isolation, les VXLAN apportent les avantages suivants : […] [il] permet de numéroter suffisamment de VXLAN pour isoler de très nombreux clients ; Les segments VXLAN ont alors un champ d’action plus important que les VLAN. ». C'est très technique et très intéressant.

Suites :

• Les différentes manières de faire du VXLAN unicast. Je retiens :

Il n’y a pas de solution universelle.

L’utilisation du multicast s’impose si :

• vous êtes dans un environnement où le multicast est disponible,
• vous êtes prêts à opérer (et étendre) un réseau multicast,
• vous avez besoin du multicast et du broadcast dans les segments virtuels,
• vous ne disposez pas des adresses L2/L3 utilisées par les locataires.

Cette solution reste valable avec plusieurs milliers de locataires si l’on prend garde à ne pas mettre tous les VXLAN dans le même groupe multicast (par exemple, en utilisant le dernier octet du VNI comme dernier octet du group multicast).

Quand le multicast n’est pas disponible, une autre solution générique est BGP EVPN : BGP est utilisé comme contrôleur pour assurer la distribution de la liste des VTEP et de leurs FDB. Comme indiqué précédemment, Cumulus Quagga fournit une implémentation de cette solution. J’explore davantage cette option dans un article séparé : « VXLAN: BGP EVPN avec Cumulus Quagga ».

Si vous êtes dans un environnement utilisant des conteneurs avec un registre, une solution reposant sur la gestion statique et/ou dynamique des entrées L2 et L3, sans apprentissage automatique des adresses, convient également. Elle apporte une meilleure sécurité (limite des ressources utilisées, protection contre les attaques MiTM, maîtrise de la bande passante). Différentes solutions sont disponibles selon l’orchestrateur utilisé7. Il est aussi possible d’écrire sa propre solution.

• Focus sur l'une des manières de faire en unicast : BGP EVPN. Je retiens :

BGP EVPN repose sur BGP (RFC 4271) et ses extensions MP-BGP (RFC 4760). BGP est le protocole de routage animant Internet. Via les extensions MP-BGP, il peut être utilisé pour transporter des informations d’accessibilité (NLRI) pour divers protocoles (IPv4, IPv6, L3 VPN et dans le cas qui nous intéresse, EVPN). EVPN est une famille spéciale permettant de publier des informations sur les adresses MAC et les équipements terminaux y donnant accès.

[…]

Usuellement, le déploiement de BGP EVPN utilise plusieurs réflecteurs de routes (à la fois pour la redondance et la montée en charge) comme illustré ci-dessous. Chaque VTEP ouvre une session BGP vers au moins deux réflecteurs, envoie les informations dont il dispose et réceptionne les informations disponibles. Cela permet de limiter le nombre de sessions BGP à configurer et maintenir.

Par rapport aux autres solutions pour déployer VXLAN, BGP EVPN présente trois avantages :

• interopérabilité avec les autres constructeurs (notamment Juniper et Cisco),
• montée en charge éprouvée (un routeur BGP gère plusieurs millions de routes),
• possibilité de mettre en place des politiques de distribution.

Sous Linux, Cumulus Quagga est une implémentation relativement complète de BGP EVPN (routes de type 3 pour la découverte de VTEP, routes de type 2 pour partager MAC et IP, mobilité des adresses MAC quand un hôte passe d’un VTEP à un autre) et ne nécessite que peu de configuration.

Il s’agit d’un dérivé de Quagga et est utilisé extensivement dans Cumulus Linux, une distribution réseau basée sur Debian et animant diverses marques de commutateurs. Dans le futur, l’implémentation de BGP EVPN sera reversé au projet FRR, un dérivé maintenu communautaire de Quagga3.

Notons toutefois que cette implémentation de BGP EVPN ne prend actuellement en compte qu’IPv4.