Virtualisation des réseaux en

environnement vSphere avec NSX

Julien Cabessut
Université Toulouse Jean Jaurès
5 allées Antonio Machado
31058 Toulouse

Résumé
Basée sur l'expérience acquise dans le cadre du projet de Cloud privé de l'Université Fédérale de Toulouse
Midi-Pyrénées (UFTMiP), cette présentation a pour objectif de faire un tour d'horizon du concept de
virtualisation des réseaux tel qu'il est implémenté par VMware. Je me focaliserai sur la version NSX-V
dédiée aux hyperviseurs ESXi, en la comparant brièvement avec la version NSX-T (pour hyperviseurs
KVM) et les technologies similaires proposées par d'autres solutions (OpenStack Neutron, Cisco ACI).

En première partie, j’expliquerai le fonctionnement général de cette plateforme et la façon dont elle
s'intègre dans un environnement vSphere. Je m’attarderai sur le concept de VXLAN et de VTEP
permettant l'abstraction de la couche réseau physique. Je détaillerai les avantages et inconvénients de cette
solution en termes d'implémentation et d'exploitation, en comparaison avec les réseaux traditionnels.

La deuxième partie se focalisera sur la sécurité, présentant les notions de micro-segmentation et de sécurité
contextuelle apportées par le pare-feu distribué. Nous verrons en quoi ce composant permet d'améliorer la
segmentation par rapport aux solutions historiques : pares feux périmétriques ou VLAN privés.
J’expliquerai également son intérêt dans un contexte de provisionnement de machines virtuelles en
association avec vRealize Automation.

Je terminerai par la description d'un composant essentiel de l'architecture NSX : l'Edge Service Gateway,
routeur périmétrique à la frontière des réseaux physiques et virtuels, en détaillant les différents services
qu'il permet d'implémenter sur les réseaux virtualisés (filtrage, NAT, VPN, routage et haute-disponibilité).

La conclusion présentera le bilan de deux ans d'exploitation de VMware NSX sur un environnement de
production.

Mots-clefs
Réseaux, virtualisation, NSX, vmware, vsphere, micro-segmentation, sdn.

1 Introduction
Le Cloud Privé de l’UFTMiP est une infrastructure communautaire d’hébergement de machines virtuelles,
sur un modèle IaaS/PaaS, s’appuyant sur des équipements répartis dans les datacenters de 3 établissements.
L’ensemble des fonctions de virtualisation est basé sur la solution vSphere de VMware.
Le modèle architectural est de type stretch-cluster : les ressources des 3 datacenters sont vues comme un
cluster unique, géré par un seul vCenter. La réplication synchrone du stockage repose sur la technologie
LiveVolume de DELL. L’interconnexion entre les sites est assurée par le réseau métropolitain REMIP.

JRES 2017 - Nantes 1/15

 Figure 1 - Architecture stretch-cluster du Cloud UFTMiP
L’administration et l’interconnexion des équipements d’infrastructure sont effectuées au travers de réseaux
« traditionnels ». A contrario, les réseaux accessibles aux machines virtuelles sont entièrement virtualisés
grâce à la solution NSX.
La plateforme NSX est une implémentation propriétaire par VMware du concept de Software Defined
Networking (SDN). Il en existe deux versions : la première, NSX-V, est spécifique aux hyperviseurs ESXi
et totalement intégrée dans l’environnement vSphere. La seconde version, baptisée NSX-T, est destinée
aux environnements multi-hyperviseurs (ESXi et KVM) et vise à promouvoir l’intégration de NSX dans
les infrastructures basées sur OpenStack.
Les fonctionnalités proposées sont quasiment identiques pour les deux versions, la différence se situant
dans la façon dont elles s’interfacent avec les systèmes sous-jacents. Cette présentation se focalisera sur
NSX-V, qui est utilisée dans le cadre du Cloud Privé de l’UFTMiP.
NSX est en concurrence avec d’autres solutions proposant des fonctionnalités similaires. Parmi celles-ci,
on peut citer la plateforme ACI (Application Centric Infrastructure) de Cisco, qui implémente le SDN avec
une philosophie centrée sur les applications, en proposant un niveau d’abstraction élevé. On notera qu’elles
partagent un défaut commun : celui d’être VMware exclusive pour NSX-V, et d’être Cisco hardware-
dependant dans le cas d’ACI.
Le module Neutron d’OpenStack permet lui aussi de virtualiser et orchestrer de nombreux services réseau
dans une infrastructure Cloud, en présentant l’avantage d’être une solution libre et très modulaire grâce à
l’utilisation de plugins.

2 Concepts fondamentaux

2.1 Abstraction matérielle

La virtualisation des réseaux repose sur la même philosophie que la virtualisation système : elle consiste à
ajouter une couche d’abstraction entre le matériel et le logiciel afin de simuler un ou plusieurs équipements
physiques. Dans le cas de NSX, l’administrateur va créer des switches logiques afin d’y connecter les

JRES 2017 - Nantes 2/15

interfaces réseau des VM, et des routeurs logiques distribués pour interconnecter ces switches et assurer
le routage des flux IP.
Les réseaux ainsi créés sont appelés overlay. De la même façon qu’un processeur virtuel a besoin d’un
processeur physique pour exécuter une instruction, un switch logique a besoin d’un équipement réseau
physique pour transporter les données entre les hyperviseurs. Le réseau physique auquel sont connectés les
serveurs est appelé underlay.

Figure 2 - Réseaux underlay et overlay

Nous allons voir comment les différents composants de la plateforme NSX interagissent entre eux et avec
le réseau physique pour permettre le bon fonctionnement de ces réseaux virtualisés.

2.2 VXLAN, VTEP et Logical Switches

Le principe d’abstraction repose sur le protocole VXLAN (RFC 73481). Suite à l’installation de NSX,
chaque hyperviseur dispose d’une interface IP nommée Virtual Tunnel Endpoint (VTEP) qui lui permet de
créer des tunnels vers les autres hyperviseurs de son cluster. Le trafic de niveau 2 entre les VM hébergées
sur des hôtes distincts est encapsulé dans des paquets UDP par l’hyperviseur source, puis transporté sur le
réseau physique jusqu’à l’hyperviseur destinataire, qui effectue alors l’opération inverse et délivre la trame
L2 à la VM de destination.
Chaque paquet VXLAN est marqué par un identifiant (VNI) qui correspond au switch logique auquel est
connectée la VM de destination.
La gestion du plan de contrôle des VXLAN par NSX sera expliquée dans la section suivante.

1
https://tools.ietf.org/html/rfc7348

JRES 2017 - Nantes 3/15

 Figure 3 - Encapsulation L2 dans un tunnel VXLAN
Ce mode de transmission présente plusieurs avantages :
̶ Les équipements réseau qui interconnectent les hyperviseurs n’ont pas connaissance des
adresses MAC des machines virtuelles. Le plan de contrôle du réseau physique ne gère que
les adresses VTEP des ESX.
̶ Les équipements physiques n’ont pas connaissance des VXLAN. Ceux-ci sont gérés par
NSX, limitant les opérations de configuration sur le réseau physique.
̶ Les paquets VXLAN, correspondant au niveau 3 du modèle OSI, peuvent être routés. Ceci
permet d’étendre un même segment de niveau 2 (le switch logique) entre plusieurs
datacenters :

Figure 4 - Routage des paquets VXLAN

JRES 2017 - Nantes 4/15

L’encapsulation augmente la taille des trames qui circulent sur le réseau physique. Il est nécessaire de
modifier la valeur MTU de tous les équipements qui interconnectent les serveurs du cluster. Les
configurations utilisant des valeurs MTU standards ne sont pas supportées par VMware. Cette contrainte
est à prendre en compte si l’interconnexion dépend d’opérateurs qui ne proposent pas cette modification.

2.3 Routeur logique distribué (DLR)

Dans un environnement vSphere traditionnel, le routage est assuré par des équipements physiques. Cela
présente un inconvénient de taille : le trafic remonte la plupart du temps jusqu’au cœur de réseau, qui
effectue le routage, avant d’être à nouveau acheminé jusqu’à l’ESX de destination.

Figure 5 - Routage avec vSphere traditionnel

NSX permet d’améliorer ce fonctionnement en confiant les décisions de routage directement aux
hyperviseurs. Le trafic entre les différents VXLAN est donc limité aux ESX et aux switches auxquels ils
sont connectés. Si les deux VM sont hébergées par le même hyperviseur, le trafic est traité localement par
le CPU, permettant une réduction considérable de la latence.

Figure 6 - Routage avec le DLR NSX

JRES 2017 - Nantes 5/15

Cette implémentation du routage au sein du réseau virtualisé illustre les notions de trafic est-ouest, entre
les VM hébergées, et de trafic nord-sud qui désigne les flux entrants et sortants du datacenter.
L’autre avantage du DLR est de proposer un nombre d’interfaces presque illimité : il est possible de
connecter jusqu’à 999 switches logiques à un même routeur logique.

2.4 Contrôleurs et Logical Control VM (LCVM)

Le plan de contrôle est entièrement géré de façon logicielle et assuré par les contrôleurs NSX.
Il s’agit d’appliances déployées lors de l’installation, recensant l’ensemble des informations sur le
périmètre réseau virtualisé : tables MAC et ARP des switches logiques et des hyperviseurs, adresses IP des
VM, relations entre les tunnels et les interfaces VTEP, tables de routage. Les contrôleurs sont synchronisés
en temps réel avec les hyperviseurs.
Un autre composant essentiel du plan de contrôle est la Logical Control VM du routeur distribué. Pour
chaque instance de routeur virtuel déployée sur l’environnement, NSX crée une VM qui permet la
configuration du routeur et communique avec les contrôleurs NSX et les hyperviseurs afin de synchroniser
les informations. Dans les configurations utilisant du routage dynamique (BGP ou OSPF), la LCVM assure
le peering avec les routeurs voisins. La LCVM ne participe pas au data plane : les flux est-ouest ne transitent
pas par cette appliance et restent gérés par les hyperviseurs.

Figure 7 - Plan de contrôle NSX

2.5 NSX Manager

Le composant d’administration de la plateforme est le NSX Manager. Il s’agit, là aussi, d’une appliance
qui centralise la configuration de l’ensemble du réseau virtualisé et assure la communication et la
synchronisation avec le vCenter. Il propose une API REST qui permet d’administrer tous les composants
de la plateforme NSX et d’automatiser certaines tâches.
Les administrateurs NSX peuvent également accéder aux fonctions de configuration et de supervision de
la plateforme au travers du client web vSphere. L’intégration complète de NSX au client vSphere est l’un
des points forts de la solution NSX-V.

JRES 2017 - Nantes 6/15

 Figure 8 - Intégration du NSX Manager au client vSphere

2.6 Edge Service Gateway (ESG)

Le dernier élément, quasiment indispensable, de l’infrastructure NSX est l’Edge Service Gateway. C’est
une appliance déployée par l’administrateur NSX, qui participe simultanément au data plane et au control
plane. Elle se situe à la frontière entre le réseau virtualisé et le réseau traditionnel. L’ensemble des flux
nord-sud des machines virtuelles transite par l’ESG.
Son positionnement particulier dans l’architecture lui permet d’implémenter de nombreuses
fonctionnalités relevant des couches 3 à 7 du modèle OSI : NAT, DHCP, DNS, Load-balancer, et d’autres
services avancés que je détaillerai dans la dernière partie de cette présentation.

3 Sécurité et micro-segmentation
L’installation de NSX déploie sur les hyperviseurs un troisième module : le pare-feu distribué (DFW). Si
les composants présentés jusqu’ici ne font que virtualiser des fonctionnalités déjà existantes sur les réseaux
physiques, le pare-feu distribué permet une nouvelle approche de la problématique de sécurité concernant
les datacenters virtualisés.

3.1 Une DMZ pour chaque VM

Dans un réseau traditionnel, les machines connectées sur un même segment réseau peuvent communiquer
entre elles sans restriction. Le premier stade du filtrage s’effectue au niveau des routeurs du cœur de réseau,
entre les différents VLAN, sous la forme d’ACL. Il faut remonter jusqu’aux pares feux périmétriques
sécurisant les différentes zones (LAN / DMZ) pour bénéficier d’une possibilité de filtrage évolué, ou tout
au moins stateful.
On peut limiter ce problème en utilisant des VLAN privés (PVLAN). Cette technologie, disponible sur la
plupart des switches d’entreprise et sur les vNetwork Distributed Switches vSphere, permet de restreindre
le trafic de niveau 2 entre des ports et/ou des groupes de ports situés dans un même VLAN. Suffisants dans
plusieurs cas de figure, les PVLAN restent toutefois limités au niveau 2, et peuvent s’avérer complexes à
mettre en œuvre et à gérer sur le long terme.
Le Distributed Firewall apporte une réponse plus adaptée à ce problème, en positionnant un firewall dédié
derrière chaque interface réseau des machines virtuelles. L’ensemble des flux issus des interfaces réseau

JRES 2017 - Nantes 7/15

d’une VM ou à destination de celles-ci transitent par l’instance de pare-feu qui lui est associée, et sont sujets
aux règles de filtrage définies par l’administrateur.
Si la politique de filtrage consiste à bloquer tout ce qui n’est pas explicitement autorisé, nous arrivons à une
situation où, par défaut, toutes les machines virtuelles du datacenter sont isolées les unes des autres,
quelle que soit leur proximité sur le réseau. Cette configuration originale est qualifiée de micro-
segmentation.

Figure 9 - Particularités de la micro-segmentation

Quelques éléments clés sur ce module :
̶ Il est géré par le noyau des hyperviseurs. L’utilisation directe des ressources CPU des serveurs
permet d’atteindre des performances proches de la capacité maximum du lien (« line-speed »).
En conséquence, les performances globales du pare-feu à l’échelle du datacenter augmentent
proportionnellement à la quantité d’hyperviseurs.
̶ Il s’applique sur les couches 2 à 4 du modèle OSI. Il est possible d’écrire des règles de filtrage
basées sur des adresses MAC, des adresses IP, et des ports source ou destination.
̶ Il est stateful. Ceci est généralement perçu comme un avantage, mais peut provoquer des
comportements inattendus dans une situation où une VM disposant de plusieurs interfaces
réseau génère du routage asymétrique qui sera bloqué par le firewall (on parle d’expérience !)
L’administration du pare-feu distribué s’effectue au travers d’une interface dédiée dans la
partie Networking & Security du client web vSphere.

JRES 2017 - Nantes 8/15

 Figure 10 - Interface utilisateur du pare-feu distribué
Le pare-feu distribué est indépendant des fonctions de virtualisation présentées en première partie. Il
s’applique par défaut à toutes les VM des hôtes protégés, qu’elles soient connectées à des switches logiques
(VXLAN) ou à des groupes de ports standards (VLAN).

3.2 Particularités de la micro-segmentation

Une question revient fréquemment à propos du pare-feu distribué : quel niveau de confiance lui accorder,
sachant qu’il est entièrement logiciel et embarqué sur les hyperviseurs ? L’expérience montre que certaines
techniques dites de VM escape peuvent aboutir à la compromission d’un ou plusieurs hôtes. Dans ces cas-
là, on peut considérer, dans l’absolu, que le pare-feu distribué n’est plus fiable et que toutes les VM voisines
qu’il protégeait sont désormais vulnérables.
Il est important de préciser que cette fonctionnalité seule ne doit pas être considérée comme une sécurité
suffisante, et ne permet en aucun cas de s’affranchir des méthodes traditionnelles de protection. Il faut
la considérer comme un niveau de protection supplémentaire s’appliquant sur un périmètre qui jusque-là
ne bénéficiait que de possibilités limitées en termes de contrôle des flux. Le Cloud UFTMiP utilise par
exemple le pare-feu distribué, le pare-feu des ESG pour chaque tenant ET des pare-feux périmétriques
communs à toute l’infrastructure.
L’utilisation efficace de ce module impose une gymnastique intellectuelle qui n’est pas naturelle pour
quiconque est habitué aux pares-feux traditionnels, la notion d’interfaces entrantes et sortantes distribuées
sur les VM NIC étant différente des situations habituelles.

3.3 Utilisation des objets vSphere

Le DFW, géré par le NSX Manager synchronisé avec le vCenter, a connaissance des conteneurs vSphere.
Ceci offre la possibilité d’écrire des règles de filtrage dont les objets source et/ou destination sont
inventoriés dans le vCenter.
Voici quelques règles imaginaires illustrant ce cas de figure :
1. La VM nommée « coriolis » peut initier des connexions vers la VM nommée « doppler » sur le
port 443.

JRES 2017 - Nantes 9/15

 2. Les VM connectées au switch logique « webservices » peuvent initier des connexions vers celles
du switch logique « databases » sur les services Oracle, MSSQL et PostgreSQL.
3. Les VM des hôtes « ESX-15 » et « ESX-22 » peuvent échanger des requêtes ICMP.
L’avantage d’une règle utilisant de tels objets est le suivant : en cas de modification par l’administrateur
système de l’adresse IP d’une VM, il n’est pas nécessaire de modifier les règles de filtrage la concernant.
Attention toutefois : dans le cas où une VM est supprimée puis restaurée avec son nom initial (lors de la
restauration d’une sauvegarde par exemple), son identifiant vCenter est modifié et la règle de filtrage
devient inopérante. La correction nécessite une intervention manuelle, et dans l’intervalle la VM concernée
se retrouve isolée du reste du réseau. On parle d’expérience…

3.4 Filtrage est-ouest et nord-sud

Nous avons vu que le pare-feu distribué apportait une protection appréciable sur les flux est-ouest. Quid de
sa relation avec l’Edge Service Gateway, qui effectue pour sa part le filtrage nord-sud ? Prenons un exemple
concret : l’écriture d’une règle autorisant une VM à effectuer librement des requêtes DNS vers Internet.
Elle aura par défaut la forme suivante :
̶ Source : VM « X »
̶ Destination : « Any »
̶ Service : « DNS-UDP »
̶ Action : « allow » (avec l’option « log »)
̶ Direction : out
̶ Appliquée à : Distributed Firewall
Publiée en l’état, elle autorisera les connexions sortantes sur le port 53. Ce flux sera toutefois bloqué par le
pare-feu de l’ESG en sortie du réseau virtualisé. Pour éviter de réécrire manuellement la même règle sur
l’interface de l’Edge, il est possible d’ajouter l’ESG dans le champ « Appliquée à ». Ainsi, le NSX Manager
va automatiquement propager les règles nécessaires sur les hôtes ET sur l’Edge spécifiée.

Figure 11 - Périmètre d’application des règles de filtrage est-ouest et nord-sud

JRES 2017 - Nantes 10/15

3.5 Sécurité contextuelle
L’utilisation combinée du pare-feu distribué et du NSX Manager permet d’implémenter une autre approche
de la sécurité, basée sur la notion de groupes de sécurité et de politiques de sécurité associées. Le terme
de sécurité contextuelle, qui n’apparaît pas dans le jargon VMware, semble adapté pour décrire la logique
mise en œuvre. Il est représenté dans l’interface vSphere sous le nom de Security Composer.

3.5.1 Security groups

Un groupe de sécurité NSX est un ensemble d’objets vSphere regroupés en une même entité. Il peut être
constitué de façon manuelle par l’administrateur (en ajoutant, par exemple, des VM spécifiques dans un
groupe nommé « serveurs web »), ou géré de façon dynamique par le NSX Manager.
Si la gestion manuelle existe déjà sur la plupart des pare-feux traditionnels, la gestion dynamique constitue
le véritable intérêt de la fonctionnalité. Elle est basée sur des conditions définies par l’administrateur et
s’appuie sur des attributs spécifiques des machines virtuelles. Prenons quelques exemples :
̶ Les VM dont le nom commence par « db-srv » sont membres du groupe « Serveurs de bases
de données »,
̶ Les VM dont le système d’exploitation contient « Windows 2012 » sont membres au groupe
« Serveurs Windows »,
̶ Les VM sur lesquelles on a positionné l’attribut de sécurité « critique » sont membres du
groupe « Serveurs critiques ».
Il est également possible de combiner plusieurs conditions :
̶ Les VMS associées à l’entité « switch_logique_production » ET dont le nom commence par
« web-srv » ET dont le système d’exploitation contient « linux » ET sur lesquelles est
positionné l’attribut « critique » sont membres du groupe « Serveurs web critiques Linux en
production ».

Figure 12 - Groupes de sécurité dans le Security Composer

Un groupe de sécurité peut contenir simultanément des objets dynamiques et des objets gérés
manuellement. Ce mélange des genres peut amener à une complexité excessive et causer des
comportements inattendus, mais il existe toutefois un cas de figure où il est intéressant : l’exclusion.
L’administrateur peut, par exemple, spécifier que les VM nommées « web-srv-temp18 » et « web-srv-
temp19 » ne seront pas intégrées automatiquement au groupe précédemment cité, même si elles satisfont à
toutes les conditions définies.

JRES 2017 - Nantes 11/15

Les conditions sont constamment vérifiées par le NSX Manager : si l’administrateur supprime l’attribut
« critique » sur une des VM membres du groupe cité en exemple, elle en sera automatiquement retirée au
bout de quelques secondes.
Il est possible d’intégrer l’authentification Active Directory dans les critères d’appartenance à un groupe.
Ainsi, un utilisateur connecté à une VM Windows pourra automatiquement obtenir pour cette machine des
autorisations de flux spécifiques à son statut.
Les groupes de sécurité ainsi créés peuvent être utilisés manuellement dans les règles du pare-feu distribué,
en tant que sources, destinations, ou encore pour limiter le périmètre d’application de certaines règles. Ils
montrent tout leur potentiel lorsque l’administrateur les associe à des politiques de sécurité.

3.5.2 Security policies

Une politique de sécurité est constituée par un ensemble de mécanismes (ou services) que l’administrateur
va assigner à un groupe de sécurité, et qui vont s’appliquer à toutes les machines virtuelles membres du
groupe en question.
Ces services se répartissent en trois catégories :
̶ Les services Endpoint, fournis par des éditeurs tiers (Antivirus par exemple),
̶ Les règles de filtrage du pare-feu distribué,
̶ Les services d’inspection réseau.
Nous nous focaliserons ici sur la partie filtrage.
Pour le Cloud privé de l’UFTMiP, nous avons créé des politiques correspondant aux différents templates
pouvant être provisionnés par un utilisateur. vRealize Automation positionne des attributs de sécurité sur
les VM ainsi déployées, qui sont automatiquement intégrées à des groupes de sécurité, sur lesquels sont
ensuite appliquées des politiques de sécurité autorisant certains flux réseau.
Par exemple, une VM « CentOS » acceptera automatiquement les connexions SSH entrantes. Si c’est un
template « CentOS + MySQL », une autre politique de sécurité autorisera les connexions TCP sur les ports
3306 et 5432, sans nécessiter l’intervention des administrateurs réseaux.
Les règles de filtrage générées par les politiques de sécurité sont visibles dans l’interface d’administration
du pare-feu distribué, dans une section dédiée.

3.5.3 Exemple d’utilisation avec des produits tiers

Associée à des produits tierce partie, la sécurité contextuelle permet d’automatiser des mécanismes de
protection évolués, comme le proposent certains pares-feux périmétriques haut de gamme.
Par exemple, une politique de sécurité « Scan antivirus » peut déclencher des analyses sur toutes les VM
membres d’un groupe « desktop Windows ». En cas de détection d’une menace, l’antivirus va positionner
un attribut de sécurité « VirusFound » sur la VM, ce qui la fera automatiquement changer de groupe de
sécurité pour intégrer un groupe « Quarantaine ».
Sur ce groupe « Quarantaine » sera appliqué une politique « nettoyage et quarantaine » qui déclenchera un
nettoyage de la VM tout en bloquant les connexions vers des adresses autres que celle du serveur Antivirus
centralisé.
Une fois le nettoyage effectué, le module antivirus va retirer l’attribut « VirusFound » et la VM rejoindra
automatiquement son groupe de sécurité initial : « desktop Windows », retrouvant par la même occasion sa
connectivité d’origine.
Les possibilités offertes par le Service Composer étant virtuellement illimitées, il convient d’effectuer un
consciencieux travail préparatoire avant de se lancer dans l’aventure, afin de définir le plus tôt possible les
comportements attendus et la stratégie à mettre en œuvre.

JRES 2017 - Nantes 12/15

4 Edge Service Gateway
L’Edge Service Gateway (ESG) est un composant essentiel de tout déploiement NSX. Elle permet, à
minima, d’effectuer la transition entre le réseau virtualisé et les réseaux physiques en liaison montante. En
fonction de l’architecture cible et des ressources disponibles, l’administrateur peut déployer plusieurs
instances d’ESG. Le modèle choisi pour le Cloud UFTMiP est appelé multi-tenancy, avec une ESG par
tenant.

Figure 13 - Architecture logique multi-tenants du Cloud UFTMiP

C’est la seule appliance de la plateforme NSX participant au data plane : il est important de considérer que
l’ensemble des flux qui la traversent sont gérés par les vCPU et les interfaces réseau de sa machine virtuelle.
Il existe quatre dimensionnements possibles qui doivent être choisis avec soin en fonction du trafic véhiculé
et des services que l’on souhaite implémenter.

4.1 Routage
L’ESG est avant tout un routeur. À ce titre, elle participe au plan de contrôle et gère l’adjacence avec les
routeurs voisins (généralement top of rack). Elle dispose de dix interfaces utilisables pour la liaison
montante et les liens vers le réseau interne, et permet d’implémenter du routage statique et dynamique
(eBGP, iBGP, et OSPF).

4.2 Haute-disponibilité
L’ESG peut être déployée selon deux modèles différents en fonction des besoins : en mode HA
(actif/passif), ou en mode ECMP (actif/actif) pour assurer la répartition de charge et augmenter la bande
passante.
En mode ECMP, jusqu’à 8 ESG peuvent être actives simultanément, mais la plupart des services stateful
sont indisponibles. Seuls le routage et le forwarding sont possibles en raison de la nature asymétrique des

JRES 2017 - Nantes 13/15

flux. Les architectures ECMP garantissent un temps de convergence quasiment immédiat en cas de
défaillance d’une appliance.
Le mode HA déploie deux appliances par instance d’ESG : une active et une passive. Les deux VM sont
constamment alimentées et échangent un heartbeat. Si l’ESG passive détecte une défaillance du heartbeat,
elle passe en mode actif et démarre l’ensemble de ses services configurés. Le temps de convergence varie
en fonction du type de routage et des timers utilisés.

4.3 Firewall
L’ESG embarque un firewall dédié aux flux nord-sud. À l’instar du pare-feu distribué, il est stateful et
administré via l’interface de gestion de l’Edge dans le client vSphere. Ce firewall et le pare-feu distribué
peuvent être utilisés indépendamment ou de façon conjointe. L’utilisation de plusieurs ESG dans le cadre
du Cloud privé permet de gérer la politique de filtrage de façon distincte pour chaque tenant, pour s’adapter
aux politiques de sécurité propres aux établissements membres.

4.4 VPN
L’ESG peut être utilisée comme terminaison VPN de niveau 2 et 3. L’utilisation de tunnels de niveau 3 est
possible en IPSec ou en SSL. Ces deux services sont distincts et indépendants.
Dans le cadre du projet UFTMiP, nous utilisons des tunnels IPSec pour interconnecter les réseaux de
campus des établissements membres avec leurs tenants correspondant sur le Cloud. Les administrateurs de
VM et les responsables du maintien en condition opérationnelle peuvent ainsi accéder de façon transparente
au périmètre réseau qui leur est affecté.
Le service VPN SSL est disponible pour les administrateurs en mobilité. Une interface web gérée par l’ESG
permet de télécharger un package d’installation client prêt à l’emploi, pour les plateformes Windows, OSX
et Linux.
Ces deux services VPN ont été utilisés avec succès par des endpoints utilisant le client libre Openvpn, ou
en association avec des firewalls Stormshield, Palo Alto et Fortinet.

5 Conclusion
L’expérience acquise sur NSX durant ces trois années de mise en œuvre et d’exploitation peut se résumer
de la façon suivante :

5.1 Avantages
̶ Facilité de déploiement et de dimensionnement de l’infrastructure réseau virtualisée
̶ Simplification des opérations de configuration sur les équipements physiques
̶ Optimisation des ressources
̶ Gestion centralisée grâce à l’intégration au client vSphere
̶ Automatisation via l’API REST ou l’interaction avec vRealize
̶ Micro-segmentation et sécurité contextuelle

5.2 Inconvénients
̶ Coût des licences
̶ Solution propriétaire
̶ Learning curve
̶ Exploitation des logs

JRES 2017 - Nantes 14/15

 ̶ Complexification des opérations de diagnostic
̶ Ergonomie de l’interface utilisateur vSphere (règles de filtrage)
̶ Manque de maturité de la solution (bugs, stabilité de certains services)

5.3 Si c’était à refaire ?

S’il fallait ne retenir que deux recommandations à l’attention des collègues intéressés par la plateforme, ce
seraient les suivantes :
Tout d’abord : formez-vous avant même de commencer à réfléchir à l’intégration de NSX à votre
architecture existante ou au déploiement d’une nouvelle infrastructure. La solution est complexe en termes
de technologies et de fonctionnalités, et il est nécessaire d’en avoir une excellente vision d’ensemble avant
de prendre la moindre décision.
VMware fournit des supports de documentation très détaillés sur NSX, qui seront indispensables lors de
des phases de design, d’installation et de configuration. L’équipe du Cloud s’est formée sur le tard, et nous
sommes ainsi passés à côté de certaines possibilités d’optimisation qui ont été compliquées à mettre en
œuvre une fois la plateforme en production.
Ensuite : expérimentez, maquettez. Tous les protocoles implémentés par NSX sont standards, et si votre
expérience préalable d’administrateur réseau vous suffira amplement à comprendre et appréhender les
mécanismes mis en œuvre, il en sera autrement pour la partie implémentation et configuration. L’utilisation
du client vSphere ou de l’API du NSX Manager ne sont pas « naturelles ». En outre, la relative jeunesse de
la plateforme confère à son interface d’administration quelques bugs et comportements originaux, qui sont
heureusement contournables… une fois qu’on en a fait l’expérience.
Le choix de NSX pour l’infrastructure du Cloud UFTMiP, il y a maintenant 3 ans, était sans aucun doute
un pari risqué. Nous avons parfois payé le prix de cette décision, en termes de bugs, de comportements
inattendus ou mal compris, et de problèmes de stabilité.
Il faut toutefois souligner les efforts considérables de VMware en matière d’accompagnement, de support
et de développement. Leur investissement dans ce produit semble démontrer une réelle ambition sur le long
terme, loin du simple effet de mode.
À mon sens, la plupart des inconvénients de NSX sont liés à son manque de maturité, et ses avantages
résident dans sa philosophie. Si elle ne constitue évidemment pas une solution idéale dans tous les
environnements, cette plateforme mérite d’être étudiée avec attention.
Quelles que soient les technologies implémentées en matière de système, de stockage ou de réseau, il
semble inconcevable que les datacenters Cloud de demain puissent se dispenser de virtualiser tout ou partie
de leurs infrastructures. Que chacun fasse son choix, en espérant surtout qu’à la fin il n’en restera pas
qu’un !

JRES 2017 - Nantes 15/15