Si par erreur, vous vous retrouvez sur cette page alors soyez des a présent en joie. Dans le cas où cela est dû à un besoin d’accroitre votre connaissance en vxlan ou bgp-evpn ou docker ou sur la stack open source FRR (Free Range Routing), alors vous être au bon endroit. Avant d’entamer les aspects de configuration, il est vital que je vous partage quelques lignes sur le quoi et le pourquoi de ces technologies que nous allons manipuler dans la suite de cet article. Commençons par le VxLAN.
Alors la Fameuse VxLAN – Je dirai la technologie qui sauve.
Je commence par vous partager sa référence - RFC 7348. Le besoin vient initialement des environnements data centers dans lesquels il faudrait isoler au niveau de la couche 2 un très grand nombre de groupe de machines, étendre ce réseau de niveau 2 dans toute l’infrastructure, et faciliter la mobilité d’une machine d’un switch (ou point de rattachement) à un autre.
Isoler logiquement (au niveau 20 des groupes de machines continue d’être effectue via la technologie VLAN qui permet de créer jusqu’à 4096 groupes dont 4094 utilisables vu que le VLAN 0 et 4095 sont réservés. (La valeur de 4096 est dû au fait que l’identifiant VLAN -VID est coder sur 12 bits). Cependant dans les environnements Cloud ou nous avons des dizaines voire des centaines de milliers de clients, cette valeur devient insuffisante pour regrouper les ressources de chaque client sur une même infrastructure.
Une technique intermédiaire souvent utiliser est le QinQ qui n’est rien d’autre que l’ajout d’un tag vlan sur une trame déjà tagger (on parle de double tags). Cette méthode 802.1Q-in-Q permet de transporter le trafic provenant de n’importe lequel des VLANs d’un client de façon unique sur une infrastructure public (donc transportant de même le trafic d’autres clients). Cela implique les concepts de Inner tag (pour la première étiquette vlan provenant du client – Customer Tag) et Outer tag (pour la seconde étiquette vlan ajoutée par le réseau de transport – Provider Tag). Du coup, un client avec ses 4094 VLANs peut voir son trafic être transporter de façon isoler en lui associant un seul VLAN ID/Tag sur le réseau public. J’ai eu l’opportunité de troubleshooter un scenario très complexe de QinQ pour un opérateur de service européen. Je prendrai donc le plaisir dans un article séparer de vous démystifier cette technologie avec un cas concret.
Revenons au vxlan – alors elle satisfait ce premier besoin par le fait qu’elle offre un format d’entête dans lequel l’identifiant (VNID - nommée VxLAN Identifier) est coder sur 24 bits, ce qui offre 2^16 possibilités soit environ une capacite de création jusqu’a 16 millions de groupement logique au niveau 2. Ce qui est le premier avantage majeur du VxLAN.
Quant au second besoin – étendre le réseau LAN (Niveau 2) d’un tenant / client sur toute l’infrastructure. Basiquement le VLAN ne permet pas cela dans un environnement router. En effet, le trafic niveau 2 (provenant d’un LAN) ne peut aller au-delà d’une interface de niveau 3. Imaginons ensemble, un switch sur lequel est configure un VLAN X. Ce même switch connecte à un routeur sur une interface de niveau 3 (supporte par une adresse IP). Tout trafic de type broadcast ou a destination d’une IP dans le même sous réseau LAN du VLAN X, ne peut pas traverser l’interface de niveau 3 du routeur. On dit alors cette interface délimite le domaine de ce VLAN X (L3 boundary). Encore cela rend le VLAN X localement significatif (connu et que sur son switch local.
Si vous me demandez mais comment faisions-nous pour étendre (on parle de stretch) le trafic d’un VLAN avant l’avènement du VxLAN ? - la méthode utilisée dans les Data Centers, a été de construire un grand réseau purement de niveau 2 dans lequel règne pleinement le STP (Spanning Tree Protocol). Encore, la présence du STP pose un problème dans les Data Center modernes, car le Spanning Tree accompli son rôle d’empêcher des boucles dans le réseau en bloquant certains liens redondants. Bloquer un lien redondant signifierait à limiter la capacité de transfert du réseau en question, ce qui n’est pas intéressant. Avoir des liens très couteux de 10G ou 40G ou 100G et les voir être inutilise car bloquer par le STP devient de plus en plus inadmissible. Comment éviter au maximum le STP, c’est d’avoir des liens de niveau 3 (chacun des deux bouts d’un lien est rattaché à une adresse IP – directement ou indirectement), donc un réseau de transport routé (on dira - routed network). C’est dans ce type d’environnement que le VxLAN va jouer sa magie. Alors, le VxLAN permettra d’étendre un VNI (voir comme un VLAN amélioré) d’un switch a un ou plusieurs autres switches qui sont tous connectes même via un réseau de niveau 3. Donc le VxLAN permet de construire (ou d’étendre) un réseau logique de niveau 2, au-dessus d’un réseau de niveau 3. On qualifie le réseau de niveau 3, de Underlay network (réseau sous-jacent) et le réseau de niveau 2 construit par le VxLAN, d’Overlay network (réseau superposé).
Terminons la magie du VxLAN avec le troisième point – permettre aux machines de se balader dans l’infrastructure réseau, ce qui est un besoin crucial pour les machines virtuelles. En effet, avec les solutions de virtualisation, une machine virtuelle peut être recréer ou transférer (pour des besoins de capacite ou d’emplacement ou de reprise d’activité etc.) et rattaché à n’importe quel switch tout en gardant son adresse IP, du coup, il faudra que le nouveau point d’atterrissage de la machine virtuelle soit capable d’acheminer le trafic de cette VM (Virtual Machine) dans son sous-réseau, en d’autres elle doit pouvoir communiquer avec les autres machines de son domaine réseau dans qu’il y de modification préalable à effectuer. Cela nous ramène au second point précédemment discuté - extension du réseau de niveau 2 dans toute l’infrastructure.
En somme, le VxLAN est principalement définie comme une technologie qui permet de construire environ 16 millions de réseaux de niveau 2 au-dessus d’une même infrastructure de niveau 3, ce qui la rend magique pour les fournisseurs de service Cloud.
Clôturons le paragraphe du VxLAN par une petite explication sur le comment elle opère sa magie. Une machine A qui désire transmettre une donnée à une autre machine B du même réseau, détient au préalable l’adresse IP de la machine B (IP-A) et devra avoir l’adresse MAC de B (MAC-B). Un message de diffusion de type ARP Request sera initiée par la A au cas où elle ne détient pas dans sa table ARP cette MAC-B. Supposons que la machine A détient cette information (MAC-B). Alors, A va devoir construire le paquet à expédier vers B. On suit le modèle TCP/IP, donc les 4 couches seront parcourues dans cet ordre : Application – Transport – Réseau – Liaison de données. La data sera injectée au niveau de la couche Application, et sera transmise à la couche Transport afin que celle-ci ajoute son entête. Une fois le Transport (TCP ou UDP en fonction du type de protocole ayant généré la donnée) ajoute les ports source et destination et autres informations, le tout sera à nouveau transmis à la couche réseau IP. Le Réseau ajoutera au moins les adresses IP source (IP-A) et destination (IP-B), puis interrogera la table ARP afin d’avoir l’adresse MAC-B, et le tout sera transmis à la couche liaison de données. A cette dernière étape, l’entête Ethernet sera fabriquée puis ajouter au paquet, l’entête sera constitué d’au moins des adresses source (MAC-A) et destination (MAC-B). La trame sera transmise au switch auquel la machine A est connectée via son interface réseau.
On suppose que le port auquel est connecte la machine A est dans un VLAN X mappé au VNID X. Une fois l’information reçue au niveau du port switch (sur lequel la configuration du vxlan a été faite), le VLAN ID auquel sera inséré dans la trame. Puis, le switch effectuera nue recherche dans la table d’adresse mac du VLAN X afin de savoir vers quel port est associe l’adresse de destination MAC-B. Lorsque le switch (SW-A) constatera que la MAC-B a été apprise via son interface VXLAN (appelée VTEP) depuis un autre switch (SW-B), il devra donc constituer un autre entête qui sera l’entête vxlan afin d’acheminer le paquet vers SW-B. Dès lors, tout le paquet initialement envoyé par la machine A (y compris le VLAN A) sera considéré comme la nouvelle data / donnée du point de vue du switch.
En termes vxlan, on qualifie les détails de la donnée initiale de Inner Headers, et les nouvelles entêtes (qui seront ajoutées par le switch due au VXLAN) de Outer Headers. Voilà pourquoi il est important d’augmenter les valeurs MTU (IP & Ethernet) lorsqu’on fait du VXLAN sur l’infrastructure afin d’éviter les fragmentations inutiles des paquets. L’idée est de configurer les valeurs maximales pour les MTU.
Alors, le switch commence par insérer le VNID X sur le paquet initial a la suite du VLAN ID. Puis, procèdera de la même façon en suivant le modèle TCP/IP. Au niveau Transport un port source sera choisi, puis l’adresse de destination sera le port par default du VXLAN 4789, puis au niveau Réseau, l’adresse IP source sera celle de la VTEP (interface VXLAN du switch SW-A), l’adresse IP destination, celle de la VTEP du switch destination (SW-B) et les mac source / destination respectivement celle des VTEP SW-A et SW-B. Ce procédé est appelé Encapsulation VXLAN, car toute la donnée initialement envoyée par la machine A sera enclavée (considérée comme la nouvelle donnée) dans ce nouveau paquet vxlan. Une fois, toute cette information arrivée au niveau du SW-B, une décapsulation sera faite. Apres avoir vérifié qu’il est le destinataire, le SW-B retirera les entêtes VxLAN (Outer Headers), et constatera qu’il s’agit d’un paquet à envoyer à la MAC-B du VLAN X. Une recherche sera faite dans la table d’adresse MAC du VLAN X afin de déterminer le port auquel est rattache cette MAC-B (c’est-à dire la machine B). Finalement, le VLAN ID sera retiré puis le paquet interne sera envoyé sur ce port afin que la machine B récupère la donnée envoyée par la machine A.
Voici donc, en quelques lignes, comment opère la magie du VXLAN. Mais dans cette description, les VTEP était configurées les switchs (SW-A et SW-B) donc on parle de Gateway-based VXLAN. On peut avoir des VTEP virtuelles c’est-à dire montées sur des machines virtuelles par exemple, on parlera de Host-based VXLAN (comme Host-based Overlays). Et c’est ce dernier cas que nous configurerons dans notre TP. Le principe de fonctionnement du VXLAN reste identique quel que soit le modèle (Gateway ou Host based). Je me ferai le plaisir de vous rédiger un article avec plus de détails et diagrammes sur ce sujet du VXLAN.
Avant, d’abordons la seconde technologie majeure de notre article, ci-dessous le lien de la RFC VXLAN pour plus de détails théoriques.
https://datatracker.ietf.org/doc/html/rfc7348
BGP-EVPN – Le BGP n’a pas encore fini de nous surprendre par ses capacités.
Au regard des détails partagés sur le VxLAN, retenons que le VxLAN est une technologie Overlay de niveau 2. La notion de niveau 2 est directement lié à la notion d’adresse MAC. Dans un réseau de niveau 2 (dans un VLAN ou simplement un LAN), l’acheminement du trafic d’une machine à une autre est effectué en fonction de l’adresse MAC de la machine destinataire. Cela signifie que la machine source (celle qui émet le trafic) doit connaitre l’adresse MAC de la machine de destination, et au moins les commutateurs source (switch qui est connecté à la machine source) et destination (switch qui est connecté à la machine destinataire) doivent être informé des adresses mac des deux machines (présence dans leur table d’adresse mac associée à leur sous réseau LAN – une table d’adresse mac sur un switch est construite par VLAN).
Un autre fait très important est qu’un switch n’apprends l’adresse mac d’une machine lorsqu’il reçoit un premier trafic (qui peut être de type unicast ou broadcast / diffusion) de cette machine. Le trafic broadcast sera une requête ARP initie par une machine désirant communiquer avec une autre de son réseau. Une fois un tel message diffus, tous les switches qui le recevront, auront donc connaissance de l’adresse mac de la machine source. Qu’est-ce cela implique ?
Imaginions une fois de plus, un réseau VxLAN étendu sur plusieurs switches, ce réseau LAN contient de milliers de machines (donc d’adresse mac) distribuées sur ces commutateurs. Comment faire pour que, dès l’instant ou une adresse mac est connue sur un switch celle-ci puisse être de même connue sur les autres switches (ou sont rattachées des machines du même réseau) afin d’éviter des diffusions de requêtes ARP indéfiniment (car la diffusion est consommatrice de bande passante et de capacite de traitement) ? Comment faire de sorte que les switches qui ont appris à un moment donne, l’existence d’une adresse mac (donc d’une machine) à un endroit précis (sur un switch bien défini) mettre à jour cette information dans leur base, après que cette même adresse mac soit déplacée (car la machine a été déplacer vers un autre switch) ?
Naturellement, le réseau finira par s’auto informer, toutefois cela entrainera des coupures de communication des machines car les informations en base seront à un instant donné erronées (non synchronisées). Un tel environnement comportant plusieurs autres réseaux VxLAN de plusieurs machines, posera plusieurs problèmes et sera très instable et difficile à contrôler, donc à faire évoluer. On dira que le réseau n’est pas scalable (évolutif) au niveau du plan de contrôle (gestion des informations permettant le bon fonctionnement des VxLANs).
C’est en ce sens que le BGP (initialement conçue pour Internet afin de propager des adresses IP) a été une fois de plus sollicité dans ses capacités MP (pour son support Multi-Protocolaire). Une nouvelle sous-variante a été définie dans la famille des VPN de niveau 2 (L2VPN), afin de pouvoir propager des adresses MAC. Cette sous famille est le EVPN pour Ethernet VPN, ou Ethernet ramène à la notion de niveau 2, donc quelque part aux adresses MAC. Elle est définie par la RFC 7432.
https://datatracker.ietf.org/doc/html/rfc7432
Il est important que je vous partage un petit rappel sur le BGP dans notre contexte. Au départ, le protocole BGP a été amélioré afin de pouvoir transporter plusieurs types d’adresses autre que IPv4 ensemble, ce qui a donné naissance au MP-BGP. Alors BGP est devenu capable de propager des IPv4 (unicast comme multicast), IPv6 (unicast et multicast), VPNv4 (unicast et multicast) utilisé pour propager les informations dans un réseau Overlay de niveau 3 (qualifie de L3VPN) ou le MPLS est utilisé pour acheminer le trafic. Nous avons de même la famille d’adresse VPNv6 (unicast et multicast) pour le transport des routes IPv6 et finalement la famille des adresses L2VPN (pour construire les réseau Overlay de niveau 2). C’est dans cette dernière famille que se trouve le EVPN qui vient s’ajouter à la sous-famille VPLS. Dans le langage BGP, on utilisera le terme AFI (Adresse Family Indicator) pour une famille d’adresse (ipv4, ipv6, l2vpn, vpnv4, vpnv6 etc.), et SAFI (Subsequent Address Family Indicator) pour chaque sous famille (unicast, multicast, vpls, evpn …). Je vous partagerai un article bien détaillé avec un scenario de configuration sur chacune de ces familles.
Dans notre Lab de démonstration, notre protocole de transport (ou de signalisation) est le MP-BGP EVPN et a pour AFI le L2VPN et pour SAFI le EVPN. On conclut en disant, le VxLAN est le protocole utilisé pour acheminer le trafic. Il assure donc le Forwarding Plane tandis que le MP-BGP EVPN assure le Contrôle Plane.
Dans la seconde partie de cet article, je vais vous présenter la beauté de la solution de routage logicielle et comment est-ce qu’elle est utilisée pour accomplir des merveilles dans par les géants du Cloud (IaaS et SaaS et CaaS tous confondus). Nous commencerons par regarder ce que Linux offre en termes de Networking et comment est-ce que Docker gère les aspects réseaux de ses conteneurs. Nous finirons par injecter step by step les configurations avec une approche d’apprentissage approfondie (du genre à la TAC Engineer). J’analyserai si je dois produire la deuxième partie de cet article en anglais ou en français. En fait, étant donné que j’ai passé les deux dernières années à parler et écrire uniquement en anglais (ici en Pologne), je suis plus à l’aise à cracher du contenu en anglais. Mais bon, je verrai. Restez à l'ecoute.
♥ Like Tags: cloud networking vxlan bgp-evpn linux docker frr Retour Aux Articles