Vous êtes sur la page 1sur 15

Le chainage de fonctions réseau, une opportunité pour les réseaux

de l'Enseignement/Recherche

Antoine DESPLAN
RENATER - Production des Services aux Utilisateurs
23-25 rue Daviel
75013 Paris

Alice THOREL
RENATER - Marketing
23-25 rue Daviel
75013 Paris

Résumé
Aujourd’hui, la recentralisation sur son corps de métier est l’une des raisons qui poussent
les entreprises à externaliser leur SI. Elles espèrent ainsi gagner en flexibilité et en
réactivité.
Le matériel physique pour l’implémentation de fonctions réseau est une contrainte. La
virtualisation et l’automatisation permettent de réduire le temps de provisionnement de
service réseau virtualisé (NFV). Cependant, certaines NFV (Pare-feu, …) nécessitent d’être
en coupure. Si l’on veut s’affranchir de la contrainte géographique et déployer le service
par exemple dans un cloud, on est donc obligé de rediriger le trafic. On peut aussi chainer
plusieurs fonctions réseau, c’est à dire réaliser un « service chaining ».
Le service chaining nécessite un grand nombre d’opérations. Pour faciliter le passage à
l’échelle, un mécanisme d’automatisation est nécessaire et le SDN répond à ces problèmes.
L’intérêt pour un opérateur est de proposer de nouveaux services à valeur ajoutée à ses
utilisateurs. Proposer ces services demandent cependant des adaptations, car la gestion
des NFV dans le cloud requiert des compétences qui ne sont pas natives dans le coeur de
métier d’un opérateur. L’opérateur fournit la fonction et son support ; la configuration est
du ressort de l’utilisateur qui reste ainsi maître de sa politique de routage et de sécurité.
Nous avons mis en place cette preuve de concept pendant six mois. Nous avons pu tester
une plate-forme basée sur la solution de Cloud Computing OpenStack et le mécanisme de
SDN de Juniper, CONTRAIL, une plateforme utilisant NSX pour fournir des NVF et enfin une
solution manuelle pour tester les NFV.

Mots-clefs
Network Functions Virtualization, Software-defined networking, Service Function Chaining, OpenStack, Cloud
Computing

1 Introduction
Le réseau RENATER pour la communauté de l’enseignement supérieur et de la recherche a beaucoup évolué
depuis sa création pour s’adapter à la transformation numérique des usages.
Aujourd’hui, les modèles SaaS et Iaas dans le Cloud permettant de simplifier la gestion du Système d’information.
Avec la virtualisation des fonctions réseau se posent la question d’un service des fonctions réseau délivrées par
RENATER à ses utilisateurs et ceci grâce à un Cloud interne. Ces services s’adresseraient principalement aux
petites structures et à titre d’exemple pourraient être un pare-feu, un routeur, un load-balancer, un serveur de VPN,
… L’intérêt de ces nouveaux services réseau virtuels est la rapidité de déploiement (pare-feu à la demande), la
souplesse, l’indépendance par rapport à la localisation du service, le passage à l’échelle (passage à l’échelle
horizontale), l’adaptation à la demande sur le service (augmentation ou diminution). Pour l’utilisateur, il n’a plus
à gérer l’environnement du matériel (salle machine, électricité), l’achat du matériel et sa maintenance en condition
opérationnelle.
Ce document expose les expérimentations que nous avons conduites ainsi que leurs résultats.

2 Principe du Service Chaining de NFV

2.1 Principe des NFVs


Le concept de Network Fonctions Virtualization (NFV) consiste à virtualiser les services et fonctions réseau
actuellement mis à disposition par un matériel dédié. L’utilisation des NFV permet donc de dissocier les fonctions
réseau d’un équipement dédié, elles sont fournies sous forme de machines virtuelles.

Figure 1 : Modèle Hardware et Virtuel

Une fois les fonctions réseau virtualisées (Pare-feu, Répartiteur de charge, etc …), les services qui nécessitaient
jusqu'alors un matériel dédié peuvent désormais être fournies à partir de serveurs x86 standard. Ce concept s’appuie
sur la volonté de rationaliser les ressources consommées par les infrastructures réseau en utilisant le modèle de
LEAN (faire plus avec moins de ressource).

2.2 Exemple de service : Pare Feu

Réseau privé Internet


(Client)

Figure 2 : Exemple de service FIREWALL

Un pare-feu est un système permettant de protéger réseau des intrusions et logiciels malveillants. Il permet de
filtrer les paquets de données échangés avec le réseau. La virtualisation d’un pare-feu apporte les avantages
suivants :
 Une machine virtuelle est rapide à mettre en place et peut ainsi offrir un pare-feu à la demande
 Rapide à administrer, redémarrer, reconfigurer
 Pas de gestion du support physique, donc évolutivité avec moins de contrainte
 Reprise sur incident facilité car la NFV est exécutable sur un hyperviseur X ou Y

En utilisant un orchestrateur de machine virtuelle et en plaçant nos machines dans le cloud, nous résolvons les
deux premiers cas, en effet nous pouvons mettre à jour et définir la taille des instances de façon très simple.

2.3 Localisation et association des NFVs (Service Function Chaining) au SDN

Figure 3 : Détournement du trafic par SFC

Dans le contexte de NFV, certains services doivent être déployés en « coupure » (par exemple un pare-feu,
accélérateur WAN, …). Cette contrainte peut impliquer une localisation de la fonction réseau virtuelle ou non
(typiquement le pare-feu en entrée de site). Cette contrainte est pénalisante en termes de coût, de temps de
déploiement et de maintenance. Si la fonction réseau est virtualisée, il est beaucoup plus facile de l’implémenter
là où elle est optimale. Il faut donc que le réseau puisse rediriger le trafic à destination de l’utilisateur vers la
fonction réseau en coupure et après le passage dans la fonction réseau renvoyer le trafic vers l’utilisateur et cela
dans les deux sens de la communication.
De plus, il existe une demande pour pouvoir disposer de plusieurs services réseau successifs (par exemple, un
utilisateur peut avoir besoin d’un pare-feu et d’un load-balancer). Il est donc nécessaire de s’affranchir de la
localisation de ces services et donc au niveau réseau de pouvoir rediriger le flux réseau à travers ces services. La
technologie employée pour permettre d’utiliser plusieurs services successifs « en coupure » est le « Service
Fonction Chaining ».
Les NFV ont un besoin en connectivité entre chaque serveur et vers internet, pour fournir cette connectivité et
d’être isolé par utilisateur (Tenant). On utilise des mécanismes d’encapsulation comme les VPN MPLS, VXLAN,
etc. en conjonction ou pas avec des mécanismes de forwarding basé sur des filtres (Policy-Based Routing, Filter-
Based Forwarding). Ces mécanismes permettent de séparer dans un réseau privé virtuel propre à chaque utilisateur
et de construire de façon transparente une infrastructure virtualisée.
On crée ainsi un réseau « Overlay » qui s’appuie sur un réseau « Underlay », (réseau physique déjà existant). Ces
réseaux overlay peuvent être présents dans le cloud NFV et aussi sur le WAN si les machines de l’utilisateur ne
sont pas hébergées dans ce cloud.

2.4 Implémentation Centralisé ou Décentralisé


Dans le cas de RENATER, il existe deux types d’implémentation, Le modèle centralisé, et le modèle décentralisé.
Figure 4 : Type D'implémentation

Dans le cas du modèle centralisé, les NFV sont exécutées dans un « Datacenter », au cœur du réseau de l’opérateur,
cela permet un meilleur taux de consolidations et de mutualiser les investissements de l’opérateur pour ces propres
infrastructures. Les problèmes de déploiement sur site de matériel sont aussi évités.
Dans le modèle décentralisé, les NFV sont exécutées dans les nœuds réseaux de l’opérateur ou dans les locaux de
l’utilisateur, cela pour rapprocher l’utilisateur et sa NFV. Certaine NFV n’ont de sens si elles sont près du site
client par exemple un accélérateur WAN, la politique de sécurité peut obliger à ce qu’un pare-feu soit hébergé
dans le site.
Dans un PoP, il faut avoir la place d’installer des serveurs physiques pour héberger ces NFV. Ce mode de
fonctionnement permettrait aussi de créer des CPE virtuels dans les NR RENATER, il ne resterait plus qu’un
switch chez l’utilisateur. Le désavantage est d’avoir à gérer le déploiement de VM sur plusieurs sites (dans les
PoP)
Les NFV peuvent aussi être embarquées dans un serveur positionné chez le client et qui joue le rôle de VCPE
(virtual CPE) comme une sorte de « BOX ». Ce CPE peut héberger plusieurs NVF en fonction des choix de
l’utilisateur. Dans ce dernier cas, le plus grand désavantage est de gérer les contraintes logistiques pour le
déploiement.

2.5 Cas d’usage pour l’utilisateur


Il y a de nombreux avantages pour l’utilisateur mais le principal est celui de pouvoir avoir sa fonction réseau mise
à disposition rapidement comme une VM. Pour l’utilisateur, un portail self-service (voir figure 5) pour la
commande de NFV serait mis à disposition de l’utilisateur. L’administration de la NFV (par un pare-feu par
exemple) serait ensuite réalisée soit par une interface web dédiée à la NFV ou via la ligne de commande. Les
utilisateurs choisissent dans un panel de NFV sélectionnées par le fournisseur.
L’achat, l’installation, le maintien en condition opérationnelle est une tâche lourde pour des utilisateurs qui veulent
concentrer leur effort sur leur cœur de métier. Notez bien que dans le contexte des NFV, l’utilisateur reste maitre
de gérer sa NFV comme il le souhaite, il est simplement soulagé des aspects installation, maintien en condition
opérationnelle et gestion de l’environnement. L’utilisateur reste ainsi maitre de sa politique de sécurité ou de
routage. L’achat est aussi simplifié car la NFV peut être choisie au sein d’un catalogue de NFV testés par le
fournisseur.
Figure 5 : Portail Self-Service

2.6 Cas d’usage pour RENATER


Dans l’absolu, le fournisseur de fonctions réseau pourrait délivrer ces services avec du matériel. C’est une option
qui peut être intéressante quand les performances matérielles sont requises mais l’usage de matériel pour toutes
les fonctions réseau serait couteux et chronophage pour les équipes opérationnelles. Le recours au matériel est
limité au cas de performance non disponible en virtuelle ou lorsque la fonction est non disponible en virtuelle.
Du point de vu de l’opérateur le déploiement en centralisé offre de nombreux avantages :

 Pas de logistique pour déployer un serveur sur le site client (opération à répéter pour chaque client) ou
dans un PoP (opération à répéter pour chaque PoP).
 L’architecture centralisée présente l’avantages propres aux Infrastructures Cloud, c’est-à-dire de
supprimer un grand nombre de points individuels de défaillance. Cependant, il reste toujours un point
de défaillance possible, la rupture de fibre ou du matériel reliant RENATER à son client.
Il y a aussi un point à prendre en considération, c’est le changement du trafic réseau dans la Backbone de
l’opérateur, ce dernier passant désormais par le site central qui héberge les NFV.

3 Démarche marketing : détection d’une opportunité stratégique et


création d’un service
Tout développement technique s’inscrit dans une démarche de réflexion stratégique par le moyen d’une
étude d’opportunité stratégique réalisée par le service marketing de RENATER. L’objectif de cette réflexion est
de se poser les questions de pertinence et de faisabilité en amont d’un développement technique plus poussé : cette
tendance est-elle assez significative pour notre communauté afin de justifier un investissement technique
important ?
Une étude d’opportunité se compose d’une phase de compréhension des besoins, suivie d’une phase d’analyse
du marché permettant de définir le potentiel d’un futur service et d’en cadrer le positionnement.
Une enquête utilisateurs a été réalisée auprès de de la communauté (échantillon de 100 établissements
membres RENATER de tailles et de natures différentes) pour comprendre et cadrer le besoin afin de répondre avec
la solution la plus appropriée.
Un grand intérêt pour une solution de virtualisation des fonctions réseau se manifeste (90% des répondants sont
intéressés par le service proposé). Les principales raisons évoquées pour souscrire à ce service sont l’aspect
innovant (pour 77% des sondés) et l’économie financière réalisée (50%). En parallèle, des freins liés à
l’externalisation du support des fonctions réseau (44%) et une demande forte d’engagements de service de la part
de RENATER (87%) s’expriment.
La réalisation de cette enquête auprès de potentiels utilisateurs a permis de démontrer que le service attire
car il est considéré comme innovant et pratique, cependant il semble nécessaire de l’associer à une stratégie de
service qui rassure et qui adresse chacun des freins relevés.
De plus, une lecture intelligente du contexte et une analyse sectorielle des tendances du marché des fonctions
réseau ont permis de quantifier l’offre et d’identifier les acteurs structurants du marché.
Le contexte actuel de redéfinition des architectures réseau pousse RENATER à s’interroger sur la manière la plus
innovante et utile de proposer une solution à la rupture technologique qui s’opère dans les établissements : matériel
vieillissant, moyens limités, personnel moins spécialisé, etc.
Notre contexte fait écho à celui des entreprises dont l’ambition est de réduire leurs coûts techniques et de se
recentrer sur leur cœur de métier. Un marché des infrastructures réseau virtualisées profite de cette tendance et se
construit autour des grands leaders comme Cisco ou Juniper qui fournissent des solutions de virtualisation des
fonctions réseau clé en main pour les entreprises.
Cette analyse du contexte dans lequel s’inscrivent les NFV permet de cerner l’offre afin de proposer une solution
au plus près des codes performants du marché.
Passer par des étapes de compréhension des attentes des établissements et des contraintes du marché
permet, avec un développement technique adéquat, d’offrir une solution appropriée aux besoins spécifiques de
notre communauté et bénéficiant de tous les avantages du réseau RENATER

4 Preuve de concept par RENATER

4.1 Principe
SFC classique : Dans un SFC classique, côté opérateur on utilise des mécanismes de type VRF et BGP.
Pour détourner le trafic vers un routeur d’entrée, le protocole BGP est utilisé pour annoncer une route vers le préfix
de destination, et, plusieurs VRF nous permettent d’éviter le phénomène de boucle qui pourrait apparaitre lors de
la sortie de l’espace « SFC ». La NFV utilise le protocol BGP deux fois, en « entrée » et en « sortie » avec son
routeur. Le premier peering permet recevoir le paquet depuis l’extérieur dans une VRF « Internet » et le second
peering permet d’envoyer le paquet vers la machine de l’utilisateur ou vers une autre NVF mais dans une VRF
Cliente Le routeur de la NVF peut ainsi donc re-diriger indéfiniment le paquet en fonction du contexte en sortie
en entrée mais cela coûte à chaque fois une VRF et un sous-réseau. Cette méthode est moins performante que la
seconde.

Figure 6 : Modèle classique avec deux NFV

SFC par forwarding basé sur du filtrage (PBR / FBF): L’idée est désormais d’utiliser uniquement 2 sous-
réseaux virtuel pour faire le chainage et chaque sous-réseau « est lié » à plusieurs VRF. S’il y 3 services et un
client Red, on obtient : Red:Red (chez le client), Internet:Service1, Red:Service2 ,Internet:Service2, Red:Service3,
Internet:Internet (dans la table de routage global [GRT]). Le principe est que le paquet va passer d’une VRF à la
NFV puis à la VRF suivante avant d’être envoyé à la NFV suivante.
1. La route par défaut chez le client pointe sur la NFV1, Un paquet venant de chez le client est amené au
virtual routeur via MPLS. Le virtual routeur utilise le label pour identifier que le paquet doit être transmis
à la NFV1.
2. La NVF1 fait transiter le paquet et envoie le paquet sur son interface de sortie qui est connecté au virtual
routeur dans la VRF Internet:Internet.
3. A cette étape le PBR/FBF intervient. Une règle est programmée sur le virtual routeur (c’est le SDN).
Cette règle stipule que si la source du paquet est l’interface de sortie de la NFV1 alors on utilise les
routes de la VRF Internet:Internet (cas où la NFV1 communique avec l’extérieur pour ses propres
besoin) sinon le paquet doit utiliser les routes de la VRF Internet:Service1 (cas où le paquet vient du
réseau du client Red.
4. Dans la VRF Internet:Service1, la route par défaut pointe le virtual routeur derrière lequel la NFV2 est
hébergée. Un label est ajouté puis retiré sur le virtual routeur où est implémentée laNFV2. Le virtual
routeur dirige le paquet vers la NFV2 grâce au label de service (label de VRF)
5. Et ainsi de suite

Figure 7: Modèle par forwarding avec deux NFV

SFC par forwarding basé sur le header : Un groupe de travail a été constitué sur le sujet SFC au niveau de
l’IETF. Ce groupe travaillait sur deux draft qui sont devenus deux RFC, 7665 et 7498. L’idée est ici d’encapsuler
le paquet dans un header de « service » pour le rediriger les paquets vers les fonctions réseau. A l’époque de notre
de nos investigations ces travaux étaient dans un états préliminaires, nous ne les avons pas pris en compte.

4.2 Principe utilisé par Contrail


Contrail utilise les SFC par forwarding basé sur du filtrage. Ce type de SFC est annoncé comme plus performant.
Le schéma ci-dessous utilise Contrail, Contrail utilise des optimisations réseaux pour l’utilisation avec OpenStack,
La figure 8 représente l’architecture physique et la figure 9 l’architecture logique,
Le trafic à destination de l’utilisateur Rouge est annoncé dans le Backbone de l’opérateur comme devant aller vers
le cloud NFV. Le routage est assuré dans le cloud NFV par des Virtual Routers (VR) et par la Gateway (routeur
hardware). Le VR routeurs sont déployés sur les « compute » (les serveurs) gérés par OpenStack. A l’intérieur du
cloud NFV, le trafic est envoyé vers une première VRF « Internet » qui rassemble les routes des utilisateurs qui
utilisent une NFV, les paquets sont ensuite envoyés vers la première NFV qui les redirige vers la VRF rouge.
Comme expliqué dans la section précédente, Contrail utilise du « policy Based Routing » pour rediriger le trafic
vers une potentielle seconde NFV. A la dernière NFV, le trafic est envoyé dans la VRF rouge, il ressort sur VR
qui le pousse vers la gateway du cloud.
La gateway du cloud partage la VRF Rouge avec le backbone RENATER grâce à option B (RFC 3107), ce qui
permet d’acheminer le trafic directement entre la NFV et le site de l’utilisateur.
Figure 8 : Architecture Principe de SFC

Dans la « Cloud Gateway », Contrail opère un route leaking entre les VRF « Internet » et « RED », cela permet
de propager les routes clients et la route par défaut entre celle ci

Figure 9 : Echange des routes dans le service chaining

4.3 Service Chaining par Contrail


Le Service Chaining implémentable grâce
à Openstack et Contrail utilise des notions
connues par les opérateurs (BGP + MPLS) pour
créer un service chaining.
Dans cette solution, Contrail utilise des Routeurs
Virtuelles (VR) en association avec un routeur
physique (MX, etc) pour permettre la connectivité
des NFV au réseau RENATER.

Figure 10 : Architecture Openstack Déployé

4.3.1 La gestion du réseau par Neutron et Contrail

Openstack Contrail

Compute

Figure 11: Interaction Contrail - OpenStack

Contrail s’intègre à l’aide d’un plugin neutron et d’un agent vRouter pour dialoguer avec les composant
d’OpenStack. S’il est possible d’utiliser l’interface Horizon pour des tâches réseau simples, ces possibilités
limitées nous ont poussé à utiliser celle de Contrail pour des tâches plus évoluées, comme le service chaining, la
machine virtuelle créée est reliée à un vRouteur qui a des fonctions analogues à la solution OpenVswitch,

Figure 12 : interface de management de Contrail


La solution Contrail est capable de communiquer avec les routeurs de l’opérateur (via BGP), pour
détourner le trafic, et est capable de déployer de façon transparente des VRF, cela permet de créer des chaines
composées de plusieurs NFV de façon automatique.

Figure 13 : Architecture Fabric Contrail

Au déploiement, Contrail prend connaissance des éléments « vRouter » et « Gateway Router » du cloud,
Lors de la création d’une machine, Contrail déploie un réseau overlay (MPLS over GRE dans notre POC) et gère
l’adresse IP du serveur.

4.3.2 Réalisation du service chaining

Figure 14 : Définition d'un service Chaining

Figure 15 : Représentation Service Chaining Contrail

Voici ci-dessous le chemin emprunté par le paquet qui passe dans un firewall dans notre « cloud ». (Symbolisé par
les trois points rouges sur le Traceroute, vSRX Juniper)
traceroute to 194.57.8.100 (194.57.8.100), 30 hops max, 60 byte packets
1 daviel-swi.renater.fr (193.49.XXX.YYY) 1.240 ms 1.170 ms 4.964 ms
2 paris1-swi.renater.fr (193.49.XXX.YYY) 1.480 ms 1.696 ms 1.851 ms
3 paris1-rtr.renater.fr (193.49.XXX.YYY) 1.061 ms 1.070 ms 1.827 ms
4 paris1-rtr-021.noc.renater.fr (193.51.XXX.YYY) 1.231 ms 1 .374ms 1.480 ms
5 193.51.189.ZZZ (193.51.189.ZZZ) 1.400 ms 1.395 ms 1.395 ms
6 10.17.71.2 (10.17.71.2) 1.561 ms 1.616 ms 1.619 ms
7 * * *
8 194.57.8.5 (194.57.8.5) 4.497 ms 4.525 ms 4.522 ms
9 194.57.8.17 (194.57.8.17) 4.517 ms 3.651 ms 3.643 ms
10 10.20.12.2 (10.20.12.2) 3.931 ms 3.930 ms 3.187 ms
11 194.57.8.100 (194.57.8.100) 4.039 ms 2.495 ms 2.958 ms

Ce traceroute correspond au trajet entre les étapes suivantes :


Infrastructure réseau Renater
Routeur Infrastructure service Chaining (MX-104-1)
Infrastructure service Chaining
Client

---(refreshed at 2016-08-24 08 :01 :40 UTC) ---


Session ID: 12567, Policy name: default-permit/6, Timeout: 1798, Valid
IN: 193.200.242.194/54505 --> 194.57.8.100/23; tcp, Conn Tag: 0x0, If:
ge-0/0/1.0, Pkts: 14, Bytes: 751,
Out: 194.57.8.100/23 --> 193.200.242.194/54505; tcp, Conn Tag: 0x0, If:
ge-0/0/1.0, Pkts: 12, Bytes 669,
Total Sessions: 1

Nous ne sommes pas parvenus à inclure la NFV dans notre stratégie de routage (peering entre la NVF [un
pare-feu] et le Virtual Router). Il est donc nécessaire de configurer manuellement le routage de la NFV, (Route
par défaut et ajout des préfixes de l’utilisateur). Ce point est handicapant mais pour ne pas bloquer nos
investigations, nous ne sommes pas arrêtés sur ce point et donc nous ne sommes pas en mesure de dire que cela
est une limitation du produit.
Openstack et Contrail remplissent notre cahier des charges. Nous avons continué notre étude de faisabilité
et nous nous sommes aperçus que le système de licence ne permet pas de démarrer avec un petit investissement,
il faut tout de suite avoir un grand nombre de serveurs pour que la solution économique est un sens. L’un des
avantages de Contrail comme d’autre solution comme Nuage est de pouvoir facilement chainer les services mais
nous nous sommes dit qu’un seul produit pourrait déjà fournir plusieurs fonctions réseau et donc ne pas nécessiter
le chainage de NFV, par exemple, un pare-feu peut faire routeur avec des fonctions de NAT.

4.4 Principe utilisé par VMware


VMware ne fournit aucun système pour chainer les fonctions réseau, il faut donc appliquer le SFC classique. En
fait, VMware ne fournit qu’une VM (l’Edge router) qui est capable de porter plusieurs fonctions réseau : le routage,
le firewall, le load-balancer, NAT, serveur de VPN. L’Edge router est capable de faire du BGP avec les 2 VRF,
celle qui permet d’accéder à l’Internet et celle qui permet d’accéder au réseau du client. Enfin, VMware aussi
fournit tout l’environnement pour gérer cette VM c.à.d. l’Edge router.

4.5 Service Chaining par NSX

4.5.1 Architecture de test


Nous avons étudié les possibilités d’utiliser VMWare en association avec NSX pour créer un service
Chaining. NSX permet l’utilisation des NFV au sein d’une infrastructure virtualisé centralisé ou décentralisé. NSX
ne fournit rien pour implanter du service chaining, il faut donc utiliser la chainage « classique ».
Figure 16 : Service chaining avec une NFV

Nous avons réalisé deux tests, l’un se rapprochant de l’architecture mis en place par Contrail (centralisée),
et l’autre en utilisant ROBO (Remote Office Branch Office) de VMware

Figure 17 : Architecture classique


Figure 18 : Architecture ROBO

l’ESG (Edge Service Gateway) est une


machine virtuelle qui est capable de porter plusieurs
NFV : le firewall, le load-balancer, NAT ou le
routage, en l’association avec la configuration des
routeurs « manuelle ». Nous sommes parvenus à
rendre automatique la gestion des préfixes des routes
à l’intérieur de la NFV. Comme l’ESG ne sait pas
utiliser de VRF, il nous faut cependant utiliser
plusieurs VLAN en « interne » et le mécanisme de
VRF en externe.
VRF 1 VRF 2 VRF 3
Figure 19 : Utilisation de l'ESG
4.5.2 Déploiement
Pour déployer NSX, nous installons le NSX manager pour déployer les 3 Controller, ensuite nous créons sur un
ESXi distant (ROBO) deux machines virtuelles « ESG » qui sont des « boites à outils ».

Les clusters vSphere-Datacenter et


vSphere-Robo sont séparés par un réseaux MPLS
comme celui du Backbone RENATER. Cela simule
que le cluster « Robo » est installé sur un « PE
Renater »

Figure 20 : Déploiement VMWARE - NSX


4.5.3 Configuration du Routage de l’ESG et du service chaining

Figure 21 : Configuration du routage de l'ESG en BGP

Le routage dans la machine virtuelle étant dynamique, nous n’avons pas besoin de configurer le routage interne de
l’ESG (Route par défaut ou de l’utilisateur), il faut cependant créer les règles de Pare-Feu manuellement
Traceroute vers un utilisateur utilisant un ESG (mode vCPE)

Détermination de l’itinéraire vers 194.57.8.124 avec un maximum de 30


sauts.
1 1 ms 1 ms 9 ms daviel-swi.renater.fr [193.49.XXX.YYY]
2 2 ms 1 ms 1 ms paris1-swi.renater.fr [194.57.XXX.YYY]
3 2 ms 1 ms <1 ms paris1-rtr.renater.fr [194.57.XXX.YYY]
4 1 ms 1 ms 1 ms paris1-rtr-021.noc.renater.fr [193.51.XXX.YYY]
5 1 ms 1 ms 1 ms 193.51.189.ZZZ
6 1 ms 1 ms 1 ms 10.100.12.2
7 1 ms <1 ms 1 ms 194.57.8.138 ESG agissant comme un vCPE
8 2 ms 1 ms 2 ms 194.57.8.124
Itinéraire déterminé.

Ce traceroute correspond au trajet entre les étapes suivantes :


Infrastructure réseau Renater
Routeur Infrastructure service Chaining (MX-104-1)
Infrastructure service Chaining
Client

4.6 Service Chaining sans aucun outil


Nous avons réalisé un système de service chaining dans lequel nous avons :
 Implémenté le service chaining de façon classique (comme pour VMware)
 Implémenté une seule NFV. La NFV était un vMX (un MX virtuel de chez Juniper)
Les mêmes résultats que pour l’Edge router ont été constatés. Le désavantages est que l’on ne bénéficie pas d’un
orchestrateur de VM. Le chainage doit être géré par l’opérateur. Le coût n’est pas le même, non plus.
Ce type de service chaining n’étant pas automatique, il est très vite difficile de créer et gérer un service chaining
composé de plusieurs NFV. Le nombre d’opérations étant assez élevé, il n’est donc pas adapté pour une utilisation
en production,
4.7 Récapitulatif des solutions

Rapidité Type de NFV Automatisation du Automatisation du Chainage


disponible Réseau (VRF) routage (interne à la
de NFV
VM)

OpenStack + + + - +
+ Contrail

VMware + + + - + 0
NSX

SFC sans 0 + Possible mais à + Possible mais


aucun développer complexe
outil

Les Solutions NSX/VMWARE ou Contrail/OpenStack sont capables de rendre le service de NFVaaS, cependant
leur philosophie et l’utilisation ne sont pas les mêmes.
Contrail est orienté vers des processus opérateurs, il est plus à même de s’intégrer avec le backbone d’un opérateur,
Contrail peut réaliser des opérations réseaux poussés notamment le chainage de NFV. Le service de licence est un
frein à l’adoption de ce produit car il réclame un investissement considérable dès le départ.
VMware NSX est orienté vers des processus Cloud, il est plus à même de s’intégrer dans une infrastructure de
type IaaS. Il rend des fonctions poussées et est sans doute plus facile à prendre en main pour des équipes
familiarisées avec VMware. Il est aussi possible de l’utiliser avec des protocoles réseaux « simples » comme OSPF
et BGP. La gestion décentralisée est plus simple car VMware prévoit avec son produit ROBO l’administration à
distance d’un hyperviseur et donc d’un ESG.

5 Perspectives
A l’issue de ces POC, qui se sont montrés concluant quant à l’implémentation du Service Fonction Chaining, nous
pensons que les NFV sont suffisamment matures pour faire une étude plus poussée,
Désormais, l’objectif est de confirmer les résultats de POC tout en mettant en place un modèle technique et
financier. Une phase de test en interne va être effectuée (utilisateur au GIP), ainsi nous pourrons mesurer la fiabilité
du service rendu par la « technologie NFV » au quotidien, tout en travaillant sur les outils exploitation (monitoring,
reporting, alerte, portail utilisateur)
Ces étapes seront déterminantes pour enclencher une phase « Service pilote », un modèle marketing sera établi en
parallèle. Cette phase permettra de relever les ajustements à apporter à la technologie afin de créer une véritable
offre, tant au niveau du service, qu’au niveau de l’industrialisation technique (mutualisation du matériel dans les
nœuds régionaux RENATER, automatisation des nouvelles demandes, création d’un portail d’administration, etc.).
Le service NFV par RENATER permettra de rendre accessible aux établissements de la communauté
Enseignement-Recherche une technologie de rupture innovante.

Vous aimerez peut-être aussi