SDN – la guerre des Overlays !

Le SDN (Software Defined Network) est le sujet d’actualité du moment, sa déclinaison pour les réseaux en Datacenter porte le nom de SDDC (Software Defined Data Center) dont le concept consiste à virtualiser tous les composants de l’infrastructure DC (Réseau, Stockage, Compute, Sécurité) et de les délivrer comme des services, l’objectif final recherché est un gain en agilité.

Pour permettre cette virtualisation sur le domaine réseau, il faut d’abords réduire la complexité par à une abstraction de la couche réseau des services qu’elle porte par l’implémentation de :

• Une couche Underlay composée de commutateurs et de routeurs interconnectés ensemble pour transporter les paquets entre deux points du réseau : les décisions de commutation et de routage sont effectués par le calcul du « next-hop » en utilisant les protocoles L2/L3 traditionnels (OSPF, IS-IS, etc.)
• Une couche Overlay qui désigne le réseau virtuel implémenté sur l’infrastructure physique et qui permet d’apporter une abstraction des décisions de routage et de filtrage pour être au plus proche des applications et des services.

Dans cet article, nous allons nous intéresser de près à la couche Overlay qui crée beaucoup de confusions et de comparaisons (parfois inutiles) entre les constructeurs et éditeurs de solutions, le but recherché est de lister les avantages et inconvénients de chaque solution et d’identifier les impacts en terme d’architecture réseau et son évolutivité, performances, implémentation de la solution, gestes d’exploitation et de résolution d’incidents.

On distingue principalement deux modèles d’implémentations réseau de couche Overlay :

Modèle 1 :  Network Based  VTEP Model

Modèle 2 :  Host Based  VTEP Model

A noter qu’il y a aussi le modèle hybride (mixte des deux modèles) mais c’est souvent compliqué à mettre en place pour diverses raisons (kernel hyperviseur propriétaire, performances et support compliqué, évolutivité, etc.), certains constructeurs le proposent dans leur offre.

Principes de fonctionnement :

Dans le modèle 1, le tunnel VxLAN est réalisé sur des équipements réseaux (commutateurs L2/L3), ces derniers assurent les correspondances entre les VLAN et les VNI pour permettre de fournir les services de virtualisation réseau de niveau 2 et 3. (exemple : extension de Vlan et VRF)

Dans le modèle 2, le tunnel VxLAN (ou équivalent) est réalisé directement depuis les commutateurs virtuels (vSwitch) embarqués dans les hyperviseurs, ces vSwitchs implémentent les services de virtualisation réseau de niveau 2 et 3 pour permettre une segmentation de bout en bout.

Performances réseaux :

Le modèle 1 embarque sur les commutateurs (switchs) des ASICs (Application Specific Integrated Circuit) spécialisés dans le traitement de l’encapsulation VxLAN ce qui permet de fournir des performances optimales en terme de traitement réseau.

Le modèle 2 s’exécute sur des serveurs physiques qui embarquent des cartes réseaux de dernière génération et qui permettent de traiter l’encapsulation VxLAN en Plan de données réduisant ainsi les sollicitions CPU (ex DPDK : Data Plane Development Kit, et autres).

Bien que la fonction primaire et principale d’un switch est de traiter rapidement les paquets qu’il reçoit sur des ASICs spécialisés, les avancées technologiques sur les cartes réseaux des serveurs physiques de dernière génération permettent d’atteindre des performances de traitement optimales sans impact majeure sur la CPU, par conséquent, je pense que ce point n’est pas différenciateur entre les deux modèles d’architecture Overlay pour des volumes d’échanges raisonnables.

Implémentation de la solution :

Dans le modèle 1, l’implémentation du réseau Overlay est réalisée sur les mêmes équipements réseaux qui implémentent aussi la couche Underlay, ce modèle permet donc de disposer d’une seule infrastructure physique qui intègre simultanément les fonctionnalités « Underlay » et « Overlay ».

Le modèle 2 n’est pas autonome dans son fonctionnement, il s’exécute sur un réseau physique « Underlay » porté par des équipements réseaux, par conséquent, la configuration de la solution doit être réalisée à la fois sur le réseau « Underlay » ainsi que sur le réseau « Overlay » , cependant, les gestes de configuration sur le réseau « Underlay » restent assez simple puisque l’intelligence réseau est maintenant portée par le réseau Overlay.

• Avantage pour le modèle 1 qui permet de disposer d’un seul outil d’administration pour la configuration des réseaux Underlay et Overlay.
• Le modèle 1 permet d’apporter nativement une visibilité sur les deux couches « Underlay » et « Overlay » à travers son outil d’administration : on peut ainsi suivre le chemin physique parcouru par un flux sur la Fabric (Leaf->Spine->Leaf)
• Le modèle 2 nécessite certains prérequis sur le réseau Underlay (MTU, optimisation hash ECMP, ..) pour permettre son bon fonctionnement.
• L’automatisation réseau permet de simplifier l’implémentation de la solution pour les deux modèles.

Sécurité avancée :

Le modèle 2 permet d’être au plus proche des applications en environnement virtualisé : l’hyperviseur héberge les applications (VM, Conteneurs) et permet au VTEP d’avoir nativement (ou avec des options propriétaires) une meilleure connaissance de ces applications que le switch du modèle 1.

Le modèle 1 n’est pas autonome dans l’implémentation des fonctionnalités de sécurité avancée en environnement virtualisé, en effet, il doit soit s’interconnecter avec le contrôleur de la solution de virtualisation pour récupérer l’information et y appliquer des politiques de sécurité ou alors utiliser une solution tierce qui nécessite d’installer un agent sur les hôtes.

Pour les serveurs physiques (Bare Metal) raccordés sur l’infrastructure, la situation est inversée, en effet, le switch du modèle 1 est maintenant plus proche de l’application, ce qui lui permet d’implémenter plus facilement les fonctionnalités de micro-segmentation.

Dans le modèle 2, la gestion des serveurs physiques nécessite d’installer un agent sur ces serveurs pour permettre une continuité du réseau Overlay et aussi des politiques de sécurité, cette solution présente des contraintes de complexité de mise en œuvre et peut dégrader les performances dans certains cas (exemple sur les vieux serveurs d’ancienne génération très critiques et que personne n’ose toucher).

En conclusion :

• En environnement virtualisé, avantage pour le modèle 2 pour l’implémentation des fonctionnalités de sécurité avancées (micro segementation, FW et IPS distribué, SLB distribué ..)
• En environnement non virtualisé (bare metal), avantage pour le modèle 1 qui permet de fournir plus facilement les mécanismes de micro-segmentation sans nécessité d’installer un agent sur les serveurs.

Évolutivité « Scalability » :

Prenons le cas d’une petite architecture réseau ( ex LAB) composée de 2 Leafs, 2 Spines et 4 Hyperviseurs, la solution Overlay des deux modèles est résumée dans le diagramme ci-dessous :

Pour le même besoin de segmentation réseau (L2 et L3) :

• Le modèle 1 nécessite un seul tunnel VxLAN entre le VTEP1 et VTEP2, la segmentation vers les hôtes (VM) se fait en Layer 2 par l’utilisation traditionnelle des VLANs (limités à 4096).
• Le modèle 2 nécessite quatre tunnels VxLAN entre les VTEPs embarqués dans les switchs virtuels.

Étudions maintenant un cas de production d’une petite Fabric réseau avec les hypothèses ci-dessous :

• Infrastructure physique constitué de 5 paires de Leafs configurées en Anycast VTEP, soit 10 Leafs au total
• Chaque Leaf dispose de 48 ports 10G vers les serveurs et de 6 liens montant en 100G
• Chaque parie de Leaf héberge 10 hyperviseurs doublement raccordés

L’application du modèle 1 sur l’infrastructure nous donne cette architecture Overlay VxLAN :

• Pour ce modèle, pour permettre l’implémentation de la segmentation de niveau 2 et 3 sur l’ensemble de la Fabric, il faut disposer de 10 tunnels VxLAN en Full-Mesh (formule de calcul : n(n-1)/2)

L’application du modèle 2 sur la même infrastructure nous donne cette architecture Overlay VxLAN :

Pour ce modèle, pour permettre l’implémentation de la segmentation de niveau 2 et 3 sur l’ensemble de la Fabric, il faut disposer jusqu’à 1225 tunnels VxLAN en Full-Mesh (formule de calcul : n(n-1)/2 ).

• Le modèle 2 nécessite un nombre important de tunnels VxLAN pour permettre son fonctionnement, la multiplication des VTEPs introduit des opérations supplémentaires en terme de plan de contrôle, comme la découverte des autres VTEP, gestion des flux BUM (Broadcast, Unknown unicast, Multicast), etc.

• Implémenter uniquement VxLAN en Overlay n’est pas suffisant pour garantir une fiabilité de l’architecture, VxLAN implémente les mécanismes « Flood & Learn » qui présentent des limites en terme d’évolutivité à grande échelle, ce fonctionnement génère un nombre importants d’informations sur le réseau et n’est pas évolutif sur le long terme.

Exploitation réseau :

Les technologie réseaux (VxLAN, EVPN) sont généralement plus faciles à exploiter sur des équipements réseaux (physiques ou virtuels) par des équipes réseaux avec quelques années d’expérience, dans le modèle 2, ces fonctions sont portés par les hyperviseurs et nécessitent que les équipes en charge de ces hyperviseurs montent en connaissance pour l’exploitation des protocoles réseaux.

On constate aussi qu’en environnement LAB, l’exploitation de ces technologies est assez simple et réalisé en « best effort », cependant, en environnement de PROD disposant d’un nombre important de tunnel VxLAN, les compétences réseaux deviennent nécessaires pour la résolution d’incident ou pour résoudre un problème de performance, souvent, par manque de connaissances réseaux, la résolution d’un incident passe par un redémarrage de l’équipement avec un impact sur la disponibilité du service.

Un autre point important concerne les opérations de mise à jour de la couche Overlay (bugs, patchs de sécurité, nouvelles fonctions) qui sont de plus en plus courantes de nos jours, dans le modèle 1, c’est assez simple, on sort un leaf de la Fabric (mode maintenance), on le met à jour avec un redémarrage, et ensuite on le remet dans la Fabric, ces opérations peuvent être réalisés sans impact sur les applications dans une Architecture Fabric en Haute Dispo.

Pour le modèle 2, c’est plus complexe, les mises à jour nécessitant un redémarrage de l’hyperviseur nécessitent de déplacer les applications sur un autre hyperviseur, il y a aussi plus d’opérations de mise à jour à réaliser dans le modèle 2 que le modèle 1 (dans notre exemple, 10 opérations pour le modèle 1 contre 50 opérations pour le modèle 2).

Conclusion :

la solution du modèle 1 permet d’implémenter une solution orientée politique réseau et agnostique avec les équipements d’extrémité (hyperviseur, bare metal, pare-feu, slb) qu’elle connecte, elle est souvent préférée par les équipes réseaux qui mène cette initiative.

La solution du modèle 2 est s’adapte parfaitement aux environnements virtualisés qui souhaitent disposer d’une orchestration transverse, elle est souvent préférée par les équipes Datacenter ou virtualisation.

Personnellement, je préfère laisser les fonctions réseaux portés par des équipements réseaux et exploitées aussi par des équipes réseaux, et aussi implémenter la couche de sécurité avancée apportée par le modèle 2 pour renforcer l’architecture et d’être au plus proche des applications.

Un bon compromis serait :

• Implémenter les fonctions Overlay dans le modèle 1 (network VTEP Overlay)
• Implémenter les couches de sécurité avancées (ex µSeg) dans le modèle 2 sans couche Overlay

Biensur, il n’y a pas de solution universelle qui s’adapte à tous les environnements, il faut choisir la meilleure solution suivant l’organisation de l’entreprise ainsi que des ressources et des moyens dont elle dispose, les deux modèles sont souvent complémentaires dans beaucoup de cas d’études, mais est ce que votre portemonnaie est capable de les financer ? Ce point est important et ne doit pas être négligé dans le choix de votre solution SDN.

Et vous ? quel modèle préférez vous ? pour quelles raisons ? votre opinion nous intéresse en commentaire de cette page.

Si vous avez des questions, un autre avis sur le sujet ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.