Memoire ENSP - OTTOU - Corrige1

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I
********** **********
ECOLE NATIONALE SUPERIEURE NATIONAL ADVANCED SCHOOL OF
POLYTECHNIQUE DE YAOUNDE ENGINEERING OF YAOUNDE
********** **********
DEPARTEMENT DES GENIES ELECTRIQUE DEPARTMENT OF ELECTRICAL AND
ET DES TELECOMMUNICATIONS TELECOMMUNICATIONS ENGINEERING
CONCEPTION ET DÉPLOIEMENT D’UNE

SOLUTION SD-WAN : APPLICATION A
LA GESTION DES RÉSEAUX DE
L'ENTREPRISE CAMTEL
Mémoire de Fin d’études

Présenté et soutenu par :
OTTOU NGBWA ABED LANDRY
En vue de l’obtention du
DIPLOME D’INGENIEUR DE CONCEPTION DE GENIE DES
TELECOMMUNICATIONS
Sous la supervision académique du :

Pr TONYE Emmanuel
Et professionnelle de :
M. MEBANDE ARMEL DADY, Ingénieur (Chef de Département de Sécurité
des Systèmes d’Information et de la Communication)
Devant le jury composé de :
 Président : NDZANA Benoît, Maître de Conférences E.N.S.P.Y

 Rapporteur : TONYE Emmanuel, Professeur Émérite E.N.S.P.Y
 Examinateur : BOUETOU BOUETOU Thomas, Professeur E.N.S.P.Y
 Invité : MEBANDE ARMEL, Ingénieur CAMTEL
Année Académique : 2019-2020

Date de soutenance : 15 Juillet 2020
DEDICACE
DÉDICACE
A mes parents.
Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Option Génie Télécommunication à l’ENSPY, Juillet 2020 1
Par OTTOU NGBWA ABED LANDRY
REMERCIEMENTS
REMERCIEMENTS
Mes pensées vont tout d’abord :
- Au Professeur NDZANA Benoît, enseignant à l’ENSPY, pour le grand honneur qu’il
nous fait de présider ce jury ;
- Au Professeur Emmanuel TONYE, mon encadreur académique pour la passion de
l’enseignement et la disponibilité permanente pour l’avancement de ce travail ;
- Au Professeur BOUETOU BOUETOU Thomas, enseignant à L’ENSPY, pour
avoir accepté d’examiner ce travail.
J’adresse mes profonds remerciements à la société « Cameroun Télécommunications » qui

m’a accueilli pour mon stage de fin d’études. Mes remerciements vont particulièrement :
- A L’Ingénieur MEBANDE Armel Dady, Chef de Département de Sécurité des
Systèmes d’Information et de la Communication chez CAMTEL, mon encadreur
professionnel, Expert Cisco pour ses apports technologique et psychologique sur ce
travail.
- A toute l’équipe du Service de Gestion et Administration de l’Intranet et Extranet pour
l’apport professionnel notamment l’Ingénieur EYONG Sylvester Chef dudit service.
Je tiens aussi à témoigner ma reconnaissance à :

- Tous les enseignants de l’ENSPY pour la formation reçue auprès d’eux particulièrement
Dr. Ingénieur Éric DEUSSOM ;
- A M. OTTOU Francis, Ingénieur, pour l’attention apportée à ce travail en tant que
conseiller professionnel, et pour le soutien apporté en tant que mon père ;
- Mes chers parents Mme OTTOU Mireille et Mme MVOUA Nathalie pour toutes les
formes de soutien au long de mon parcours académique ;
- Mes tantes, oncles, cousines et cousins pour tout le soutien familial.
- Mes camarades de l’ENSPY, particulièrement tous mes camarades de promotion du
département des Génies Electrique et Télécommunications.
- A l’entreprise multinationale « Cisco Systems » pour les sessions de formations en
ligne, la documentation, les certifications et le transfert de technologie.
Enfin A tous ceux qui de près ou de loin ont contribué à la réalisation de ce projet, je vous dis
grandement MERCI.

GLOSSAIRE
GLOSSAIRE
A I
AES: Advanced Encryption Sandard IaaS: Infracstructure As A Service

AFI: Address Family Interface IETF: Internet Engineering Task Force
AH: Authentication Header IKE: Internet Key Exchange
API: Application Programming Interface IP: Internet Protocol
AS: Autonomous System IPsec: Internet Procol Security
ASN: Autonomous System Number ISDN: Réseau numérique à intégration de
ATM: Asynchronous Transfer Mode services
AWS: Amazon Web Services IS-IS: Intermediate System to Intermediate
System
B
L
BGP: Border Gateway Protocol
BoS: Bottom of Stack LAN: Local Area Network
LDP: Labed Distribution Protocol
C LER: Label Edge Router
LIFO: Last In First Out
CA: Certificate Authority
LSP: Lanel Switched Path
CAMTEL: Cameroon Telecommunications
LSR: Labed Switching Router
CBC: Cipher Block Chaining
LTE: Long Term Evolution
CE: Customer Edge
CLI: Command Line Interface M
D MPLS-VPN: Multi-Protocol Label Switching -

VPN
DES: Data Encryption Standard
MRNLRI: Multiprotocol Reachable Network
DHCP: Dynamic Host Control Protocol
Layer Reachability Information
DSL: Dedicated Subscriber Line
MSP: Managed Service Provider
DTLS: Datagram Transport Layer Security
MUNLRI: Multiprotocol Unreachable
DWDM: Dense Wavelength Division
Network Layer Reachability Information
Multiplexing
N
E
NETCONF: Network Configuration
EIGRP: Exterio Interior Gateway Protocol
NMS: Network Management System
ESP: Encapsulating Security Payload
EVE-NG: Emulated Virutal Environment New O
Generation
OMP: Overlay Management Protocol
F ONF: Open Networking Foundation
OSPF: Open Switched Path First
FAI: Fournisseur d'Acces Internet
OTP: One-Time Password
FEC: Forward Equivalent Class
OVF: Open Virtual Machine Format
H
HMAC: Keyed-Hash message Authentication

GLOSSAIRE
P SSL: Secure Sockets Layer
STUN: Simple Traversal of User Datagram
P: Provider ou Routeur du Cœur MPLS
Protocol
PaaS: Platform As A Service
PE: Provider Edge
T
PnP: Plug and Play
TCP: Transfer Control Protocol
Q TLOC: Transport Locator
TLS: Transport Layer Security
QoS: Quality Of Service
TTL: Time To Live
R
U
RD: Route Distinguisher
UDP: User Datagram Protocol
RFC: Request For Comments
RIR: Registres Internet Régionaux
V
RSVP: Resouce Reservation Protocol
RT: Route Target vEdge Cloud: Modele appareil WAN Edge
VM: Virtual Machine
S VOIP: Voice Over IP
VPC: Virtual Personal Computer
SaaS: Software As A Service
VPLS: Virtual Protocol Label Switching
SCP: Secure Copy Protocol
VPN: Virtual Private Network
SDH: Synchronous Digital Hierarchy
VRF: Virtual Routing ans Forwarding
SDN: Softwae Defined Networking
VSAT: Very Small Aperture Terminal
SD-WAN: Software Defined Wide Area
Networking
W
SFTP: SSH File Transfer Protocol
SHA: Secure Hash Algorithm WAN: Wide Area Network
SLA: Service Level Agreement WAN Edge: Routeur de Bord WAN
SN: Sequence Number
SONET: Synchronous Optical Network Z
SPI: Security Parameters Index ZTP: Zero Touch Provisioning
SSH: Secure SHell

RESUME / ABSTRACT
RÉSUMÉ/ABSTRACT
RÉSUMÉ
Dans le but de rester compétitif suite à la nécessité constante d’utilisation du réseau et avec la
croissance du nombre de site de son réseau d’entreprise, CAMTEL a migré vers une
architecture réseau orientée Logicielle (SD-WAN) constituée de 3 plans dont la donnée, le
contrôle et le management. L’administration de façon manuelle du réseau d’entreprise constitué
de nombreux routeurs interconnectés entre eux par un nuage MPLS, telle que connue à ce jour,
s’avère être fastidieuse et sujette à de nombreuses erreurs. Le suivi de l’interconnexion, la
disponibilité des services et la QoS étant capitaux pour le fonctionnement de l’entreprise, il
serait essentiel de pouvoir automatiser les déploiements et centraliser cette gestion de manière
à permettre aux responsables du réseau d’entreprise de se concentrer sur les aspects d’accès aux
services et gestion du trafic. Les principes technologiques du SD-WAN de Cisco sont analysés
et intégrés dans l’architecture du réseau d’entreprise afin de répondre aux différentes
problématiques qui vont se présenter dans le cadre du fonctionnement existant, le tout en
relevant un certain nombre de challenges sur les plans théoriques et pratiques. Ce travail a
permis la mise en œuvre d’une solution réseau de l’équipementier Cisco permettant d’améliorer
la gestion du réseau d’entreprise, en se basant sur le MPLS-VPN existant, avec les résultats
probants suivants : l’automatisation des déploiements, la centralisation de la gestion, la vue
globale du réseau sur interface web, la possibilité d’application de politiques de sécurité et
gestion de trafic sans intervenir physiquement sur les équipements.
Mots clés : SD-WAN, MPLS, VPN, administration réseau, CISCO, déploiements.

RESUME / ABSTRACT
RÉSUMÉ/ABSTRACT
ABSTRACT
In order to remain competitive following the constant need to use the network and with the
growth in the number of sites in its corporate network, CAMTEL has migrated to a software-
oriented network architecture (SD-WAN) made up of 3 plans including data, control and
management. Manually administering the corporate network of many routers interconnected by
an MPLS cloud, as known to date, is tedious and prone to many errors. As interconnection
monitoring, service availability and QoS are crucial for the operation of the business, it would
be essential to be able to automate deployments and centralize this management so as to allow
those responsible for the corporate network to concentrate. on aspects of access to services and
traffic management. The technological principles of Cisco's SD-WAN are analysed and
integrated into the architecture of the corporate network in order to respond to the various issues
that will arise in the context of existing operations, while relevant to a number of challenges on
the theoretical and practical plans. This work allowed the implementation of a Cisco equipment
network solution to improve the management of the corporate network, based on the existing
MPLS-VPN, with the following convincing results: the automation of deployments,
centralization of management, global view of the network on the web interface, the possibility
of applying security policies and traffic management without physically intervening on the
equipment.
Keywords: SD-WAN, MPLS, network administration, CISCO, deployments.

LISTE DES FIGURES
LISTE DES FIGURES

Figure 1: Arbre Technologique WAN [11] ----------------------------------------------------------- 15
Figure 2: Mécanisme de commutation de paquets [12] --------------------------------------------- 16
Figure 3 : Architecture MPLS [13] -------------------------------------------------------------------- 17
Figure 4 : Mécanisme d'étiquette MPLS [7] ---------------------------------------------------------- 18
Figure 5: L’en-tête MPLS [21] ------------------------------------------------------------------------- 19
Figure 6 : Mécanique VPN MPLS [4] ----------------------------------------------------------------- 20
Figure 7: Croissance de la table BGP - 1994 à aujourd'hui [15] ----------------------------------- 21
Figure 8: Architecture VPN MPLS [17] -------------------------------------------------------------- 23
Figure 9: VPN de site à site [16] ----------------------------------------------------------------------- 26
Figure 10: VPN d'accès à distance [14] --------------------------------------------------------------- 26
Figure 11: Architecture IPsec [18] --------------------------------------------------------------------- 27
Figure 12: Types de VPN IPsec [5] -------------------------------------------------------------------- 28
Figure 13: Comparaison Transport ESP et du mode tunnel ---------------------------------------- 29
Figure 14: Format de paquet AH ----------------------------------------------------------------------- 29
Figure 15: Trois couches de réseau [19]--------------------------------------------------------------- 34
Figure 16: Architecture SDN [19] ---------------------------------------------------------------------- 35
Figure 17: Architecture du commutateur OpenFlow [19] ------------------------------------------ 36
Figure 18: L'évolution des services cloud [20] ------------------------------------------------------- 39
Figure 19: Le concept SD-WAN [22] ----------------------------------------------------------------- 40
Figure 20: L'architecture SD-WAN [3] --------------------------------------------------------------- 41
Figure 21: Architecture SD-WAN Cisco [23] -------------------------------------------------------- 43
Figure 22: Connexions de contrôle [23] --------------------------------------------------------------- 43
Figure 23: Contrôle de Connexions WAN Edge[23] ----------------------------------------------- 44
Figure 24: Liste Blanche vEdges et Contrôleurs[23] ------------------------------------------------ 45
Figure 25: Validation de l'identité de l'appareil via certificats[23] -------------------------------- 46
Figure 26: vManage racine CA pour les routeurs cloud WAN Edge[23] ------------------------ 47
Figure 27: Authentification et autorisation du dispositif SD-WAN[23] -------------------------- 48
Figure 28: Introduction d'un WAN Edge dans l’overlay network[23] ---------------------------- 49
Figure 29: ZtP et PnP [23]------------------------------------------------------------------------------- 51
Figure 30: Underlay vs Overlay Routing[23]--------------------------------------------------------- 52
Figure 31: Opération OMP [23] ------------------------------------------------------------------------ 53
Figure 32: Cryptage du plan de données -------------------------------------------------------------- 54
Figure 33: Tableau de bord SD-WAN ----------------------------------------------------------------- 55
Figure 34: Séquence Déploiement SD-WAN[24] --------------------------------------------------- 56
Figure 35: Flexibilité de déploiement des contrôleurs[24] ----------------------------------------- 56
Figure 36: Routeur Edge simple ou double WAN Edge [24] -------------------------------------- 57
Figure 37: Routage[24] ---------------------------------------------------------------------------------- 58
Figure 38: Connexions MPLS et Internet avec les WAN Edge [24] ------------------------------ 59
Figure 39: Options de transport pour WAN Edge[24] ---------------------------------------------- 60
Figure 40: Modèles de périphériques et de fonctionnalités ----------------------------------------- 61
Figure 41: Déploiement et établissement du plan de données [23] -------------------------------- 64
Figure 42: Méthode de déploiement vManage ------------------------------------------------------- 65
Figure 43: Méthode de déploiement vSmart ---------------------------------------------------------- 66
Figure 44: Méthode de déploiement vBond ---------------------------------------------------------- 67
Figure 45: Condition préalables WAN Edge --------------------------------------------------------- 62
Figure 46: Méthodologie déploiement vEdge -------------------------------------------------------- 63
Figure 47: Exemple de déploiement OSPF ----------------------------------------------------------- 68

LISTE DES FIGURES
Figure 48: Modèle de configuration OSPF cote VPN de service ---------------------------------- 68

Figure 49: Logo EVE-NG ------------------------------------------------------------------------------- 69
Figure 50: Page d’accueil EVE-NG Community ---------------------------------------------------- 69
Figure 51:Architecture Transport MPLS -------------------------------------------------------------- 75
Figure 52: Création des sites distants ------------------------------------------------------------------ 76
Figure 53: Création du site des contrôleurs ----------------------------------------------------------- 76
Figure 54: Carte réseau virtuelle de Management --------------------------------------------------- 77
Figure 55: Architecture de Simulation----------------------------------------------------------------- 78
Figure 56: Téléchargement et enregistrement du fichier serial ------------------------------------ 78
Figure 58: Démarrage du contrôleur vManage ------------------------------------------------------- 79
Figure 59: vSmart et vBond installés ------------------------------------------------------------------ 80
Figure 60: WAN Edge installé -------------------------------------------------------------------------- 80
Figure 61: Vérification de la mise en œuvre ---------------------------------------------------------- 81
Figure 62: configuration de base des interfaces ------------------------------------------------------ 81
Figure 63: configuration de base du routage ---------------------------------------------------------- 81
Figure 64: Accès à l'espace des Modèles -------------------------------------------------------------- 82
Figure 65: Ajout des fonctionnalités ------------------------------------------------------------------- 82
Figure 66: Sélection fonctionnalité VPN -------------------------------------------------------------- 83
Figure 67: Nom et description de la fonctionnalité VPN ------------------------------------------- 83
Figure 68: Configuration basique de la fonctionnalité VPN --------------------------------------- 83
Figure 69: Configuration de la route statique dans le VPN----------------------------------------- 84
Figure 70: Bouton Save ---------------------------------------------------------------------------------- 84
Figure 71: Fonctionnalité VPN Interface Ethernet -------------------------------------------------- 85
Figure 72: Configuration de l'interface ---------------------------------------------------------------- 85
Figure 73: Paramètres du tunnel ------------------------------------------------------------------------ 85
Figure 74: Services du tunnel --------------------------------------------------------------------------- 86
Figure 75: Paramètres VPN de service ---------------------------------------------------------------- 87
Figure 76: Paramètres interfaces de service ---------------------------------------------------------- 87
Figure 77: Fonctionnalité OSPF ------------------------------------------------------------------------ 88
Figure 78: Configuration des paramètres de la fonctionnalité OSPF ----------------------------- 88
Figure 79: Création du modèle de périphérique ------------------------------------------------------ 89
Figure 80: Configuration des paramètres du modele de peripherique ---------------------------- 90
Figure 81: Association des Peripheriques vEdges au modèle -------------------------------------- 91
Figure 82: Sélection des périphériques à associer --------------------------------------------------- 91
Figure 83: Spécification des paramètres variables des vEdges ------------------------------------ 92
Figure 84: Annonce des configurations --------------------------------------------------------------- 92
Figure 85: Succès de l'application des configurations au vEdges --------------------------------- 93
Figure 86: Vérification des routes OMP et OSPF --------------------------------------------------- 93
Figure 87: Vérification des interfaces ----------------------------------------------------------------- 94
Figure 88: Vérification de la relation OSPF ---------------------------------------------------------- 94
Figure 89: Connectivité dans le VPN 1 --------------------------------------------------------------- 94
Figure 90: Connectivité dans le VPN 2 --------------------------------------------------------------- 94

LISTE DES TABLEAUX
LISTE DES TABLEAUX

Tableau 1: Prérequis Matériel Minimal Pc/Laptop et EVE-NG .............................................. 70

TABLE DES MATIERES
TABLE DES MATIERES

Dédicaces ........................................................................................... 1
Remerciements .................................................................................... 2
Glossaire ............................................................................................ 3
Résumé/Abstract .................................................................................. 5
Résumé .............................................................................................. 5
Abstract ............................................................................................. 6
Liste des figures ................................................................................... 7
Liste des tableaux ................................................................................. 9
Introduction Générale ........................................................................... 11
Contexte et Problématique .................................................................... 13
1.1- Contexte................................................................................. 14
1.1.1- Réseaux étendus .................................................................................................................. 14
1.1.2- Réseaux privés virtuels..................................................................................................... 24
1.2- Problématique ......................................................................... 30

1.2.1- Définition du problème..................................................................................................... 31
1.2.2- Etat de l’art............................................................................................................................................ 33
1.2.3- Quelques contraintes........................................................................................................................ 36
1.2.4. Cahier de Charges ............................................................................................................................... 36
1.3- Bilan ...................................................................................... 37
Méthodologie .................................................................................. 38
2.1. SD-WAN ....................................................................................... 39

2.1.1- Introduction........................................................................................................................... 39
2.1.2- Réseau étendu défini par logiciel ................................................................................. 39
2.1.3- Quelques Fournisseurs SD-WAN .................................................................................. 40
2.1.4- L'architecture générale SD-WAN.................................................................................. 41
2.1.5- La solution Cisco SD-WAN ............................................................................................... 41
2.1.3 Options de déploiement CISCO SD-WAN ................................................................................... 55
2.2. Généralités sur la méthodologie de déploiement ................................... 61

2.2.1- Méthodologie de déploiement des WAN-Edge ...................................................... 61
2.2.2- Déploiement de contrôleur sur site CAMTEL.......................................................... 63
2.2.3- Méthodologie d’interconnexion des sites VPN service par OSPF ................... 67

TABLE DES MATIERES
2.3. Choix de l’outils de simulation .......................................................... 68
2.4. Analyse des besoins et contraintes ..................................................... 70

2.4.1. Contraintes Matérielles .................................................................................................................... 70
2.4.2 Plateformes de virtualisation supportées : .............................................................................. 70
2.5- Bilan ...................................................................................... 71
Résultats et commentaires ..................................................................... 72
3.1- Rappel des objectifs .................................................................. 73
3.2- Architecture Structurelle de la simulation ....................................... 73

3.2.1- Challenges à relever ........................................................................................................... 73
3.2.2- Mise en œuvre de la Simulation .................................................................................... 73
3.3- Etapes préliminaires .................................................................. 77

3.3.1- Cisco Virtual Account ....................................................................................................................... 78
3.3.2- INSTALLATION des équipements ............................................................................................... 79
3.4- Présentation des résultats ........................................................... 81

3.4.1- Déploiement des Sites Clients ........................................................................................ 81
3.4.2- Mise en place des modèles de configuration ........................................................... 81
3.4.3- Application des modèles aux périphériques ........................................................... 90
3.4.4- Vérification des configurations ..................................................................................... 93
3.4.5- Communication inter-sites entre VPN ....................................................................... 94
3.5- Bilan ...................................................................................... 95
Conclusion et Perspectives..................................................................... 96
Bibliographie ...................................................................................... 97
Annexes ............................................................... Erreur ! Signet non défini.
Annexe 1 : Présentation de CAMTEL ............................ Erreur ! Signet non défini.

Genèse de CAMTEL ....................................................................................Erreur ! Signet non défini.
Missions et Projets .....................................................................................Erreur ! Signet non défini.
Services et produits Grand Public .......................................................Erreur ! Signet non défini.
Identités ..........................................................................................................Erreur ! Signet non défini.
Organigramme .............................................................................................Erreur ! Signet non défini.
Annexe 2 : Configurations contrôleurs et vEdges lors de la mise en œuvre .. Erreur !

Signet non défini.

INTRODUCTION GENERALE
INTRODUCTION GÉNÉRALE
Ces dernières années, le numérique occupe une place de plus en plus importante pour le
développement économique, social, et culturel des pays, surtout des pays en développement. Il
revient ainsi au Cameroun se voyant émergent à l’horizon 2035, d’assurer pleinement les
challenges dans ce secteur qui lui permettront alors d’être compétitif à l’échelle mondiale. C’est
dans cette vision que l’Etat du Cameroun, à travers son opérateur historique des
télécommunications qu’est la CAMTEL, se trouve dans l’obligation d’intégrer des
technologies de plus en plus innovantes pour la gestion et le déploiement de son infrastructure
réseau sur le territoire national.
Dans cette optique, la CAMTEL a implémenté un réseau IP national qui interconnecte tous les
sites opérationnels de l’entreprise à travers un réseau backbone IP-MPLS en place depuis 2014.
A l’heure actuelle plus de 80% de sites de l’entreprise ont été migrés sur ce backbone. Les
services offerts aux employés sont multiples allant des Emails aux accès de plateformes de
supervision, de suivi clientèle, de facturation et de vidéosurveillance. On est donc là dans le
cœur des services liés au système productif des ressources clés de l’opérateur. Afin d’optimiser
au mieux l’accès à ces différentes ressources et améliorer la capacité d’accès à ces différents
services, CAMTEL a décidé de migrer son réseau d’entreprise vers une architecture virtualisée
ou dématérialisée afin d’automatiser au maximum les déploiements de tous ses sites et surtout
manager les aspects réseaux et services en un point central.
Etude faite, le déploiement et la gestion de l’infrastructure réseau d’entreprise requiert de
ressources humaines et matérielles conséquentes pour CAMTEL, de ce fait l’intégration d’une
solution de virtualisation déjà utilisée et implémentée par les autres opérateurs du secteur au
Cameroun et à travers le monde devient un impératif. En effet le secteur de la virtualisation
connait une croissance intéressante et les prévisions du secteur en Afrique sont plutôt
prometteuses.
Ce mémoire décrit les perspectives des réseaux étendus et l’intégration du Software Defined
WAN (SD-WAN) dans les réseaux d’entreprises de CAMTEL. Les technologies WAN
existantes sur le marché, utilisées de façon courante par l’opérateur, seront discutées afin de
souligner leurs points faibles et forts pour de se faire une idée claire de l’existant. Les principes
technologiques du SD-WAN de Cisco sont analysés et intégrés dans l’architecture du réseau
d’entreprise afin de répondre aux différentes problématiques qui vont se présenter dans le cadre

INTRODUCTION GENERALE
du fonctionnement existant, le tout en relevant un certain nombre de challenges sur les plans
théoriques et pratiques.
L’essentiel de ce travail constitue de ce fait le contenu du présent mémoire que nous avons
structuré en trois (03) chapitres ainsi qu’il suit :
- Le chapitre 1 « Contexte et problématique » décrit le contexte de notre travail et fait
ressortir le problème que vient résoudre notre contribution après avoir fait une étude et
analyse de l’existant ;
- Le chapitre 2 « Méthodologie » présente la méthode que nous
avons utilisée pour résoudre ce problème sus-identifié, en l’occurrence la méthode de
déploiement et d’intégration de la solution SD-WAN de CISCO, tout en justifiant les
choix de chaque élément entrant dans la conception et la réalisation de notre système ;
- Le chapitre 3 « Résultats et commentaires » décrit les
résultats de notre travail, découlant de la méthodologie plus haut, tout en commentant
lesdits résultats en termes de déploiement et de gestion du réseau d’entreprise à partir
de la solution Cisco SD-WAN.
Nous terminerons par une conclusion et mentionnerons quelques perspectives pour
améliorer notre travail

CHAPITRE 1 : CONTEXTE ET PROBLEMATIQUE
CONTEXTE ET PROBLÉMATIQUE
e chapitre présente le contexte du travail et la problématique associée. En effet dans un
C premier temps il est question de ressortir l’état actuel du réseau WAN de CAMTEL, les
technologies utilisées de façon courante au niveau du réseau d’entreprise, leurs atouts
ainsi que leurs différentes limitations. Ensuite il est question de ressortir le problème de
base qui découle de ces différentes limitations en rapport avec l’existant pour enfin proposer la
solution appropriée.

1.1- CONTEXTE
Cette partie va nous permettre de présenter plus en détails des technologies WAN actuelles
existantes sur le marché WAN, utilisées par CAMTEL pour déployer ses réseaux locaux, leurs
types et principes de fonctionnement. Les VPN Internet sont également soumis à un examen.
Les principes fondamentaux de la mise en réseau définie par logiciel sont également discutés
et expliqués en introduction du SD-WAN. La première solution WAN qui est abordée est le
MPLS VPN. Les principes de base du BGP sont expliqués avec ceux du MPLS. Les VPN de
couche 2 et de couche 3 sont examinés. La deuxième solution qui est considérée est IPsec. Les
principes généraux d'IKE sont expliqués.
1.1.1- RÉSEAUX ÉTENDUS

1.1.1.1- EVOLUTION DES RÉSEAUX ÉTENDUS
Depuis l'émergence d'ARPANET dans les années 1960, le premier ordinateur TCP / IP réseau,
le monde est devenu extrêmement attaché à sa version moderne- l'Internet. Il y a quelques
événements historiques importants qui sont responsable d'Internet tel que nous le voyons
aujourd'hui. Le développement d'Ethernet en 1974 au Xerox PARC et son succès en tant que
premier réseau local largement déployé vers 1980. L'émergence du changement dans les années
1990, qui a remplacé les ponts à faible fonctionnalité qui étaient utilisés à l'époque.
L'introduction du premier routeur multi protocole commercial en 1986 par Cisco, qui a
transformé le monde des réseaux informatiques. Tous ces événements ont grandement contribué
à la recherche et au développement dans le domaine des réseaux informatiques. Plus tard,
lorsque la mise en réseau est devenue disponible à des fins commerciales, après 1990, il fallait
un autre type de technologie capable de connecter non seulement des ordinateurs locaux, mais
aussi des ordinateurs distants. Cela a déclenché l'émergence de réseaux WAN. La première
forme de réseau étendu était les soi-disant lignes louées, qui étaient de simples connexions
privées qui avaient besoin de médias partagés, à travers lesquels les connexions individuelles
des plusieurs clients ont été multiplexés. Le premier commutateur commercial à commutation
de paquets. La technologie WAN, cependant, était Frame Relay. Il a été conçu pour remplacer
les lignes louées et forment un seul protocole WAN à commutation de paquets indépendant du
protocole. Une autre technologie WAN importante qui a commencé le passage du paquet aux
réseaux à commutation de cellules était ATM, à la fin des années 80. La rivalité a duré près
d'une décennie jusqu'à ce que les réseaux à commutation de paquets prennent le relais et
deviennent le standard pour l'Internet moderne [1]. L’autre technologie WAN que nous pouvons
mentionner est encore la technologie WAN dominante aujourd'hui, de sa création en 1999.

Cette technologie est appelée MPLS et elle est standardisée par IETF dans RFC3031. MPLS
est basé sur la commutation de balises, un pro-solution prioritaire lancée en 1998 et axée sur
l'étiquetage des paquets IP.
Toutes les technologies WAN mentionnées ci-dessus nécessitent les services d'un fournisseur
d’équipement de télécommunications, qui est responsable pour leur gestion et les fournit en tant
que service aux clients potentiels.
1.1.1.2- TYPES
Il existe de nombreuses technologies conçues pour la communication WAN telles que SDH,
DWDM, VSAT, ISDN, Frame Relay, ATM, Metro Ethernet, MPLS, DSL. Ces technologies
peuvent être regroupées en deux grandes catégories, comme le montre la figure 1
Figure 1: Arbre Technologique WAN [11]

Les technologies WAN privées peuvent être divisées en technologies dédiées et commutées. Un exemple
de WAN privé dédié peut être la transmission SONET / SDH ou DWDM.
Les technologies WAN publiques, en revanche, reposent sur Internet qui fournit un réseau mondial aux
entreprises, où elles peuvent connecter tous leurs bureaux ensemble et partager des informations entre
elles. Il y a cependant un hic. Étant donné qu'Internet est un réseau public, tous ceux qui y sont connectés
peuvent voir les informations qui les traversent. C'est certainement quelque chose dont les entreprises
ne veulent pas. Et la solution à ce problème est les technologies VPN.
Lorsqu'un niveau élevé de sécurité est nécessaire, l'avantage revient au WAN privé. Mais lorsque des
coûts de mise en œuvre et une flexibilité faible sont plus recherchés, le WAN public doit être envisagé.

Tout dépend des exigences spécifiques de l'entreprise.

- COMMUTATION DE PAQUETS
Etant donné que la compréhension de la commutation de paquets est le fondement des solutions
WAN moderne nous pouvons examiner son principe de fonctionnement. Le mécanisme de
commutation de paquets est illustre dans la figure 2. Ce mécanisme transmet les données sous
forme de paquets qui sont routes et commutes, selon le réseau qu’ils traversent. Le réseau de
transport est partage entre tous les utilisateurs, entrainant des couts bas pour les clients par
rapport aux solutions WAN dédiées. S’il existe un besoin de communication privée sur le réseau
à commutation de paquets, des canaux virtuels sont formés entre les points d’intérêts et leur
trafic est caché au reste du trafic public. Il existe 2 méthodes principales pour transmettre des
données dans un environnement à commutation de paquets : orienté connexion et sans
connexion. Un exemple de technologie à commutation de paquets orienté connexion peut être
frame Relay ou MPLS.
Figure 2: Mécanisme de commutation de paquets [12]

1.1.1.3- MULTI-PROTOCOL LABEL SWITCHING VPN
Cette technologie représentant le plus grand concurrent du SD-WAN, et elle en est également
un élément majeur pour son fonctionnement.
A- MPLS

Afin de bien comprendre les principes du MPLS, nous devons commencer par sa terminologie.
Du point de vue d'un FAI, le périphérique client utilisé pour se connecter au FAI est appelé
périphérie client (CE). De l'autre côté, le périphérique du FAI utilisé comme connexion au client
est appelé fournisseur (PE). Les autres routeurs du réseau du FAI, qui ne sont responsables que
des opérations principales et ne sont pas connectés à des périphériques externes, sont
simplement appelés routeurs fournisseur (P). Du point de vue MPLS, tous les routeurs qui
exécutent MPLS sont appelés routeurs à commutation d'étiquettes (LSR). Cette terminologie
vient du fait que l'architecture MPLS utilise des étiquettes pour transférer des paquets via le
réseau au lieu d'adresses IP, qui est la méthode de transfert traditionnelle. On peut dire que les
routeurs P sont en fait également des routeurs LSR. De plus, les routeurs PE, du point de vue
MPLS, peuvent également être appelés routeurs de bord d'étiquette (LER). Le chemin emprunté
par les paquets MPLS, de leur point d'entrée dans le réseau du FAI au LER de sortie, est appelé
chemin à commutation d'étiquettes (LSP). Il est important de noter que les LSP sont
unidirectionnels. L'architecture MPLS est visible sur la figure 3.
Figure 3 : Architecture MPLS [13]

MPLS fonctionne avec un mécanisme orienté connexion, créant le canal de communication
avant le début de la communication réelle. Le principe central de MPLS est la mise en œuvre
d'un mécanisme de services différenciés, qui traite chaque paquet en fonction de son flux de
trafic - les adresses IP source et de destination. Lorsque des paquets externes entrent dans le
réseau MPLS, ils sont affectés à une classe d'équivalence directe (FEC) en fonction de leur
adresse IP de destination. Ensuite, tous les paquets qui appartiennent à la même FEC sont

affectés avec la même étiquette pour un traitement ultérieur. L'étiquette est un identifiant local
qui indique à quelle FEC appartient le paquet. La FEC peut être basée sur les adresses IP de
destination, la classe de trafic basée sur la valeur du point de code DiffServ IP (DSCP), les
groupes de multidiffusion, les valeurs du circuit virtuel (VC) MPLS VPN de couche 2 ou les
adresses IP qui font partie des ensembles spéciaux de préfixes BGP utilisés pour fins de routage.
Les paquets sont étiquetés une fois qu'ils entrent dans le LER d'entrée et leurs étiquettes sont
supprimées lorsqu'ils quittent le réseau MPLS. De plus, les paquets sont transmis via le réseau
MPLS uniquement sur la base de leurs étiquettes, qui sont utilisées pour déterminer le saut
suivant. (Voir figure 4)
Figure 4 : Mécanisme d'étiquette MPLS [7]

L'étiquette MPLS réelle peut être vue sur la figure 5, où la structure de l'en-tête MPLS est affichée. Il se
compose de 32 bits, dont les 20 premiers représentent la valeur réelle de l'étiquette. Cette valeur est dans
la plage 0 − (220 − 1) .
Les 16 premières valeurs de cette plage sont réservées à un usage spécial. Et les étiquettes
MPLS normales commencent à partir de la valeur de 16. La partie suivante de l'en-tête est le
champ expérimental, représenté sur 3 bits et utilisé pour appliquer la QoS. BoS est le champ
suivant, abréviation de Bottom of Stack, ou généralement appelé bit S. Il se compose d'un seul
bit, qui est utilisé pour déterminer la dernière étiquette d'une pile d'étiquettes. MPLS permet
l'agrégation de flux et plusieurs étiquettes peuvent être "empilées" sur le même paquet. Ceci est
connu sous le nom d'empilement d'étiquettes et utilise le mécanisme Last In First Out (LIFO).
Le bit BoS est 0 pour toutes les étiquettes de la pile, à l'exception de l'étiquette inférieure, pour
laquelle il est défini sur 1. Les 8 derniers bits sont utilisés pour la valeur Time To Live (TTL).

Figure 5: L’en-tête MPLS [21]

Le changement d'étiquette se fait via la table de transfert MPLS, qui contient toutes les
informations nécessaires à la distribution des paquets étiquetés. Ce type de différenciation du
trafic permet un niveau élevé de qualité de service (QoS), appliqué à travers des politiques sur
les différentes classes de trafic. Pour la distribution des paquets étiquetés, cependant, un
mécanisme commun est nécessaire. Il existe deux mécanismes qui peuvent être utilisés pour
distribuer des paquets MPLS. Premièrement, les étiquettes peuvent être placées au-dessus d'un
protocole de routage IP existant et deuxièmement un protocole distinct ne peut être utilisé que
pour la distribution d'étiquettes. L'option la plus courante est l'utilisation d'un protocole distinct
et ce protocole est le Label Distribution Protocol (LDP). Il existe un autre protocole utilisé pour
la distribution des étiquettes Resource Reservation Protocol (RSVP), qui est utilisé
principalement pour l'ingénierie du trafic MPLS. L'un des principaux avantages du MPLS est
que la table de transfert MPLS consomme moins de puissance de traitement que la table de
routage ordinaire et permet un traitement plus rapide des paquets. Il existe actuellement 718223
préfixes IP qui sont routés sur Internet. Sans MPLS, les calculs que chaque routeur doit
effectuer afin de calculer le meilleur itinéraire vers une adresse IP de destination spécifique
seraient importants. MPLS présente également d'autres avantages très importants, tels que sa
prise en charge des étiquettes multicouches et son plan de transmission orienté connexion.
MPLS fournit également une ingénierie de trafic intelligente, qui est une caractéristique
extrêmement importante pour les FAI afin de leur permettre de manipuler le trafic client de la
manière la plus appropriée. Ces fonctionnalités font du MPLS la technologie dominante pour
les services VPN à grande échelle et la priorisation de la QoS.
L'application MPLS la plus utilisée est le VPN MPLS, illustré dans la figure 6. Ce service est
basé sur le réseau MPLS existant d'un FAI tel que CAMTEL et utilise la technologie MPLS
pour créer des canaux virtuels au sein de ce réseau et les utiliser pour transmettre en privé le
trafic client entre plusieurs emplacements. Cependant, MPLS n'est pas capable de réaliser ce
service à lui seul. Un protocole de routage est également requis et le protocole utilisé pour cela
est BGP.

Figure 6 : Mécanique VPN MPLS [4]

B- Border Gateway Protocol
Nous allons brièvement discuter de ce qu'est BGP (Border Gateway Protocol) et mettre l'accent
sur les attributs et extensions nécessaires pour le VPN MPLS. BGP, ou plus précisément BGP
version 4 (BGP4) est le protocole de routage responsable d'Internet. C'est le seul protocole de
passerelle extérieure (EGP) que nous utilisons aujourd'hui et il est très différent de la plupart
des protocoles de passerelle intérieure (IGP) comme OSPF, EIGRP et IS-IS. [26] BGP n'est ni
un vecteur de distance ni un protocole de routage d'état de liens. Au lieu de cela, il est appelé
protocole de routage à vecteur de chemin et il a été conçu pour avoir de nombreux attributs ou
vecteurs capables d'influencer le trafic. Cependant, toutes les entreprises ne sont pas connectées
à Internet via BGP. BGP est utilisé lorsqu'une entreprise dispose d'un réseau plus complexe
avec différentes routes IP et souhaite disposer d'une connexion Internet principale et de
sauvegarde via plusieurs FAI. Il y a deux avantages principaux du BGP qui doivent être
mentionnés. Le premier est son évolutivité. Il n'existe aucun autre protocole de routage capable
de gérer l'ensemble d'Internet. Le deuxième avantage est sa personnalisation. Lorsque la grande
quantité d'attributs BGP est combinée avec des politiques de routage, les possibilités de
personnalisation du trafic deviennent extrêmement élevées.
L'évolution d'Internet est présentée sur la figure 7 avec la croissance exponentielle de la table
BGP mondiale de 1994 a nos jours.

Figure 7: Croissance de la table BGP - 1994 à aujourd'hui [15]

C- SYSTÈME AUTONOME
Aujourd'hui, Internet est un réseau complexe de réseaux connectés via BGP. BGP examine ces
réseaux avec le concept de systèmes autonomes (AS). Chaque entreprise qui utilise BGP pour
se connecter à Internet possède son propre numéro AS (ASN). Les AS sont gérés par les
Registres Internet Régionaux (RIR) et il existe des politiques spécifiques pour leur affectation.
En Europe, ils sont gérés par Réseaux IP Européens (RIPE) et selon leur définition, un AS est
"un groupe de réseaux IP gérés par un ou plusieurs opérateurs de réseau avec une seule politique
de routage clairement définie".[29]
D- BGP MULTI PROTOCOLE
BGP en lui-même est incapable de transmettre des informations MPLS et doit donc être étendu
pour fournir une prise en charge multi protocole pour la création de VPN MPLS. Le BGP multi
protocole (MP-BGP), normalisé dans la RFC4760, ainsi que l'attribut BGP étendu Route Target
du RFC4364, fournissent les outils nécessaires à la réalisation de cette solution VPN. Les deux
nouveaux attributs apportés par MP-BGP sont les informations MRNLRI (Multiprotocol
Reachable Network Layer Reachability Information) et MUNLRI (Multiprotocol Unreachable
NLRI). Ils sont tous deux constitués de l'identificateur de famille d'adresses (AFI) et de
l'identifiant de famille d'adresses suivant (SAFI) et sont utilisés pour déterminer les types de
routes que BGP distribue. L'AFI décrit le protocole de communication réseau spécifique - IPv4,
IPv6, VPN-IPv4 ou VPN-IPv6 et le SAFI indique si le trafic est unicast, multicast ou VRF. Le
concept Virtual Routing and Forwarding (VRF) fournit des tables de routage virtuelles
distinctes pour chaque connexion VPN. Les AFI VPN-IPv4 et VPN-IPv6 spéciaux sont formés

avec l'ajout d'un Route Distinguisher (RD) au préfixe IP sélectionné. Le RD fait 8 octets de
long et il est utilisé pour séparer différentes routes VPN qui utilisent le même préfixe IP. [34]
De cette façon, des préfixes VPN-IP uniques sont formés. Lors de l'importation de routes IP
dans les familles d'adresses BGP, l'attribut BGP étendu Route Target (RT) est ajouté au préfixe.
Il est responsable de la mise en correspondance du préfixe IP avec le VRF / VPN spécifique
auquel il appartient. Une route IP donnée peut avoir plusieurs RT mais ne peut avoir qu'un seul
RD. Tout itinéraire mappé avec un RT spécifique doit être distribué à tous les autres itinéraires
mappés avec le même RT, créant la table VRF privée.
E- VPN DE COUCHE 2 ET DE COUCHE 3
La technologie MPLS prend en charge deux types de services VPN, la couche 2 et la couche 3
VPN.
Le VPN de couche 2, également connu sous le nom de LAN privé virtuel (VPLS). C’est un
service opérateur privé de couche 2 simple mais puissant. Il crée un canal virtuel entre les sites
d'un client, qui reste complètement privé du reste du trafic sur le réseau du FAI. Il est important
de noter qu'avec le VPN de couche 2, le routage se produit du côté client, sur le périphérique
CE et le FAI accepte « aveuglément » le trafic de couche 2 et le transporte via les interfaces de
couche 2 dans son réseau MPLS.
Avec le VPN de couche 3, le FAI est responsable de tout le routage entre les différents sites
clients. Les VPN MPLS de couche 3 sont basés sur le modèle homologue et sont donc plus
évolutifs que d'autres modèles basés sur la superposition tels que IPsec. Le VPN de couche 3
est créé à l'aide de tables VRF. Ils sont isolés des autres trafics du réseau du FAI et le trafic du
client est totalement privé. Lorsqu'il y a plusieurs clients connectés au même routeur PE, comme
le montre la figure 8, chaque client appartient à son propre VPN et a donc sa propre table VRF.

Figure 8: Architecture VPN MPLS [17]

BGP est utilisé pour distribuer les informations VPN via le réseau du FAI via l'utilisation de
communautés étendues. Lorsque le trafic client entre dans le réseau BGP / MPLS du FAI, il est
marqué d'un RD. Tous les sites d'un client doivent avoir le même RD. RT est ensuite utilisé
pour importer et exporter les préfixes IP d'un client dans une ou plusieurs tables VRF. Étant
donné que chaque VPN est complètement isolé, cela présente l'opportunité d'une attribution
d'adresse IP en double. Les clients VPN peuvent utiliser les mêmes adresses IP, publiques ou
privées, et être routés sur le même réseau BGP / MPLS à l'aide de RD. Chaque préfixe IP utilisé
par le client est membre de la famille d'adresses BGP IPv4. Pour rendre les adresses IP uniques,
le RD est ajouté au préfixe IP et cette combinaison est insérée dans la famille d'adresses BGP
VPN-IPv4.[54] La sécurité dans MPLS VPN est conçue dans une approche décentralisée avec
la séparation des plans de contrôle et de données.
1.1.1.4- AVANTAGES ET LIMITES
MPLS règne clairement en maître sur les réseaux étendus (WAN). Soixante-quatorze pour cent
des entreprises qui ont participé à l’étude internationale 2011-2012 Computing and
Communications Benchmark de l’entreprise Nemertes ont déployé des services MPLS/IP-VPN.
Il s’agit bien évidemment de réseaux privés virtuels IP de niveau 3, dans lesquels les routeurs
opérateurs s’associent aux routeurs du client (routeurs CE) et les communications entre
l’opérateur et l’entreprise ont lieu au niveau de la couche IP.
A- AVANTAGES

- Routage sous-traité. Avec la technologie MPLS, l’opérateur gère le routage du réseau

étendu. Les entreprises utilisatrices n’ont pas à s’en occuper elles-mêmes ; il leur est plus
simple d’utiliser MPLS que de gérer un grand réseau routé. Et elles réduisent leurs besoins
en ingénieurs spécialistes des routeurs/WAN.
- Interconnectivité sans contraintes. Le trafic d’applications comme la voix et la vidéo suit
un modèle multidirectionnel. MPLS facilite l’interconnexion de sites entre eux et la prise
en charge de tels modèles de trafic.
- Prise en charge intégrée de la qualité de service (QoS). Pratiquement tous les services
MPLS du marché proposent plusieurs niveaux de qualité de service. Les utilisateurs peuvent
indiquer les seuils minimums de temps de latence, de gigue et de perte de paquets pour
chaque type de trafic (voix, vidéo, email, transferts de fichiers en masse, etc.). Par exemple,
le réseau MPLS donne la priorité au trafic des données sensibles à la latence, comme la voix
et la vidéo, par rapport au reste du trafic, moins sensible.
- Contrats de niveau de service (contrats SLA) avec garanties de prestation. Comme
pour la plupart des services destinés aux entreprises, les opérateurs accompagnent la mise
en œuvre de MPLS de garanties en termes de délais d’installation et de disponibilité, à
l’inverse des prestations Internet grand public généralement soumises à une simple
obligation de moyens.
B- LIMITES
L’inconvénient principal du MPLS sera le manque de fiabilité. Les services Internet grand
public en particulier peuvent s’avérer capricieux aussi bien en termes de qualité de service (le
service fonctionne mais mal) que de disponibilité (interruption de service).
Pour les sites où l’obligation de moyen suffit, où la qualité de service n’est pas indispensable et
où l’ubiquité l’emporte sur la fiabilité, les services Internet constituent une bonne solution.
1.1.2- RÉSEAUX PRIVÉS VIRTUELS
Il existe cependant une autre façon de créer des connexions WAN entre sites qui exploitent
l'infrastructure Internet existante et ne dépendant pas d'un service spécifique. Cette méthode est
nommée Virtual Private Networking. Les VPN sont des solutions extrêmement rentables,
évolutives et flexibles qui peuvent être utilisées comme alternative aux technologies WAN
susmentionnées. Les VPN utilisent l'infrastructure publique disponible, c’est-à-dire internet,
pour réaliser un WAN virtuel entre sites d'entreprise. Comme Internet est un réseau mondial, il
offre la possibilité de connecter des sites de partout dans le monde. Les VPN offrent également
une autre option que les réseaux WAN traditionnels le font pas. Il s’agit d'un accès à distance à

l’infrastructure de l'entreprise, qui peut être initialisée à partir de n’importe quel endroit grâce
à internet Il existe plusieurs solutions VPN qui peuvent être adoptées comme solutions par des
entreprises.
Dans le cas de CAMTEL il s’agit de IPsec. IPsec est un ensemble de protocoles utilisés pour
former un canal sécurisé sur Internet au niveau de la couche IP et il est principalement utilisé
pour la création de VPN. IPsec peut être utilisé avec IPv4 et IPv6 pour fournir une sécurité de
trafic de haute qualité sur Internet.
1.1.2.1- TYPES DE VPN
Les VPN sont des connexions virtuelles sécurisées entre deux sites ou plus, qui utilisent Internet
comme réseau de transport. Ils sont considérés comme sécurisés car les informations échangées
entre les sites sont protégées par cryptage. Le lien virtuel qui compose le VPN d'un point à
l'autre est appelé tunnel VPN. Une connexion VPN peut être établie entre différents bureaux
d'une entreprise, également appelés VPN site à site ou entre un appareil et un bureau, appelés
VPN d'accès à distance. L'appareil qui peut être utilisé pour accéder au réseau d'une entreprise
via une connexion VPN peut être n'importe quel type d'appareil intelligent tel qu'un ordinateur
portable, une tablette ou un téléphone.
A- VPN DE SITE À SITE
Le but des VPN de site à site est de connecter les réseaux de plusieurs sites ensemble via
Internet. Les VPN de site à site nécessitent des équipements dédiés tels que des pares-feux, des
routeurs, des commutateurs de couche 3 ou des serveurs. La seule exigence pour chaque site
est d'avoir une connexion Internet. De cette façon, les dépenses ne sont limitées qu'aux appareils
réels utilisés pour créer le VPN et les frais d'abonnement Internet. La connexion VPN de site à
site est statique et les terminaux qui résident à l'intérieur des sites ne connaissent pas son
existence. Les VPN de site à site peuvent être divisés en VPN intranet et extranet. Lorsque le
VPN de site à site connecte des bureaux de la même entreprise, il est considéré comme intranet
et lorsqu'il connecte deux entreprises différentes, il est appelé extranet. Des exemples de
solutions pouvant fournir des services VPN de site à site sont MPLS, DMVPN et IPsec.
L'architecture d'un VPN de site à site est illustrée dans la figure 9.

Figure 9: VPN de site à site [16]

B- VPN D'ACCÈS À DISTANCE
Le but des VPN d'accès à distance est de permettre aux employés qui ne sont pas au bureau
d'accéder à distance à l'infrastructure réseau de l'entreprise. Contrairement aux VPN de site à
site, où la connexion VPN est permanente, les VPN d'accès à distance établissent une connexion
uniquement lorsque cela est nécessaire pour l'utilisateur distant. La connexion VPN d'accès à
distance est dynamique et certains paramètres peuvent être modifiés, comme l'adresse IP de
l'utilisateur qui tente d'initialiser le service. Afin d'établir un VPN d'accès distant, l'utilisateur
distant doit avoir un logiciel client VPN et des informations d'identification pour
l'authentification avec le serveur VPN. Aujourd'hui, les principales solutions VPN d'accès à
distance sont IPsec et SSL. L'architecture d'un VPN d'accès à distance est illustrée dans la figure
10.
Figure 10: VPN d'accès à distance [14]

1.1.2.2- IPSEC
La sécurité du protocole Internet (IPsec) est une suite de protocoles et de technologies qui sont
utilisés pour assurer la sécurité des données transitant sur Internet. Les spécifications et les
méthodes pour réaliser IPsec sont définies dans RFC4301 et RFC6071. Deux protocoles sont
utilisés pour la fourniture de la sécurité sur les réseaux IP, Encapsulating Security Payload
(ESP) et Authentication Header (AH). La version actuelle d'IPsec est IPsec-v3.
A- ARCHITECTURE IPSEC
L'architecture IPsec est illustrée dans la figure 11. Son mécanisme crée un tunnel privé sur
Internet conçu pour transporter en toute sécurité les données des clients entre les points
d'extrémité locaux et distants. Le tunnel privé se compose en fait de deux tunnels distincts, l'un
englobé dans l'autre, grâce à l'utilisation du protocole Internet Key Exchange (IKE) qui sera
discuté plus loin dans cette sous-section. IPsec peut également être utilisé au-dessus du VPN
MPLS afin d'assurer la transmission sécurisée des données IP.
Figure 11: Architecture IPsec [18]

B- ASSOCIATIONS DE SÉCURITÉ
Les associations de sécurité (SA) représentent la boîte à outils qui fournit les détails nécessaires
à la gestion et à la surveillance des sessions IPsec. Les exemples de paramètres SA peuvent être
le cryptage, l'authentification et la gestion des clés.
- ÉCHANGE DE CLÉS INTERNET
IKE est le protocole qui négocie les SA IPsec. Son processus est divisé en deux phases. La
version actuelle d'IKE est la version 2 d'IKE, comme spécifié dans la RFC7296. Le protocole
IKE est capable de fournir des capacités de confidentialité et d'intégrité complètes. Pour des
raisons de confidentialité, des algorithmes cryptographiques tels que Data Encryption Standard
(DES) et Advanced Encryption Standard (AES) peuvent être utilisés. Pour des raisons
d'intégrité, la combinaison d'algorithmes HMAC (Hash-based Message Authentication Code)
et SHA (Secure Hash Algorithm) est recommandée.

LA PHASE 1 : Dans la phase 1, IKE crée un canal sécurisé entre les pairs qui est appelé IKE
SA. IKE authentifie l'homologue et les paquets que l'homologue envoie pendant la phase 1. Il
s'agit de la première étape de la communication IPsec et elle peut être effectuée en deux modes,
principal et agressif. Les principaux paramètres sur lesquels les pairs doivent se mettre d'accord
sont l'authentification, le chiffrement, le groupe diffie-hellman et les méthodes de hachage.
LA PHASE 2 : Dans la phase 2, IKE négocie les SA IPsec, qui sont utilisées pour créer le tunnel
IPsec sur le canal de communication sécurisé IKE phase 1 existant. Les paramètres négociés
pour la phase 2 comprennent le protocole de sécurité sélectionné ESP ou AH et les paramètres
spécifiques d'authentification et de cryptage.
Le VPN IPsec peut être réalisé dans différents types de pairs, comme illustré dans la figure 12
Le premier type est un VPN de site à site typique et parce que les périphériques utilisés pour
créer le tunnel VPN sont appelés des passerelles, il est considéré comme un VPN de passerelle
à passerelle IPsec. Le deuxième exemple montre un VPN IPsec d'accès à distance, réalisé à
partir d'un périphérique final vers une passerelle de sécurité. Ce type de VPN IPsec est appelé
hôte à passerelle. Le dernier type d'homologue VPN est d'hôte à hôte et comme illustré il
représente une solution VPN de bout en bout d'un hôte privé à un autre.
Figure 12: Types de VPN IPsec [5]

- ENCAPSULER LA CHARGE UTILE DE SÉCURITÉ
ESP est le protocole de sécurité qui protège les données IP de toutes les attaques. Il est
responsable de tous les aspects de la sécurité des données, authentification, intégrité et
confidentialité. Le niveau de ces aspects de sécurité dépend du mode IPsec spécifique choisi. Il
existe deux modes de fonctionnement de la solution VPN IPsec qui sont Transport et Tunnel.
Ces deux modes affectent le fonctionnement des protocoles de sécurité IPsec. La différence

entre le tunnel ESP et le mode de transport est illustrée dans la figure 12. En mode transport,
l'en-tête ESP est inséré entre l'en-tête IP et les données. Cela maintient l'en-tête IP d'origine et
permet aux données d'être cryptées, authentifiées et transmises avec ses paramètres d'origine.
En mode tunnel, tout le paquet IP est crypté et l'en-tête ESP est placé avec un nouvel en-tête IP
au-dessus du datagramme d'origine.
Figure 13: Comparaison Transport ESP et du mode tunnel

Le format d'un paquet AH est illustré à la figure 14. Contrairement à ESP, AH se compose
uniquement d'une partie d'en-tête. L'en-tête AH contient les champs suivants : Next Header,
Payload Len, RESERVED, SPI, SN et ICV. Le Next Header, SPI, Les champs SN et ICV
contiennent les mêmes informations que celles discutées avec ESP. Le champ Payload Len est
une valeur de 1 octet qui montre la longueur du bloc d'authentification en mots de 32 bits. Le
champ RESERVED est toujours mis à zéro et il est laissé à des fins expérimentales.
Figure 14: Format de paquet AH

1.1.2.2. AVANTAGES ET LIMITES
A- AVANTAGES
Le plus grand avantage pour les entreprises qui utilisent des solutions VPN sur le WAN
traditionnel est leur prix, cependant, des avantages tels que la fiabilité du trafic inter-sites et une
QoS efficace ne sont offerts que par des solutions WAN traditionnelles.
Les clients VPN IPSec prennent en charge tous les protocoles de couche IP. IPsec est appliqué
à la couche de transport et est transparent pour les applications. Lorsqu'IPSec est installé sur un
routeur ou un pare-feu, il n’y a pas besoin de modifier les paramètres logiciels du système

utilisateur ou serveur. Même si IPSec est exécuté dans le système de terminal, le logiciel de
couche supérieure n'est pas affecté.
Le VPN IPSec a des performances de sécurité élevées. Étant donné que le protocole IPSec
fonctionne au niveau de la couche réseau, non seulement tous les canaux réseau sont chiffrés,
mais également lorsque les utilisateurs accèdent à toutes les ressources d'entreprise, tout comme
ils sont directement connectés au réseau d'entreprise via la ligne privée. IPSec non seulement
crypte la petite partie du canal en cours de communication, mais crypte également tous les
canaux. En outre, IPSec VPN nécessite également l'installation et la configuration appropriées
du logiciel client IPSec et des périphériques d'accès sur les clients d'accès à distance, ce qui
augmente considérablement le niveau de sécurité car l'accès est limité par des périphériques
d'accès spécifiques, des clients logiciels, des mécanismes d'authentification des utilisateurs et
des règles de sécurité prédéfinies.
B- LIMITES
Les performances de communication du VPN IPSec sont faibles. Par ailleurs, étant relativement
élevé en termes de sécurité, il affecte ses performances de communication.
Le VPN IPSec nécessite un logiciel client. Dans le VPN IPSec, vous devez installer un logiciel
client spécial pour chaque client pour remplacer ou ajouter la pile TCP/IP du système
client. Dans de nombreux systèmes, cela peut entraîner un risque de problèmes de compatibilité
avec d'autres logiciels système. Actuellement, il n'y a pas de norme cohérente pour la
compatibilité du protocole IPSec. Presque tous les logiciels clients IPSec sont exclusifs et ne
peuvent pas être compatibles avec d'autres.
La traversée de NAT et de pare-feu n'est pas facile à résoudre. Les produits VPN IPSec ne
résolvent pas les problèmes complexes d'accès à distance, notamment la traduction d'adresses
réseau, la traversée de pare-feu et l'accès à large bande. Par exemple, si un utilisateur a installé
un client IPSec mais ne peut pas accéder à Internet au sein du réseau d'une autre entreprise,
IPSec sera bloqué par le pare-feu de l'entreprise à moins que l'utilisateur ne négocie avec
l'administrateur réseau de l'entreprise pour ouvrir un autre port sur le pare-feu.
1.2- PROBLÉMATIQUE
Après avoir situé le cadre dans lequel notre travail a été effectué, il est nécessaire que nous
présentions le problème que vient résoudre notre travail. Pour cela, nous allons commencer par
énoncer le problème en se basant sur des cas réels, ensuite présenter l’état de l’art et enfin, nous
allons établir le cahier de charges qui nous guidera jusqu’à la résolution de ce problème.

1.2.1- DÉFINITION DU PROBLÈME
1.2.1.1- MOTIVATION
Après des décennies de configurations répétitives, les ingénieurs réseau recherchent à

transmettre une approche qui facilitera le processus de gestion du réseau et y apporter plus
d'automatisation. L'approche définie par logiciel est jusqu'à présent la plus proche de cette idée.
Elle permet une séparation entre les cerveaux et les muscles du réseau et apporte un haut niveau
de programmation dans le jeu de réseautage. L'application du principe défini par logiciel dans
le secteur WAN est réalisée grâce à la technologie SD-WAN. De technologie émergente en
2017, le SD-WAN est devenu rapidement le leader dans le secteur en 2018. Cette transition
rapide est la plus importante évolution du marché WAN depuis son existence.
Les fournisseurs SD-WAN étant indépendants des télécoms et de leurs solutions s'appuyant
majoritairement sur internet, un changement radical du marché s’est produit. Le besoin de
recherche dans le domaine est d'une grande importance pour les professionnels et contribuera à
une meilleure compréhension de l'évolution des WAN. Il existe déjà des succès d’adoption du
SD-WAN. Plusieurs entreprises ont indiqué avoir remarqué une triple amélioration des
performances de leurs applications Office 365 sur les infrastructures de leur réseau mondial,
après avoir déployé une solution SD-WAN. Concernant la situation financière les attentes du
marché du SD-WAN sont également considérables, avec un chiffre d’affaire mondial qui
devrait atteindre 3 milliards USD d'ici 2022. Sur le marché africain des solutions commencent
à émerger notamment avec des opérateurs en République Démocratique du Congo et au Niger
CAMTEL en voulant intégrer cette solution à ses différents réseaux, peut donc compter sur une
croissance intéressante du marché SD-WAN en Afrique qui atteindra le milliard de dollars US
de chiffre d’affaire à l’horizon 2022. Cet engouement constitue une opportunité considérable
pour les opérateurs en termes de transfert de technologie, de création de services nouveaux liés
à la virtualisation qui débouchera naturellement sur de nouveaux emplois.
Cette intégration est liée à des problèmes rencontrés par CAMTEL sur le plan opérationnel
concernant son réseau d’entreprise :
- Une trop grande dépendance aux ressources humaines lors de déploiements de nouveaux
sites : En effet la croissance de l’entreprise sur le territoire implique la création fréquente
de nouveaux sites qui vont se raccorder à l’infrastructure existante. Ces déploiements
impliquent de façon générale l’intervention humaine pour l’installation physique des
équipements et les configurations de départ. Néanmoins ces dernières sont habituellement
sujettes à des erreurs humaines et requièrent un cout en termes de main d’œuvre, les

administrateurs réseau étant appelles tout d’un coup à effectuer des configurations
complexes et répétitives pour déployer leur architecture.
- Un manque de centralisation dans la gestion quotidienne et l’exploitation des
équipements réseau : En effet une fois déployés configures et mis en service, les
équipements ont besoin d’être maintenus et contrôlés. Cette maintenance est généralement
assurée à travers des logiciels tels que PuTTY qui vont utiliser le protocole SSH pour
accéder aux équipements à distance, dans d’autres cas une décente sur site sera nécessaire.
Néanmoins le manque de visibilité globale sur les équipements réseau sur un point central
lie à cette méthode conduit à une gestion plutôt artisanale qui conduit inévitablement à des
erreurs de configurations ou un temps de maintenance trop long lors de l’apparition d’un
problème réseau ; temps qui aurait pu être attribué à d’autres taches.
- Temps de configuration de maintenance trop long pour des sites réseaux similaires : En
effet, il est à noter que CAMTEL déploie régulièrement des sites semblables répondant à
un même type de profil (services voix, données, wifi) sur son réseau d’entreprise. Ces
déploiements qui sont multiples ont généralement les mêmes types de configurations
d’équipements. Le but est donc pour de sites qui répondent à un cahier de charges similaire
de créer des profils de configuration qui pourront être transmis aux équipements à distance
de façon automatique. Cette pratique va fiabiliser les configurations, diminuer le temps de
déploiement et faciliter la maintenance des équipements du réseau.
- Un manque d’identification des services critiques de l’entreprise et l’absence d’une
politique de disponibilité permanente de ces derniers : En effet des services internes et
externes sont fondamentaux pour le fonctionnement quotidien de l’entreprise. Ces derniers
ne sont à l’heure actuelle pas quantifiable sur le plan statistique et leur optimisation reste
floue. Néanmoins l’entreprise fait face à des baisses de qualité réseau sur certains services
(mail, VOIP, Internet) et l’absence d’une politique de gestion centralisée sur une interface
et appliquée à tous les sites du territoire est un frein à l’amélioration de l’expérience des
utilisateurs du réseau.
1.2.1.2- FORMULATION DU PROBLÈME

SD-WAN est conçu pour permettre non seulement aux entreprises de connecter leurs
succursales, comme MPLS, mais aussi pour fournir une connectivité rapide à toutes les
applications cloud. Un autre point majeur du SD-WAN est son manque de complexité de
configuration. La séparation du plan de contrôle du plan de données, qui est le principe majeur

du SDN de base, permet une configuration centralisée de l’ensemble du réseau, qui deviens
facilement administrable. Mais le SD-WAN va-t-il complètement remplacer les solutions WAN
MPLS et VPN actuelles ? Probablement pas, cependant, il est capable d’utiliser à la fois Internet
et les Réseau MPLS afin d'offrir la meilleure optimisation WAN possible pour les affaires. Par
conséquent, dans le cas de CAMTEL SD-WAN et MPLS peuvent coexister car y a un trafic
sensible de son réseau d’entreprise qui peut justifier le coût MPLS.
Le but de ce mémoire est d’intégrer la technologie SD-WAN de CISCO et d'analyser son impact
sur le réseau d’entreprise de CAMTEL. Au vu de tout ce qui précède, notre travail se résume à
répondre à la question suivante :
« COMMENT ADMINISTRER LE PLUS EFFICACEMENT POSSIBLE LE RESEAU IP
D’ENTREPRISE
- EN AUTOMATISANT LES DEPLOIEMENTS
- EN CONFIGURANT LES EQUIPEMENTS A DISTANCE
- ET EN MINIMISANT LES COUTS DE DEPLOIEMENT ? »
1.2.2- ETAT DE L’ART
Pour la résolution de ce problème, il existe dans la littérature quelques travaux récents

effectués dans le domaine lié à une solution existante : Software Defined Networking (SDN).
1.2.2.1- FONDAMENTAUX SDN
Il existe quatre éléments fondamentaux de la séparation du plan SDN ; appareil simplifié et

contrôle central, automatisation et virtualisation de réseaux ;
A- SÉPARATION DES PLANS
Pour une meilleure compréhension de ce principe, les trois niveaux d'abstraction du réseau sont
représentés sur la figure 15.Le plan de données ou de transfert est responsable de la transmission
des paquets sur la base des tables de transfert. Le plan de contrôle est constitué des protocoles
utilisés pour manipuler les mécanismes de transfert de données. Le plan de gestion s'appuie sur
des outils logiciels qui sont utilisés pour influencer les protocoles dans le plan de contrôle. Ce
niveau de séparation est le fondement de SDN.

Figure 15: Trois couches de réseau [19]

B- AUTOMATISATION ET VIRTUALISATION DU RÉSEAU
Le SDN peut être considéré comme une analogie avec l'évolution des langages de
programmation, qui ont évolué à l'aide de l'abstraction. Cette abstraction permet de virtualiser
les fonctions du réseau et conduit à une plus grande productivité. Il est important de noter que
c'est la virtualisation qui permet à SDN de ne pas être spécifique au fournisseur. La figure 16
montre l'architecture SDN et ses deux types de liens, les interfaces nord et sud. L'interface de
programmation d'application (API) en direction nord est utilisée pour connecter le contrôleur
au plan de gestion, où résident toutes les applications. Ce type d'interface peut servir de
passerelle vers une automatisation de réseau de haut niveau. L'API REST est un exemple
d'interface vers le nord et peut être utilisée pour l'intégration avec les outils d'automatisation
modernes (Puppet, Ansible, etc). L'API vers le sud est le lien qui permet au contrôleur de
configurer dynamiquement les périphériques réseau de transfert. Le standard le plus largement
utilisé et ouvert pour l'API est OpenFlow, qui sera abordé ci-après.

Figure 16: Architecture SDN [19]

C- OUVERTURE
L'idée derrière SDN est que tout doit être accompli grâce à l'utilisation de normes ouvertes. De
cette façon, n'importe qui peut comprendre et contribuer au développement de SDN, sans se
soucier des secrets propriétaires. L'Open Networking Foundation (ONF) est une organisation à
but non lucratif qui est responsable du développement et de la promotion des technologies SDN.
Un autre contributeur important est la Fondation Linux. Il est responsable de la création du
logiciel le plus utilisé pour un contrôleur SDN qui est Opendaylight.
1.1.3.2 OPENFLOW
OpenFlow a été créé à l'origine à Stanford à des fins expérimentales, vers 2008, avant la création
de l'ONF en 2011, puis a été normalisé et géré par l'ONF en 2012 après la version 1.1. Il est
connu comme le principal protocole d'API pour communiquer vers les équipements. Il existe
de nombreuses versions des protocoles OpenFlow qui ont été développées pour les contrôleurs
et les commutateurs, le plus connu parmi les commutateurs étant l'Open vSwitch (OVS). Par
commutateurs, dans le contexte SDN, nous nous référons aux dispositifs de transmission
simples qui opèrent dans le plan de données. Il existe deux types de commutateurs OpenFlow :
purs et hybrides. Les commutateurs Pure OpenFlow sont les appareils les plus simples,
également appelés commutateurs à boîte blanche, et ils sont incapables de fonctionner sans
contrôleur. Les commutateurs hybrides, d'autre part, facilitent à la fois les méthodes de transfert
OpenFlow et traditionnelles. L'architecture d'un commutateur OpenFlow est illustrée à la figure
17. Il se compose de plusieurs tableaux de flux, d'une table de groupe et d'un canal. Le canal
représente la couche d'abstraction utilisée pour transmettre en toute sécurité des données entre

le commutateur et le contrôleur. Les tables de flux et de groupe seront discutées plus loin dans
cette section.
Figure 17: Architecture du commutateur OpenFlow [19]

1.2.3- QUELQUES CONTRAINTES
Les technologies examinées dans ce mémoire seront discutées dans des détails et des
connaissances techniques préalables sont requises dans la mise en réseau informatique. Étant
donné que toutes les solutions SD-WAN sont propriétaires, les détails les plus spécifiques
autour de la technologie sont accessibles uniquement chez un vendeur spécifique. Par
conséquent, l'analyse présentera le SD-WAN sur les principes généraux de fonctionnement
avant d’aborder le cas de la solution propriétaire SD-WAN viptela de Cisco. Cette solution a
été choisie par l’entreprise CAMTEL lors de son processus de migration de son réseau IP.
1.2.4. CAHIER DE CHARGES

Au vu des différents problèmes cités précédemment, il nous a été demandé d’intégrer à
l’architecture réseau d’entreprise de CAMTEL la solution orientée logiciel SD-WAN de Cisco
en implémentant par l’intermédiaire d’une simulation.
Du côté de CAMTEL, il faudra mettre en place :

- Une architecture réseau qui utilise le transport MPLS avec des sites d’entreprise dans sur
un VRF interco
- L’implémentation de la solution Cisco SD-WAN sur un des sites de l’entreprise
appartenant au VRF.
- Le déploiement automatique d’un site de l’entreprise et des VPN services données, VOIX
sur un modèle de configuration prédéfini

- La maintenance et gestion du réseau à partir d’un point central (salle serveur ou DATA-
CENTER).
-
1.3- BILAN
Les technologies WAN ont parcouru un long chemin depuis leur invention. Ils font désormais
partie d'un marché dynamique, avec une forte concurrence entre les différents fournisseurs de
réseaux qui continue d’évoluera. Les technologies VPN sont également une partie importante
de ce marché. L'évolution rapide du monde numérique et en particulier la croissance de la
demande de bande passante transforment l'industrie du WAN. Cette transformation vise une
automatisation accrue, une gestion du réseau centralisée et de la flexibilité. La réalisation de
ces objectifs va être faite à l'aide de réseaux définis par logiciel et spécifiquement pour le WAN
avec l'aide de SD-WAN.

CHAPITRE 2 : METHODOLOGIE
MÉTHODOLOGIE
ans ce chapitre, nous allons d'abord dans une première partie présenter la technologie
D SD-WAN et ses composants, ensuite beaucoup plus précisément la technologies SD-

WAN de Cisco après avoir évoqué les solutions concurrentes. Ensuite il sera question
de présenter la méthodologie de réalisation ainsi que la conception de l’architecture.

2.1. SD-WAN
2.1.1- INTRODUCTION
Il est difficile pour le réseau de répondre aux demandes évolutives actuelles des applications.
Surtout dans le secteur WAN, où le besoin de bande passante à la demande et de faible latence,
déclenché par les applications cloud, ne cesse d'augmenter. Alors que les entreprises dépensent
des milliards pour virtualiser et mettre à niveau leur infrastructure de centre de données, la
nécessité de mettre également à niveau le WAN est imminente. Les revenus dépensés sur les
services cloud sont présentés dans la figure 18. Il existe trois principales formes de services
cloud qui sont Software as à Service (SaaS), Platform as à Service (PaaS) et Infrastructure as à
Service (IaaS). Comme nous pouvons le voir, cette tendance montre une croissance quasi-
exponentielle pour la période examinée.
Figure 18: L'évolution des services cloud [20]
2.1.2- RÉSEAU ÉTENDU DÉFINI PAR LOGICIEL

SD-WAN est une technologie qui a le potentiel de révolutionner le secteur des réseaux dans la
zone WAN. Il facilite un nouveau concept pour le secteur des réseaux - la mise en réseau basée
sur les applications, où le réseau devrait s'adapter en fonction des besoins des applications. Ce
concept permet au SD-WAN de remplacer les services d'optimisation WAN, les VPN MPLS
coûteux et les coûts supplémentaires d'automatisation et de gestion du réseau. Ce nouveau
concept est visible sur la figure 19 et sera abordé plus en détail plus loin dans cette section.

Figure 19: Le concept SD-WAN [22]
L’adoption des solutions SD-WAN s’accélère, à l’heure où toujours plus d’entreprises passent
au cloud et visent à simplifier la gestion de leur architecture réseau. Le manque de compétences
à disposition freine néanmoins cette adoption et influence le choix des solutions.
2.1.3- QUELQUES FOURNISSEURS SD-WAN
Nous avons sélectionné cinq fournisseurs de SD-WAN qui se sont distingués avec succès des
autres acteurs du marché au cours de ces dernières années, grâce à un portefeuille perfectionné
de solutions SD-WAN. Bien entendu, il n’existe pas de solution prête à l’emploi lorsqu’il s’agit
de trouver le « bon » fournisseur de SD-WAN. Mais ces cinq fournisseurs valent sans aucun
doute la peine d’être pris en compte lorsque l’on est en phase de sélection d’un fournisseur de
SD-WAN.
- Riverbed SteelConnect
- Netscaler de Citrix
- Silver Peak Unity EdgeConnect
- Juniper Networks Contrail
- SD-WAN de Cisco
La solution SD-WAN résout les problèmes critiques des entreprises, tels que:
- Création d’un WAN qui ne dépend pas du transport pour diminuer les coûts
- Respect des SLA pour les applications en temps réel essentielles à l’entreprise
- Segmentation de bout en bout pour la protection des ressources informatiques essentielles
de l’entreprise
- Extension facile sur un cloud public
- Expérience utilisateur optimale pour les applications SaaS
- Options souples de tarification et de licence

- Plateformes de routage physiques ou virtuelles
2.1.4- L'ARCHITECTURE GÉNÉRALE SD-WAN

L'architecture SD-WAN est illustrée dans la figure 20, il existe trois couches principales de
l'architecture : réseau cloud, services virtuels et orchestration et analyse.
Chaque périphérique SD-WAN doit s'authentifier auprès du contrôleur avant de pouvoir
participer au réseau cloud sécurisé. L'autorisation de l'appareil est contrôlée par l'utilisation de
politiques. Ces politiques sont contrôlées par le plan de contrôle et peuvent être utilisées pour
manipuler le trafic.
Figure 20: L'architecture SD-WAN [3]
2.1.5- LA SOLUTION CISCO SD-WAN
2.1.5.1- ARCHITECTURE ET COMPOSANTS

L'architecture SD-WAN de Cisco de la figure 21 comprend quatre composants différents:
Contrôleur vSmart, Orchestrateur vBond, Routeur vEdge et vManage. Chacun des quatre
composants a ses propres fonctions et capacités spécifiques.
A- VSMART
Le contrôleur vSmart représente le plan de contrôle SD-WAN. Il est responsable du contrôle
global du plan de données et de tous les types de manipulation du trafic. Les connexions entre
le contrôle et les plans de données reposent sur le protocole DTLS. Il s'agit d'une version

spéciale de TLS, conçue pour fonctionner avec UDP. Le protocole de communication utilisé
pour échanger des informations de configuration entre vSmart Controller et vEdge Router est
OMP. C’est le protocole de communication propriétaire de Cisco pour le partage d'informations
entre les plans de contrôle et de données.
B- VBOND
vBond Orchestrateur réside au-dessus des routeurs vEdge et est spécialisé dans le processus
initial de communication entre le routeur et le contrôleur. Il est également chargé d'utiliser la
meilleure communication possible du canal vers le contrôleur, qu'il s'agisse d'Internet, d'un
service MPLS ou d'une connexion mobile.
C- VEDGE (WAN EDGE)
Le routeur vEdge est qui doit être placé dans les différents sites clients. Comme le montre la
figure 21 il peut être utilisé dans toutes les installations, comme les centres de données, les
bureaux du campus, les succursales et les sites éloignés. Les routeurs vEdge sont une version
mise à niveau du routeur IP habituel qui est capable de faciliter les principes définis par le SD-
WAN au côté des procédures de routage traditionnelles. Ils sont capables de fournir toutes les
fonctionnalités de routage essentielles, y compris les protocoles de routage tels que BGP et
OSPF, QoS, politique et contrôle d'accès, et gestion du réseau. La sécurisation de la
communication entre les différents routeurs vEdge s'effectue via des tunnels IPsec.
D- VMANAGE
Le dernier composant de la solution est le contrôleur vManage. Il représente une plate-forme
pour la gestion globale de la configuration et la surveillance de tous les appareils participants
de l'entreprise. Il est basé sur un logiciel et est conçu pour être déployé en tant que machine
virtuelle, à nouveau compatible avec les hyperviseurs VMware.

Figure 21: Architecture SD-WAN Cisco [23]
2.1.5.2- PLAN DE CONTRÔLE

A- CONTRÔLE DE CONNEXIONS
Les contrôleurs Cisco SD-WAN vManage et vSmart contactent et s'authentifient initialement
auprès du contrôleur vBond, formant des connexions DTLS persistantes, puis établissent et
maintiennent par la suite des connexions DTLS / TLS persistantes entre elles. Les périphériques
WAN Edge sont intégrés de la même manière, mais supprimez la connexion transitoire vBond
et maintenez les connexions DTLS/TLS avec les contrôleurs vManage et vSmart. Le
diagramme suivant illustre cela :
Figure 22: Connexions de contrôle [23]

Si un périphérique est configuré pour TLS et un autre périphérique est configuré pour DTLS,
TLS est choisi pour la connexion de contrôle entre les deux périphériques. TLS est recommandé
car il utilise TCP, qui utilise des accusés de réception pour une plus grande fiabilité.
B- CONTRÔLE DE CONNEXION DES WAN EDGE
Le routeur WAN Edge essaie d'établir des connexions de contrôle sur tous les transports
provisionnés par défaut, initiant d'abord le contact avec l'orchestrateur vBond sur chaque
transport avant d'essayer de se connecter à l'autre contrôleurs. Une seule connexion de contrôle
vBond est établie par transport lorsque plusieurs orchestrateurs vBond existent. Le routeur
WAN Edge établit une connexion permanente au contrôleur vSmart sur chaque transport, et
établit une connexion permanente unique à vManage sur un seul transport, le premier qui établit
une connexion.
Une fois la connexion sécurisée établie, NETCONF est utilisé par le vManage pour
provisionner le périphérique WAN Edge, et l'homologation OMP est établie entre le vSmart et
le WAN Edge. L'homologation OMP est établie entre un périphérique WAN Edge et un
contrôleur vSmart, même s'il existe plusieurs connexions DTLS / TLS. ‘
Figure 23: Contrôle de Connexions WAN Edge[23]

C- MODÈLE DE LISTE BLANCHE
Tous les périphériques et contrôleurs WAN Edge s'authentifient mutuellement à l'aide d'un
modèle de liste blanche contenu dans un fichier serial, où les périphériques doivent être
autorisés avant d'établir des connexions et d'être autorisés à accéder au réseau.
Il existe deux listes blanches autorisées distribuées par vManage, une pour les contrôleurs et
une pour les périphériques WAN Edge.

● Liste blanche des contrôleurs : la liste blanche des contrôleurs est le résultat de
l'addition manuelle des contrôleurs dans l'interface utilisateur de vManage. Cette liste
peut être distribuée du vManage à tous les contrôleurs et, par la suite, du vBond aux
contrôleurs vSmart.
● Liste blanche pour les périphériques WAN Edge: le fichier de liste blanche autorisé
signé numériquement pour les périphériques WAN Edge peut être modifié et récupéré
à partir du portail Plug and Play Connect à l'adresse http://software.cisco.com. La liste
peut être récupérée manuellement ou synchronisée automatiquement à partir de
vManage par un utilisateur avec un compte Cisco valide avec accès au compte
intelligent et au compte virtuel appropriés pour la superposition SD-WAN. Une fois la
liste blanche téléchargée ou synchronisée avec vManage, elle est distribuée par
vManage à tous les contrôleurs.
Avec la liste blanche signée WAN Edge, l'administrateur peut décider et configurer la confiance
d'identité de chaque routeur WAN Edge individuel.
Figure 24: Liste Blanche vEdges et Contrôleurs [23]
D- IDENTITÉ
L'authentification entre les appareils implique la validation de l'identité de l'appareil via des
certificats. Fonctionnement de la validation du certificat d’appareil :
● Le périphérique client présente au serveur un certificat de périphérique signé par
l'autorité de certification.
● Le serveur valide la signature du certificat par
1. Exécution d'un algorithme de hachage sur les données de certificat pour obtenir
une valeur, et

2. Décryptage de la signature du certificat avec la clé publique obtenue à partir du

certificat racine de l'autorité de certification pour obtenir une deuxième valeur
Si les deux valeurs sont égales, la signature est valide.
● Le périphérique client est désormais approuvé et la clé publique client peut être
approuvée pour une utilisation dans le chiffrement.
Figure 25: Validation de l'identité de l'appareil via certificats [23]
La figure 26 montre :
1. Le vManage agissant en tant qu'autorité de certification (CA) pour les routeurs cloud
WAN Edge.
2. vManage distribue le certificat racine Cisco au vBond et vSmart afin qu'ils valident
l'identité du cloud WAN Edge.
3. Une fois que les routeurs WAN Edge sont authentifiés via OTP, l'autorité de
certification vManage leur délivre des certificats signés Viptela qui sont ensuite utilisés
pour l'authentification.

Figure 26: vManage racine CA pour les routeurs cloud WAN Edge[23]
E- CERTIFICATS
Les schémas suivants illustrent la façon dont les différents périphériques s'authentifient les uns
les autres à l'aide de certificats Symantec/Digicert ou Cisco. De façon générale :
- Les contrôleurs et les périphériques WAN Edge agissent comme des clients pour établir
des connexions avec le vBond, qui agit comme un serveur
- Les contrôleurs vManage agissent comme des clients pour établir des connexions avec
le vSmart, qui agit comme un serveur
- Les contrôleurs vSmart agissent comme des clients pour établir des connexions avec
d'autres contrôleurs vSmart et celui avec l'adresse IP publique la plus élevée agit
comme un serveur
- Les périphériques WAN Edge agissent comme des clients pour établir des connexions
avec les contrôleurs vManage et vSmart, qui agissent comme des serveurs

Figure 27: Authentification et autorisation du dispositif SD-WAN[23]
Pour plus d'informations sur le déploiement de certificats pour la solution Cisco SD-WAN,
reportez-vous au Guide de déploiement des certificats Cisco SD-WAN
2.1.5.3- PLAN D'ORCHESTRATION
A- AMENER LE WAN EDGE DANS L’OVERLAY NETWORK

Afin de rejoindre le réseau de superposition ou overlay network, un routeur WAN Edge doit
établir une connexion sécurisée au vManage afin qu'il puisse recevoir un fichier de
configuration, et il doit établir une connexion sécurisée avec le contrôleur vSmart afin qu'il
puisse participer à la superposition réseau. La découverte de vManage et vSmart se produit
automatiquement et se fait en établissant d'abord une connexion sécurisée à l'orchestrateur
vBond.
La figure suivante montre la séquence d'événements qui se produit lors de l'introduction du
routeur WAN Edge dans le réseau de superposition.

Figure 28: Introduction d'un WAN Edge dans l’overlay network [23]
1. Grâce à une configuration d'amorçage (manuelle ou automatique), le routeur WAN

Edge tente d'abord de s'authentifier auprès de l'orchestrateur vBond via une connexion
DTLS chiffrée. Une fois authentifié, l'orchestrateur vBond envoie au routeur WAN Edge
les adresses IP du système de gestion de réseau du vManage et des contrôleurs vSmart.
L'orchestrateur vBond informe également les contrôleurs vSmart et vManage du nouveau
routeur WAN Edge souhaitant rejoindre le domaine.
2. Le routeur WAN Edge commence à établir des sessions DTLS ou TLS sécurisées avec
vManage et les contrôleurs vSmart et arrête la session avec l'orchestrateur vBond. Une fois
que le routeur WAN Edge s'authentifie auprès de vManage NMS, le vManage envoie la
configuration au routeur WAN Edge si disponible.
3. Le routeur WAN Edge tente d'établir des connexions DTLS / TLS avec les contrôleurs
vSmart sur chaque liaison de transport. Lorsqu'il s'authentifie auprès d'un contrôleur
vSmart, il établit une session OMP puis apprend les itinéraires, y compris les préfixes, les
clés de chiffrement et les politiques.
4. Le routeur WAN Edge tente d'établir des sessions BFD sur des TLOC distants sur
chaque transport à l'aide d'IPsec.
B- INTÉGRATION DU ROUTEUR WAN EDGE A L’ARCHITECTURE
Il existe plusieurs façons de faire fonctionner un routeur WAN Edge sur le réseau. Une façon
est la méthode manuelle, où l’on peut accéder à la console de l'appareil et configurer quelques
paramètres de base ou en utilisant une méthode d'approvisionnement automatisée, comme Zero-

Touch Provisioning (ZTP) ou Plug-and-Play (PnP), où on peut brancher le routeur WAN Edge
au réseau et le mettre sous tension et il sera automatiquement provisionné. La méthode manuelle
et automatisée sont brièvement décrites ci-dessous.
- MÉTHODE MANUELLE
La méthode manuelle beaucoup plus accessible dans le cadre de notre déploiement peut être
décrite ainsi qu’il suit. L'idée est de configurer la connectivité réseau minimale et les
informations d'identification minimales avec l'adresse IP ou le nom d'hôte de vBond
orchestrateur. Le routeur WAN Edge tente de se connecter à l'orchestrateur vBond et de
découvrir les autres contrôleurs réseau à partir de là. Afin de pouvoir afficher le routeur WAN
Edge avec succès au niveau du vManage, il y a quelques éléments qui doivent être configurés
sur le routeur WAN Edge :
● Configurer une adresse IP et une adresse de passerelle sur une interface connectée au
réseau de transport, ou bien configurer le protocole DHCP afin d'obtenir
dynamiquement une adresse IP et une adresse de passerelle. Le WAN Edge doit
pouvoir atteindre le vBond via le réseau.
● Configurer l'adresse IP du vBond.
● Configurer le nom de l'organisation, l'adresse IP du système et l'ID de site.
Facultativement, configurez le nom d'hôte.
Cette méthode est beaucoup plus détaillée dans l’annexe 2 de ce document.
- PROVISIONING AUTOMATISÉ DES APPAREILS (ZTP OU PNP)

Le provisionnement automatisé des périphériques vEdge est appelé Zero-Touch Provisioning
(ZTP), il est appelé Plug-and-Play (PnP). Les processus sont très similaires, mais deux services
différents sont impliqués.
La procédure d'approvisionnement automatisé démarre lorsque le routeur WAN Edge est mis
sous tension pour la première fois. Le routeur vEdge tente de se connecter à un serveur ZTP
avec le nom d'hôte ztp.viptela.com, où il obtient ses informations d'orchestrateur vBond. Une
fois les informations de vBond orchestrateur obtenues, il peut ensuite établir des connexions
avec les contrôleurs vManage et vSmart afin d'obtenir sa configuration complète et rejoindre le
réseau de superposition.

Figure 29: ZtP et PnP [23]
2.1.5.4- PLAN DE DONNÉES

Cette section examine la sécurité du plan de données Cisco SD-WAN est établi et se concentre
sur les composants qui aident à l'activer.
A- ROUTAGE SD-WAN
- « UNDERLAY VS OVERLAY ROUTING »

Le réseau Cisco SD-WAN est divisé en deux parties distinctes : le réseau de sous-couche et de
superposition. Le réseau sous-jacent est l'infrastructure réseau physique qui connecte les
périphériques du réseau tels que les routeurs et les commutateurs et achemine le trafic entre les
périphériques à l'aide des mécanismes de routage traditionnels. Dans le réseau SD-WAN, les
ports réseau qui se connectent au réseau sous-jacent font partie du VPN 0, le VPN de transport.
L'obtention de la connectivité à la passerelle du fournisseur de services dans le réseau de
transport implique généralement la configuration d'une passerelle par défaut statique (la plus
courante) ou la configuration d'un protocole de routage dynamique, tel que BGP ou OSPF.
Les tunnels IPsec qui traversent de site en site à l'aide du réseau de sous-couches aident à former
le réseau de superposition SD-WAN. Le protocole OMP, un protocole TCP similaire à BGP,
fournit le routage du réseau de superposition. Le protocole s'exécute entre les contrôleurs
vSmart et les routeurs WAN Edge où les informations du plan de contrôle sont échangées via
des connexions DTLS ou TLS sécurisées.

Figure 30: Underlay vs Overlay Routing[23]
- OMP
OMP s'exécute entre les routeurs WAN Edge et les contrôleurs vSmart et également en tant que
maillage complet entre les contrôleurs vSmart. Lorsque les connexions de contrôle DTLS / TLS
sont établies, OMP est automatiquement activé. L'homologation OMP est établie à l'aide des
adresses IP du système et une seule session d'homologation est établie entre un périphérique
WAN Edge et un contrôleur vSmart même s'il existe plusieurs connexions DTLS / TLS. OMP
échange des préfixes de route, des routes de prochain saut, des clés de chiffrement et des
informations de politique de routage et sécurité.
OMP annonce trois types de routes des routeurs WAN aux contrôleurs vSmart :
● Les routes OMP : qui sont des préfixes qui sont appris à partir du site local ou du côté
service d'un routeur WAN Edge. Les préfixes sont originaires comme des routes
statiques ou connectées, ou à partir du protocole OSPF, BGP ou EIGRP, et redistribués
dans OMP afin qu'ils puissent être transportés à travers le réseau de superposition. Un
itinéraire OMP n'est installé dans la table de transfert que si le TLOC vers lequel il
pointe est actif.
● Les routes TLOC : annoncent les TLOC connectés aux transports WAN, ainsi qu'un
ensemble supplémentaire d'attributs tels que les adresses IP privées et publiques TLOC,
l'opérateur, la préférence, l'ID de site, la balise, le poids et les informations de clé de
chiffrement.
● Les routes de service représentent des services (pare-feu, IPS, optimisation
d'application, etc.) qui sont connectés au réseau de site local WAN Edge et sont

disponibles pour d'autres sites pour une utilisation avec l'insertion de service. De plus,
ces routes incluent l'IP du système d'origine, le TLOC et les ID VPN.
Figure 31: Opération OMP [23]
Par défaut, OMP annonce uniquement la ou les meilleures routes dans le cas de chemins à coût
égal. Et les routes statiques et OSPF (intra-zone et interzone) sont automatiquement distribués
des VPN côté service vers OMP. Tous les autres types de routes (y compris les routes externes
OSPF) doivent être explicitement configuré.
B- CONFIDENTIALITÉ ET CRYPTAGE DU PLAN DE DONNÉES
Les routeurs WAN Edge sécurisent le trafic de données échangé entre eux à l'aide d'IPsec avec
des clés de chiffrement qui chiffrent et déchiffrent les données. Dans les environnements IPsec
traditionnels, IKE est utilisé pour faciliter l'échange de clés entre pairs. Cela crée des clés par
paire, obligeant chaque périphérique à gérer n^2 échanges de clés et n-1 clés différentes dans
un environnement à maillage complet. Pour une mise à l'échelle plus efficace dans le réseau
Cisco SD-WAN, aucune IKE n'est implémentée car l'identité a déjà été établie entre les routeurs
WAN Edge et les contrôleurs. Le plan de contrôle, déjà authentifié, chiffré et inviolable à l'aide
de DTLS ou TLS, est utilisé pour communiquer des clés symétriques AES-256. Chaque routeur
WAN Edge génère une clé AES par TLOC et transmet ces informations au contrôleur vSmart
dans des paquets de route OMP. La durée de vie de chaque clé est de 24 heures par défaut. Une
nouvelle clé est générée toutes les 12 heures, envoyée aux contrôleurs vSmart puis distribuée
aux autres routeurs WAN Edge, ce qui signifie que deux clés sont présentes à tout moment.

Figure 32: Cryptage du plan de données[23]
Pour crypter le trafic du plan de données, une version modifiée de ESP est utilisée pour protéger
la charge utile des paquets de données. L'algorithme de chiffrement est AES-256 GCM ou AES-
256 CBC. L'algorithme d'authentification, qui vérifie l'intégrité et l'authenticité des données,
est configurable et est inclus dans les propriétés TLOC qui sont échangées avec les contrôleurs
vSmart. Par défaut, AH-SHA1 HMAC et ESP HMAC-SHA1 sont tous deux configurés.
Lorsque plusieurs types d'authentification sont configurés, la méthode la plus forte entre les
deux points est choisie (AH-SHA1 HMAC).
2.1.5.5- PLAN DE MANAGEMENT

VManage est l'interface graphique centralisée Cisco SD-WAN qui permet de gérer le réseau
SD-WAN de bout en bout à partir d'un seul tableau de bord
Une fois connecté à vManage :
- Il indiquera le nombre de vSmart, vEdge, vManage et vBond dans le réseau
- Il montrera la connexion de contrôle mentionnée dans la configuration du contrôle.
- Il montrera également la connectivité complète entre les sites, la connectivité partielle et
aucune connectivité (si un vEdge est en panne).
- Il montrera également l'inventaire vEdge, pour lequel vManage est sous licence.
- Il affichera les statistiques de santé pour les vEdge (Normal, Avertissement et Erreur)

Figure 33: Tableau de bord SD-WAN[23]
- SECURE SHELL (SSH)

SSH fournit un canal sécurisé et crypté sur un réseau non sécurisé. Il est généralement utilisé
pour se connecter à une machine distante pour exécuter des commandes, mais il peut également
être utilisé dans le transfert de fichiers (SFTP) et la copie sécurisée (SCP). VManage peut
utiliser SCP pour installer des certificats signés sur les contrôleurs si des connexions DTLS /
TLS ne sont pas encore établies entre eux, ce qui sera fait dans l’annexe 3. SSH utilise le port
de destination TCP 22.
2.1.3 OPTIONS DE DÉPLOIEMENT CISCO SD -WAN
2.1.3.1- DÉPLOIEMENT DES CONTRÔLEURS
Dans tout déploiement SD-WAN, les contrôleurs sont d'abord déployés et configurés,
suivis des sites principaux du concentrateur ou du centre de données et enfin des sites
distants. Au fur et à mesure du déploiement de chaque site, le plan de contrôle est établi en
premier, suivi automatiquement par le plan de données. Il est recommandé d'utiliser des
sites concentrateurs pour router entre les sites SD-WAN et non SD-WAN lors de la
migration des sites vers SD-WAN.

Figure 34: Séquence Déploiement SD-WAN [24]

Les contrôleurs SD-WAN peuvent être hébergés dans le cloud ou hébergés sur site. La figure
35 montre un déploiement d'entreprise étendu hébergé dans le cloud.
3. Déploiement cloud : Les contrôleurs SD-WAN hébergés dans le cloud sont hébergés par
Cisco sur un service clou AWS ou Microsoft Azure.
4. Déploiement par Cloud MSP : Dans un cloud Managed Service Provider (MSP) ou
hébergé par un partenaire. Ceci est hébergé dans le cloud privé ou peut être hébergé dans
le cloud public et déployé dans AWS ou Azure. Le MSP ou le partenaire est généralement
responsable de l'approvisionnement des contrôleurs et responsable des sauvegardes et de
la reprise après sinistre.
5. Déploiement sur site : Dans le modèle sur site, les composants SD-WAN sont installés
sur du matériel virtualisé. vManage, orchestrateur vBond et le contrôleur vSmart peuvent
tous être déployés sur des machines virtuelles. Il est recommandé les composants SD-
WAN sont protégés par un pare-feu de centre de données.
Figure 35: Flexibilité de déploiement des contrôleurs[24]

2.1.3.2- DÉPLOIEMENT WAN EDGE
Les routeurs WAN Edge sont déployés sur les sites distants, les campus et les centres de
données et sont responsables du routage du trafic de données vers et depuis les sites à travers le
réseau de superposition SD-WAN.
A. ARCHITECTURE GÉNÉRALE DE DÉPLOIEMENT WAN EDGE
Lors du déploiement d'un routeur WAN Edge pour un site, la plate-forme doit être choisie et
dimensionnée correctement pour le débit de trafic et le nombre de tunnels pris en charge, etc. Il
est recommandé d'ajouter un deuxième routeur WAN Edge pour la redondance. Lors du
déploiement, les routeurs WAN Edge sont généralement connectés à tous les transports pour
une redondance appropriée.
La figure 36 illustre un site à routeur unique et à double routeur, chaque routeur WAN Edge se
connectant aux deux transports.
Figure 36: Routeur Edge simple ou double WAN Edge [24]
Les tunnels encapsulés IPsec chiffrent le trafic de données vers d'autres emplacements de
routeur vEdge, et des sessions BFD sont également formées sur ces tunnels. Le trafic utilisateur
provenant des VPN de service est dirigé vers les tunnels. Lorsqu'un transport ou une liaison
vers un transport tombe en panne, la session BFD expire et les tunnels sont arrêtés des deux
côtés une fois que les routeurs vEdge détectent la condition. Les liaisons de transport restantes
peuvent être utilisées pour le trafic. Dans le site à double routeur, si l'un des routeurs tombe en
panne, le routeur restant qui a toujours des connexions aux deux transports prend en charge le
routage pour le site.
B. ASPECT TRANSPORT
- RÉSEAU SOUS-JACENT

La sous-couche comprend le VPN de transport (VPN 0) et les connexions à chaque transport.

Pour plus de simplicité, il est recommandé d'utiliser le routage statique dans VPN 0 autant que
possible par opposition au routage dynamique, cependant, le routage dynamique dans VPN 0
peut être nécessaire pour certains cas spécifiques.
En règle générale, tout ce qui est nécessaire pour le routage dans VPN 0 est une route par défaut
spécifiant l'adresse IP du saut suivant pour chaque transport. Son objectif est de créer des
tunnels de données encapsulés par IPsec vers d'autres routeurs Edge WAN et de construire des
tunnels DTLS/TLS du plan de contrôle vers les contrôleurs SD-WAN. Plusieurs routes par
défaut peuvent exister dans le VPN 0 car la route choisie dépend de l'adresse IP source du
tunnel, qui doit se trouver dans le même sous-réseau que l'adresse IP du prochain saut de la
route par défaut.
- CHOIX DE CONNEXION
Figure 37: Routage [24]

Tout ce qui est nécessaire pour établir le réseau sous-jacent est la connectivité IP du routeur
WAN Edge au fournisseur de services de transport, qui a son tour est responsable de la
propagation des informations de route du sous-réseau du tunnel vers les sites SD-WAN distants.
La connexion au transport peut se faire de plusieurs manières :
Les choix de connexion illustrés sur la figure 38 courants sont les suivants :
● (A) Pour MPLS, un routeur vEdge peut remplacer complètement un routeur Customer
Edge (CE) afin qu'il y ait une connectivité directe entre le routeur WAN Edge et le
routeur Provider Edge (PE) dans le transport MPLS.

Pour le transport Internet, un routeur vEdge est connecté directement au transport

Internet sans pare-feu. Ce type de connexion est communément observé dans les sites
de succursale.
● (B) Pour MPLS, un routeur vEdge peut être placé derrière un routeur CE qui se
connecte au transport MPLS. Ceci est utilisé lorsque le routeur CE doit rester en place
pour des raisons telles que :
◦ Le routeur CE fournit une connectivité réseau ou un service réseau avec une
fonctionnalité activée non prise en charge par le routeur SD-WAN.
◦ Le routeur CE fournit un accès direct aux sites SD-WAN non migrés lors d'un
déploiement SD-WAN.
Pour le transport Internet, le routeur WAN Edge peut être placé derrière un pare-feu si
cela est requis par la politique de sécurité de l'entreprise. Ce type de connexion est
couramment utilisé dans les sites de centres de données.
Figure 38: Connexions MPLS et Internet avec les WAN Edge [24]
● (C) Pour les transports MPLS et Internet, un routeur WAN Edge peut être connecté
directement au commutateur LAN pour la connectivité de transport lorsqu'un CE ou un
pare-feu est requis mais aucune connexion directe n'est disponible pour le CE ou le
pare-feu pour le routeur SD-WAN.
- CHOIX DE TRANSPORT
Il existe de nombreux choix de transport et différentes combinaisons de transports qui peuvent
être utilisés. Les transports sont déployés dans un état actif/actif, et la façon dont on les utilise
est extrêmement flexible. Une combinaison de transport très courante est MPLS et Internet.
MPLS peut être utilisé pour le trafic stratégique, tandis qu'Internet peut être utilisé pour le trafic
en vrac et d'autres données.

Le LTE est fréquemment utilisé comme choix de transport et peut être déployé en mode actif.
Ce qui suit montre un petit échantillon de différentes options de transport.
Figure 39: Options de transport pour WAN Edge [24]
2.1.4.2 MODÈLES DE CONFIGURATION
Les configurations et les politiques sont appliquées aux routeurs WAN Edge et aux contrôleurs
vSmart qui permettent au trafic de circuler entre le centre de données et la succursale ou entre
les succursales. Un administrateur peut activer des configurations et des via l'interface de ligne
de commande (CLI) à l'aide de la console ou de SSH sur le périphérique WAN Edge, ou à
distance via l'interface graphique vManage.
A- MODÈLES DE PÉRIPHÉRIQUES ET DE FONCTIONNALITÉS
Les modèles de périphériques (Device Templates) sont spécifiques à un seul type de modèle
WAN Edge, mais il est possible de créer plusieurs modèles de périphérique du même type
d’équipement en raison de leur emplacement et de leur fonction sur le réseau. Chaque
modèle de périphérique fait référence à une série de modèles de fonctionnalités qui
constituent la configuration complète de l'appareil. Une configuration de modèle de
périphérique ne peut pas être partagée entre les modèles WAN Edge, mais un modèle de
fonctionnalité peut s'étendre sur plusieurs types de modèle et être utilisé par différents
modèles de périphérique.
La figure 40 illustre les composants du modèle de périphérique. Le modèle de périphérique
est composé de modèles de fonctionnalités (Feature Templates ) regroupés en plusieurs
sections

Figure 40: Modèles de périphériques et de fonctionnalités[23]
B- UTILITÉ
Pour configurer un périphérique ou un contrôleur WAN Edge sur le réseau à l'aide de l'interface
graphique vManage, un administrateur applique un modèle de périphérique à un routeur WAN
Edge ou à plusieurs routeurs WAN Edge. Ces modèles peuvent être basés sur CLI ou basés sur
des fonctionnalités. Bien que ça soit possible de créer des modèles basés sur CLI, il est
recommandé d’utiliser des modèles basés sur des fonctionnalités car ils sont modulaires, plus
évolutifs et moins sujets aux erreurs.
Lors de la conception de modèles de configuration, il est utile de réfléchir à la façon dont les
opérations peuvent interagir avec les modèles au quotidien. Il peut être utile d'utiliser des
variables pour les noms d'interface afin que les interfaces puissent être déplacées à des fins de
dépannage, sans avoir à créer de nouveaux modèles de fonctionnalités pour l'accomplir (ou
interrompre d'autres appareils en utilisant le même modèle de fonctionnalités).
2.2. GÉNÉRALITÉS SUR LA MÉTHODOLOGIE DE DÉPLOIEMENT
2.2.1- MÉTHODOLOGIE DE DÉPLOIEMENT DES WAN-EDGE

2.2.2.1- CONDITIONS PRÉALABLES

On aura besoin d'autorisations pour créer un compte virtuel dans le portail du logiciel Cisco.
On aura également besoin d'un accès pour créer des profils de contrôleur et ajouter des
dispositifs logiciels à un compte virtuel. Ces différents prérequis vont être détaillés en 2.6.1 lors
de mise en œuvre du compte virtuel Cisco qui nous permettra d’obtenir la liste blanche des
vEdges encore appelé fichier serial.
Figure 41: Condition préalables WAN Edge
2.2.2.2- MÉTHODOLOGIE WAN EDGE

Tout comme les contrôleurs du SD-WAN, nous avons choisi une méthode de déploiement
manuelle pour les sites de l’entreprise, qui auront pour CE les vEdges de CISCO.
Il est question de configurer le dispositif avec une configuration minimale nécessaire pour que
le dispositif atteigne le contrôleur vBond. Après authentification et autorisation du dispositif
par l'orchestrateur vBond, puis par les contrôleurs vManage et vSmart, le dispositif WAN Edge
établit une connexion de contrôle permanente avec les contrôleurs vManage et vSmart.
Les modèles de configuration évoqués en 2.1.4.2 du vManage peuvent être utilisés pour
configurer entièrement le périphérique WAN Edge. En établissant une connexion de contrôle
avec vManage, le modèle de périphérique configuré est poussé vers le périphérique WAN Edge.
Notez qu'il n'est pas nécessaire de disposer d'un modèle de périphérique dans vManage pour les
périphériques WAN Edge afin d'établir des connexions de contrôle avec les contrôleurs, tant

que la configuration minimale du CLI est configurée. Le modèle de périphérique peut être joint
ultérieurement. Pour que le périphérique WAN Edge fonctionne correctement, il doit avoir une
configuration de base minimale.
- Propriétés du système avec les informations System-ip, site-id, organization-name, et adresse
ip du vBond.
- Interface VPN de transport (VPN 0) avec adresse IP, configuration des routes et des tunnels.
- En option, un nom d'hôte et des informations sur le VPN 512 (adresse IP de l'interface de
management et protocole de routage ou route par défaut) peuvent être fournis.
Par la suite les certificats d’entreprise doivent importes du vManage vers les vEdge et les
numéros de séries compatibles associés
Ces étapes peuvent être résumées dans la figure ci-dessous :
Figure 42: Méthodologie déploiement vEdge
L’implémentation concrète de cette méthodologie en environnement de simulation est

disponible dans l’annexe 2.
2.2.2- DÉPLOIEMENT DE CONTRÔLEUR SUR SITE CAMTEL
Dans ce type de déploiement de contrôleur, les contrôleurs sont déployés sur site dans un centre
de données ou un cloud privé, où l'organisation informatique de l'entreprise est généralement

responsable de l'approvisionnement des contrôleurs et responsable des sauvegardes et de la

reprise après sinistre. Certains clients, tels que les institutions financières ou les entités
gouvernementales, peuvent choisir d'exécuter des déploiements sur site principalement pour
des raisons de conformité à la sécurité. CAMTEL dans sa posture d’operateur pourra déployer
ces contrôleurs sur site d’entreprise, en l’occurrence une salle serveur dédiée et rattachée à son
réseau d’entreprise ou alors tout simplement un déploiement dans le segment virtualisation
réseau prévu dans son nouveau DATACENTER
La figure 41 présente deux exemples de déploiement sur site. Dans le déploiement A, WAN
Edge 1 peut se connecter aux contrôleurs du centre de données à partir des deux transports.
Dans le déploiement B, les contrôleurs sont accessibles uniquement via le MPLS privé. Un
vBond supplémentaire est déployé sur Internet et agit comme un serveur STUN pour les
périphériques WAN Edge avec accès Internet et les redirige vers les adresses IP du contrôleur
privé. WAN Edge 1 peut toujours établir des connexions IPsec de plan de données sur le
transport Internet car les informations TLOC sont toujours reçues sur OMP à partir du transport
MPLS.
Figure 43: Déploiement et établissement du plan de données [23]
2.2.1.1 LE VMANAGE
Comme précisé plus haut, les contrôleurs sont déployés sur site CAMTEL, par ailleurs pour
notre simulation nous avons choisi une méthode de déploiement manuelle, en premier lieu le
vManage va suivre une procédure standard de déploiement qui est définie dans la figure 42.

Figure 44: Méthode de déploiement vManage
2.2.1.2- LE VSMART
La méthode de déploiement est définie dans la figure 43, Pour que le contrôleur vSmart
fonctionne correctement, il doit avoir une configuration de base minimale,
ip du vBond.
- Interface VPN de management (VPN 512) avec adresse IP.
Ensuite les certificats doivent être associes au vManage pour une communication entre
contrôleurs.

Figure 45: Méthode de déploiement vSmart
2.2.1.3 LE VBOND
La méthode de déploiement est définie dans la figure 44, Pour que le contrôleur vBond
fonctionne correctement, il doit avoir une configuration de base minimale,
ip du vBond.
- Interface VPN de management (VPN 512) avec adresse IP.
Ensuite les certificats doivent être associés au vManage pour une communication entre
contrôleurs.

Figure 46: Méthode de déploiement vBond
2.2.3- MÉTHODOLOGIE D’INTERCONNEXION DES SITES VPN SERVICE

PAR OSPF
2.2.4.1- CONDITIONS PRÉALABLES
Dans un premier temps les modèles de configuration énoncés en 2.1.4.2 doivent être
implémentés. D’abord on aura les modèles de périphériques qu’on va créer et associer aux
équipements qui distribueront les VPN de service que l’on veut implémenter, ensuite on aura 2
modèles de fonctionnalités à mettre en œuvre, l’un concernant la création des VPN et l’autre
concernant la création des interfaces associés aux différents VPN à interconnecter.
2.2.4.2- MODÈLE DE FONCTIONNALITÉ OSPF
OSPF peut être utilisé pour le routage côté service, afin d'assurer l'accessibilité aux réseaux sur
le site local, et il peut être utilisé pour le routage côté transport, afin de permettre la
communication entre le routeur vEdge et d'autres dispositifs Viptela lorsque le routeur n'est pas
directement connecté au nuage WAN.

Figure 47: Exemple de déploiement OSPF
La méthodologie de configuration coté VPN service (VPN 1-511) que nous allons utiliser pour
déployer OSPF avec un modèle sera celle de la figure 48, au préalable on supposera que les
vEdges ont été bascules du mode CLI vers le mode vManage, et que les modèles de
configuration nécessaires sont implémentés (VPN, Interfaces, Routes par défaut)
Figure 48: Modèle de configuration OSPF cote VPN de service
2.3. CHOIX DE L’OUTILS DE SIMULATION
Pour réaliser notre modèle de solution, nous avons utilisé un logiciel de simulation réseau
appelé EVE-NG. Cette plateforme est prête pour les exigences du monde informatique et des
télécommunications d'aujourd'hui et permet aux entreprises, aux fournisseurs/centres de

formation en ligne, aux individus et aux collaborateurs de groupe de créer une preuve virtuelle
de concepts, de solutions et d'environnements de formation.
Dans notre cas ce simulateur va nous permettre de créer une architecture réseau virtualisée
complète qui va intégrer les différents équipements du constructeur Cisco nécessaires à la mise
en œuvre de la solution.
Figure 49: Logo EVE-NG
Pour installer le simulateur EVE-NG il faudra au préalable respecter les contraintes matérielles
qui nous allons énoncer plus tard, il s’agit de la configuration minimale au niveau matériel et
logiciel que doit respecter notre ordinateur afin d’installer le simulateur en tout sécurité.
Par la suite il faut se rendre sur le site https://www.eve-ng.net/ et y télécharger le guide pour la
version « EVE-NG Community » . Ce guide contient les étapes d’installation nécessaires à la
mise en place du simulateur et l’importation de diffèrent équipements qui sont listés en 2.5.2 et
seront utilisés pour la simulation. La figure ci-dessous montre la page d’accueil du simulateur.
Figure 50: Page d’accueil EVE-NG Community

2.4. ANALYSE DES BESOINS ET CONTRAINTES

EVE-NG est disponible au format de fichier OVF ou ISO. Le format OVF est une norme
ouverte pour le conditionnement et la distribution d'appareils virtuels. Il peut être utilisé pour
déployer une VM dans des hyperviseurs tels que VMware Workstation, Player et ESXi.
2.4.1. CONTRAINTES MATÉRIELLES

2.4.1.1 CONFIGURATION MINIMALE REQUISE POUR L'ORDINATEUR
PORTABLE / PC DE BUREAU
Prérequis :
- Processeur : INTEL supportant la technologie de virtualisation “Intel® VT-x
/EPT“
- Système d’exploitation : Windows 7,8,10 ou Linux Desktop
- VMware Workstation 12.5 ou plus
- VMware Player 12.5 ou plus
Tableau 1: Prérequis Matériel Minimal Pc/Laptop et EVE-NG
PC/Laptop prérequis matériels

Processeur Intel i5/i7 (4 Processeurs Logiques), Virtualisation
Intel activée dans le BIOS
Mémoire Vive 8 Gb
Espace Disque 40 Gb
Réseau LAN/WAN
Machine EVE-NG Prérequis
Processeur 4/1 (Nombre de processeurs/Nombre de cœurs par
processeurs). Fonctionnalité Intel VT-x/EPT active
Mémoire Vive 6 Gb ou plus
Espace Disque 40 Gb ou plus
Réseau VMware NAT ou “Bridged Network Adapter”
2.4.2 PLATEFORMES DE VIRTUALISATION SUPPORTÉES

Pour implémenter des architectures dans la machine virtuelle EVE-NG plusieurs plateformes
de virtualisation sont supportées par défaut :
- VMware Workstation 12.5 ou plus

- VMware Player 12.5 ou plus

- VMware ESXi 6.0 ou plus
- Ubuntu Server 16.04 LTS
- Plateforme Google Cloud
2.5- BILAN
Rendu au terme de ce chapitre, nous avons défini de façon théorique et conceptuelle

les éléments essentiels de la solution SD-WAN de Cisco, en commençant par une analyse des
concepts, présentation des autres fournisseurs, nous avons également présenté les options de
déploiements de la technologie pour l’entreprise et conçu les différentes méthodologies
inhérentes aux aspects opérationnels une fois le SD-WAN Cisco déployé. Nous avons présenté
l’outil de simulation choisi et terminé avec une analyse des besoins et contraintes matérielles
ainsi que logicielles lors de la simulation.

CHAPITRE 3 : RESULTATS ET COMMENTAIRES
RÉSULTATS ET COMMENTAIRES
N ous présenterons les résultats obtenus après la conception et la mise en place de la

solution Cisco SD-WAN. Les paragraphes qui suivent sont dédiés à la présentation de
l’implémentation de cette solution et aux commentaires relatifs aux résultats obtenus.

3.1- RAPPEL DES OBJECTIFS

L’objectif principal ici est de mettre en œuvre la solution Cisco SD-WAN pour le déploiements
des sites du réseau d’entreprise de CAMTEL. La simulation devra répondre à un certain nombre
de critères dont le plus important sera la facilite de compréhension et de reproduction afin d’être
exploité efficacement lors de l’implémentation de la solution en environnement réel par les
équipes de l’entreprise.
3.2- ARCHITECTURE STRUCTURELLE DE LA SIMULATION
Nous présentons ici la structure générale inhérente à notre architecture et propre aux différents
modules que nous avons implémentés. Il s’agit d’une architecture réseau qui va partir de
l’existant et intégrer les équipements de la solution SD-WAN Cisco. L’objectif est d’avoir un
rendu de base qui se rapproche au maximum de ce qui est existant dans l’environnement réel
de CAMTEL, tout cela dans les limites de la configuration de notre machine afin d’avoir une
solution pouvant être reproduite par les équipes de l’entreprise au besoin.
3.2.1- CHALLENGES À RELEVER

Concevoir une architecture réseau WAN orientée logiciel respectant la méthodologie
précédemment énoncée est un travail qui revêt des défis intéressants. Les principaux défis à
relever sont les suivants :
- Rapidité d’accès à l’interface web de configuration vManage
- Rapidité de déploiement, configuration et maintenance des sites du réseau d’entreprise
- Permettre aux administrateurs réseaux de diminuer aux maximums les interventions
physiques sur les équipements
- Limiter les erreurs humaines
- Simuler sur PC une architecture réseau virtuelle réaliste et contrôlée par logiciel un PC
3.2.2- MISE EN ŒUVRE DE LA SIMULATION

3.2.2.1- ELÉMENTS MATÉRIELS ET LOGICIELS
Dans cette section nous allons décrire l’environnement matériel et logiciels que nous avons
utilisé pour réaliser la simulation. Les différentes versions des équipements et contrôleurs
utilises, vEdge et autres équipements réseaux.
Configuration Matérielle de la machine hôte
- Processeur : INTEL core I5 7eme génération
- Mémoire Vive : 24 Gigas
- Espace Disque 256 Gigas

- Réseau : LAN
Configuration Logicielle
- Système d’exploitation : Windows 10 PRO 64 bits
- VMware Workstation 15.5.2
- Machine Virtuelle EVE-NG « Community » disponible sur le site EVE ; https://www.eve-
ng.net/index.php/download/
Configuration Matérielle EVE-NG
Cette configuration s’ajuste dans le logiciel VMWare une fois la machine virtuelle EVE
installée.
- Processeur : 4/1 (Nombre de processeurs/Nombre de cœurs par processeurs).
Fonctionnalité Intel VT-x/EPT active
- Mémoire Vive : 9 Gigas
- Espace Disque : 100 Gigas
- Réseau : VMware NAT
Versions Equipements SD-WAN Cisco
- vBond, vManage, vSmart, vEdge: 19.3.0
Versions Equipements Réseau
- Routeur CISCO C3725 version c3560e-universalk9-mz.150-1.SE
- Switch CISCO compatible avec EVE-NG: L2-ADVENTERPRISE-M-15.1-
20140814.bin
- Carte réseau pour le Management “Cloud Management”
- 4 VPCS
Dans notre simulation nous allons créer d’abord un nuage pour le transport et ensuite y greffer
les sites de l’entreprise qui seront en communication, ils seront au nombre de 3, un site qui va
contenir les contrôleurs et 2 sites clients.
3.2.2.2- CHOIX DU TRANSPORT
L’entreprise utilise par défaut de nuage MPLS pour interconnecter ses différents sites, la
technologie MPLS a été présentée en détail en 1.1.14, et sa fiabilité ainsi que sa flexibilité en
font le protocole de transport privilégie pour le réseau d’entreprise. Bien que le VPN internet
soit également très utilisé il ne revêt pas une importance fondamentale dans le déploiement de
l’architecture.
En bref notre architecture de transport va s’appuyer uniquement sur un nuage MPLS que nous
allons définir en 7 routeurs Cisco version C3725, 4 Routeur Provider Edge et 3 routeurs
Providers. Elle va se présenter ainsi qu’il suit :

Figure 51:Architecture Transport MPLS
Les configurations techniques inhérentes à cette seront détaillées en annexe 2. L’élément a

précisé est que une fois le nuage MPLS fonctionnel il suffira de créer un VRF d’interconnexion
qui sera le tunnel permettant de transporter les paquets du réseau d’entreprise à travers le nuage
Les équipements utilises devront remplir des rôles bien précis :
• PE-SD-WAN : Routeur PE du site abritant les contrôleurs
• PE1-3 : Routeurs PE abritant les sites du réseau d’entreprise à déployer
• P1-3 : Routeurs P du Cœur du nuage MPLS
3.2.2.3- CRÉATION DES SITES DISTANTS
Pour mettre en œuvre nos sites clients nous aurons besoin des vEdge qui seront les CE de
chaque site du réseau d’entreprise. Dans le cadre de la mise en œuvre de notre simulation
nous aurons besoin de 2 sites initiaux. Ces 2 sites vont abriter 2 VPN de service que nous
allons distinguer dans notre architecture. Le VPN 1 (en rouge) qui sera le VPN de service
LAN., le VPN 2 (en vert) qui sera le VPN de service VOIP. Cela va être présenté tel que dans
la figure suivante :

Figure 52: Création des sites distants
3.2.2.4- INTÉGRATION CISCO SD-WAN

Par la suite il est question de mettre en place les contrôleurs vManage, vSmart, vBond. Ils seront
membre d’un site qui appartient au réseau à contrôler, en l’occurrence le réseau d’entreprise.
Pour respecter les aspects technologies évoqués en 2.1.2 concernant le plan de contrôle et le
plan de management, les différents ports de chaque contrôleur appartenant au VPN 0 de
transport et au VPN 512 de management seront respectivement dans le même réseau.
L’architecture est telle que présentée dans la figure 53 :
Figure 53: Création du site des contrôleurs

Il est à noter que le VPN 512 de management est celui nous donne accès à l’interface web du
vManage qui permet de mettre en œuvre les aspects opérationnels du SD-WAN. Pour accéder
à cet équipement nous utilisons notre machine hôte et un mécanisme de carte réseau virtuelle.
En effet le logiciel VMware permet de créer des cartes réseaux virtuelles, ces cartes servent
d’interface entre la machine hôte et la machine virtuelle, permettant ainsi de communiquer
directement avec les équipements de notre simulation. Comme la figure 54 nous le montre il
existe plusieurs cartes réseaux virtuelles utilisables. Dans notre cas nous avons choisi celle
« Management (Cloud0). Une fois choisie on peut configurer son adresse de façon à se
positionner dans le même réseau que les contrôleurs, en l’occurrence le réseau du VPN 512.
Figure 54: Carte réseau virtuelle de Management
3.3- ETAPES PRÉLIMINAIRES
Une fois l’architecture de la figure 2.35 implémentée dans notre simulateur, nous devrons à
présent mettre en œuvre l’environnement de travail. Se basant sur l’existant nous allons nous
calquer sur les configurations connues en intégrant les éléments de la documentation Cisco SD-
WAN.

Figure 55: Architecture de Simulation
3.3.1- CISCO VIRTUAL ACCOUNT
Un compte virtuel est un conteneur logique pour des groupes d'appareils qui seront utilisés lors
du déploiement des sites SD-WAN. Dans notre cas il s’agit des vEdge. L’objectif ici est
d’obtenir le fichier serial de configuration qui va contenir les numéros de série de vEdges
compatibles avec les détails de notre architecture.
Accéder à https://software.cisco.com et sélectionner Manage Smart Account0 Ensuite suite
les différentes étapes de création du compte virtuel avec les paramètres de l’entreprise
Sélectionner 18.3 et newer récent dans la liste déroulante, puis sélectionnez Download.
Enregistrez le fichier dans un emplacement sûr pour l'importer dans le vManage ultérieurement.
Figure 56: Téléchargement et enregistrement du fichier serial

- RÉSUMÉ
Nous avons créé un compte virtuel, le profil du contrôleur a ajouté des logiciels vEdge et nous
avons en main l’important fichier serial. Ce qui nous permet de passer à la phase suivante et de
finaliser la mise en œuvre de la simulation.
3.3.2- INSTALLATION DES ÉQUIPEMENTS

Dans cette partie, nous allons installer les différents contrôleurs et les vEdges en se basant sur
l’architecture décidée en 2.5.3
2.6.2.1 INSTALLATION DES CONTRÔLEURS
A- INSTALLATION VMANAGE
Nous démarrons l’équipement vManage de notre simulation après sa mise en place. Une fois
que nous voyons le message System Ready nous allons donc nous identifier à l’équipement
avec vManage login/Password = « admin ». Il faudra ensuite suivre l’invite de commande pour
initialiser la base de données.
Sun Jun 2 03:33:42 UTC 2020: System Ready
viptela 19.3.0
vmanage login: admin

Password:
Welcome to Viptela CLI
admin connected from 127.0.0.1 using console on vmanage
Available storage devices:
hdb 100GB
1) hdb
Select storage device to use: 1
Would you like to format hdb? (y/n): y
Figure 57: Démarrage du contrôleur vManage
A ce niveau nous devons respecter les étapes présentées lors de l’élaboration de la méthodologie
en 2.2.1.1, les configurations techniques concernant les paramètres system-ip, site-id,
organization-name, vpn 512, vpn 0 ainsi que l’installation des certificats nécessaires sont
détaillées dans l’annexe 2.
Une fois la méthodologie appliquée l’équipement vManage est désormais disponible et prêt
pour le déploiement des service SD-WAN sur les sites de CAMTEL.

B- INSTALLATION VSMART ET VBOND

Comme précédemment il faudra tout d’abord démarrer les équipements. Ensuite une fois que
nous voyons le message System Ready nous allons donc nous identifier à l’équipement avec
Username/Password = « admin ».
en 2.2.1.2 et 2.2.1.3, les configurations techniques concernant les paramètres system-ip, site-id,
organization-name, vpn 512, vpn 0 ainsi que l’installation des certificats nécessaires pour
communiquer avec le vManage sont détaillées dans l’annexe 2.
Une fois la méthodologie appliquée les équipements vSmart et vBond sont désormais
disponibles sur l’interface web du vManage comme on peut le voir sur la figure 59 et prêts pour
le déploiement des services SD-WAN sur les sites de CAMTEL.
Figure 58: vSmart et vBond installés
C- INSTALLATION DES VEDGES

Tout comme les 3 installations précédentes il faudra tout d’abord démarrer les équipements.
Ensuite une fois que nous voyons le message System Ready nous allons donc nous identifier à
l’équipement avec Username/Password = « admin ».
en 2.2.2, les configurations techniques concernant les paramètres system-ip, site-id,
organization-name, vpn 512, vpn 0 ainsi que l’installation des certificats nécessaires pour
communiquer avec les contrôleurs sont détaillées dans l’annexe 2.
Une fois la méthodologie appliquée les équipements vEdges sont désormais disponibles sur
l’interface web du vManage comme on peut le voir sur la figure 60 et prêts pour le déploiement
des services SD-WAN sur les sites de CAMTEL.
Figure 59: WAN Edge installé
D- BILAN

Et c'est tout. Notre simulation Cisco SDWAN respectant l’architecture définie dans la figure 61
est désormais fonctionnelle avec des vEdges et les contrôleurs vSmart, vBond, et vManage.
L’installation finale se présente tel qu’il suit dans l’interface graphique du vManage.
Figure 60: Vérification de la mise en œuvre
3.4- PRÉSENTATION DES RÉSULTATS
3.4.1- DÉPLOIEMENT DES SITES CLIENTS
3.4.1.1- CONFIGURATIONS DE BASE DES SITES VPN
A- ROUTEURS CISCO
Chaque site vEdge a derrière lui deux VPN de service représenté chacun par un routeur Cisco.
Ce routeur aura besoin de configurations minimales pour entrer en relation avec le routeur
vEdge et communiquer avec les sites VPNs distants.
Les configurations sont les suivantes pour le routeur LAN11 du VPN 1 du site 1 :
- Configuration des interfaces
Building configuration...
!!
hostname
router ospfLAN11
1
!!
interface
interface FastEthernet0/1
FastEthernet0/0
ip address 11.1.1.1
ip ospf 1 area 0 255.255.255.0
!!
interface
interface FastEthernet0/0
FastEthernet0/1
ip address 192.168.11.2
ip ospf 1 area 0 255.255.255.0
!!
Figure 61: configuration de base des interfaces

Figure 62: configuration de base du routage
- Configuration du routage OSPF avec le vEdge correspondants
B- VPCS
Une fois les routeurs configurent il faut configurer les VPCS avec les adresses IP
correspondantes. Nous allons configurer ici le VPC du VPN 1 connecte au vEdge 1.
3.4.2- MISE EN PLACE DES MODÈLES DE CONFIGURATION

Ici nous allons mettre en place dans le vManage les modèles de périphériques et les modèles de
fonctionnalités qui vont être appliqués à nos vEdges.
Nous pouvons accéder à la section de modèles de configuration Configuration>Templates
Figure 63: Accès à l'espace des Modèles
3.4.2.1- MODÈLES DE BASE

Les modèles de base concernent les fonctionnalités des VPN de transport et de management de
nos vEdges ainsi que les interfaces de transport et de management correspondantes.
A- LES VPN 0 ET 512
Pour configurer le modèle de fonctionnalité des VPN 0 et 512 on procède à l’ajout d’une
nouvelle fonctionnalité dans l’onglet Feature.
Feature>Add Templates
Figure 64: Ajout des fonctionnalités
Dans la page qui s’affiche sélectionner le périphérique vEdge Coud qui est celui que nous
utilisons et choisir ensuite la fonctionnalité VPN.
Select Devices>vEdge Cloud>VPN

Figure 65: Sélection fonctionnalité VPN
On peut ensuite configurer le modèle de fonctionnalités VPN avec les paramètres désirés.
Tout d’abord le nom de la fonctionnalité Template Name et sa description.
Figure 66: Nom et description de la fonctionnalité VPN
Ensuite dans l’onglet Basic Configuration nous allons configurer le nom global et le numéro
du VPN , ici il s’agit du VPN 0 qui est le VPN de transport.
Figure 67: Configuration basique de la fonctionnalité VPN

On accède ensuite à l’onglet IPv4 route afin de configurer les routes statiques
Figure 68: Configuration de la route statique dans le VPN
On clique sur le bouton Add pour ajouter les configurations de route au modèle
Une fois tous les paramètres du modèle mis en œuvre il faut enregistrer à l’aide du bouton Save
tout en base de l’interface.
Figure 69: Bouton Save
Le VPN 512 suivra la même méthode de configuration que le VPN 0, le tout sans définir de
route statique avec pour nom global « MANAGEMENT ».
B- LES INTERFACES DE TRANSPORT ET DE MANAGEMENT :
Afin de configurer les modèles de ces interfaces nous revenons dans l’onglet Feature de la
partie Configuration. Nous ajoutons à nouveau une fonctionnalité à l’aide de Add Template.
Une fois cela fait on sélectionne notre périphérique vEdge-Cloud et notre fonctionnalité VPN
Interface Ethernet.
Select Devices>vEdge Cloud>VPN Interface Ethernet

Figure 70: Fonctionnalité VPN Interface Ethernet
On peut ensuite configurer les paramètres de notre interface. L’interface de transport sera Giga-
ethernet0/0 (Ge0/0) pour chaque vEdge.
Figure 71: Configuration de l'interface
Dans l’onglet tunnel nous mettons le mode tunnel sur On et la couleur du transport sera mpls
Figure 72: Paramètres du tunnel

Ensuite nous activons les différents services de notre interface tunnel (NETCONF, SSH,..)
Figure 73: Services du tunnel
On peut don enregistrer notre modèle à l’aide du bouton Save comme précédemment.
L’interface Ethernet 0 appartenant au VPN 512 de chaque vEdge subira le même type de
configuration, néanmoins son adressage sera dynamique et on n’aura pas besoin d’une interface
tunnel.
3.4.2.2- FONCTIONNALITÉS VPN DE SERVICE ET OSPF

Afin de faire communiquer les VPN de service que nous avons mis en place dans nos
architectures, nous aurons besoin de configurer les modèles de fonctionnalités correspondants
ainsi que le routage OSPF qui aura lieu entre les vEdges et les routeurs VPN.
A- VPN DE SERVICE 1 ET 2
Afin de configurer les modèles de VPN de service nous revenons dans l’onglet Feature de la
partie Configuration. Nous ajoutons à nouveau une fonctionnalité à l’aide de Add Template.
Une fois cela fait on sélectionne notre périphérique vEdge-Cloud et notre fonctionnalité VPN.
Select Devices>vEdge Cloud>VPN, on retrouvera ainsi l’interface vue en a- du 3.4.2.1.

Figure 74: Paramètres VPN de service
Le VPN 1 aura pour nom « LAN » et le VPN 2 aura pour nom « VOIX ». Une fois les
configurations effectuées pour chaque VPN de service on peut sauvegarder avec le bouton Save
B- INTERFACES DE SERVICES
Il sera ensuite question de configurer les modèles d’interfaces de service qui appartiennent à
chaque VPN pour les vEdges. Dans notre architecture nous avons choisi l’interface Ge0/1 pour
le VPN1 et Ge0/2 pour le VPN2. Comme les interfaces précédentes nous allons choisir le
modèle d’équipements, la fonctionnalité VPN Interface Ethernet configurer les paramètres
(Nom, description, …) de la figure suivante et enregistrer.
Figure 75: Paramètres interfaces de service

Sauvegarder ensuite avec le bouton Save

C- FONCTIONNALITÉS OSPF
La fonctionnalité OSPF que nous allons mettre en place va suivre la méthodologie énoncée en
2.2.5 qui permet d’interconnecter les sites VPN 1 et 2 que nous avons mis en œuvre. Pour
chaque VPN de service il nous faudra une fonctionnalité OSPF. Pour configurer la
fonctionnalité OSPF, on reprend les étapes précédentes de l’ajout d’une nouvelle fonctionnalité
mais on sélectionne la fonctionnalité OSPF.
Figure 76: Fonctionnalité OSPF
On peut donc accéder à la fonctionnalité et configurer les différents paramètres
Figure 77: Configuration des paramètres de la fonctionnalité OSPF

- (1) Nom et Description du modèle OSPF du VPN 1 (VPN 2)

- (2) Redistribution du protocole OMP dans OSPF du VPN 1 (VPN 2)
- (3) Configuration de l’aire OSPF et association de l’interface de service correspondante
- (4) Activation de la route par défaut OSPF
Une fois les configurations OSPF effectuées pour chaque VPN de service on peut sauvegarder
avec le bouton Save.
3.4.2.3- MISE EN PLACE DU MODÈLE DE PÉRIPHÉRIQUE
Nous avons configurée les différents modèles de fonctionnalité, il faut désormais les associer à
un modèle de périphérique qui représente le profil mutuel des équipements vEdges qu’on va
déployer.
Pour se faire on accède à l’espace Configuration>Templates, dans l’onglet Device, on crée le
modèle à l’aide du bouton Create Template.
Figure 78: Création du modèle de périphérique
Par la suite il faut créer le modèle de périphérique dans la fenêtre qui s’affiche. Comme dit en
2.1.4.2 le modèles de périphérique contiennent toujours plusieurs modèles de fonctionnalités.
De ce fait nous allons dans cette étape associer tous les modèles des fonctionnalités crées
précédemment avec notre modèle de périphérique.
Une fois les configurations effectuées on peut sauvegarder avec le bouton Save.

Figure 79: Configuration des paramètres du modele de peripherique
- (1) Choix du modèle de périphérique et configuration du nom du modèle et description

- (2) Modèles de fonctionnalité de base du périphérique (system-ip, logging, OMP, AAA)
- (3) Fonctionnalités VPN 0 et 512 et association des fonctionnalités des interfaces
correspondantes
- (4) et (5) Fonctionnalités VPN 1 et 2 de service LAN et VOIP
3.4.3- APPLICATION DES MODÈLES AUX PÉRIPHÉRIQUES
Le modèle crée est désormais présent dans l’onglet Devices, il faut donc lui associer les vEdges
de nos sites qui ont été déployés afin que les configurations prennent forme.

Figure 80: Association des Peripheriques vEdges au modèle
Dans la fenêtre qui s’affiche nous choisissons les vEdges à associer à notre modèle de
configuration.
Figure 81: Sélection des périphériques à associer
On configure ensuite les paramètres variables propres à chaque vEdge pour notre déploiement,
Ces paramètres ont été définis lors de la création des différents modèles de fonctionnalités.

Figure 82: Spécification des paramètres variables des vEdges
On sélectionne le bouton Update pour chaque vEdge et dans la fenêtre suivante on a accès aux
configurations proprement dites. Celles qui seront appliqués aux vEdges à partir de notre
interface web et celles qui sont préexistantes dans les équipements
Figure 83: Annonce des configurations

.
Le bouton Configure Devices permet donc finalement d’appliquer nos configurations.
Le message « success » de la fenêtre suivante nous indique qu’elles ont bien été propagées dans
les équipements
Figure 84: Succès de l'application des configurations au vEdges
3.4.4- VÉRIFICATION DES CONFIGURATIONS

VÉRIFICATION DES ROUTES OMP ET OSPF SUR LES VEDGES
Utilisation de la commande show ip routes
Figure 85: Vérification des routes OMP et OSPF
On remarque la présence de nos sites distants

VÉRIFICATION DES INTERFACES
Les différentes interfaces configurées sont actives

Figure 86: Vérification des interfaces
VÉRIFICATION DE LA RELATION OSPF

La relation OSPF entre le vEdge2 et les routeurs Cisco du VPN 1 et 2 en état « full ».
Figure 87: Vérification de la relation OSPF
3.4.5- COMMUNICATION INTER-SITES ENTRE VPN

Une fois les configurations vérifiées, un test de connectivité s’impose :
- Pour le VPN 1 - Pour le VPN 2
Figure 88: Connectivité dans le VPN 1 Figure 89: Connectivité dans le VPN 2

3.5- BILAN
Dans ce chapitre, nous avons fait un rappel des objectifs, nous avons mis en œuvre les outils
technologiques de notre simulation après avoir ressorti les étapes préliminaires ce qui nous a
permis de ressortir les différents résultats. Au cours de la simulation, nous avons déployé un
service SD-WAN Cisco de façon opérationnelle et interconnecté les sites du réseau d’entreprise
de CAMTEL.

CONCLUSION ET PERSPECTIVES
CONCLUSION ET PERSPECTIVES
Il a été question au cours de notre travail, d’étudier et mettre en place la solution Cisco SD-
WAN dans le réseau d’entreprise de CAMTEL par l’intermédiaire d’une simulation, permettant
ainsi à ses équipes de maintenance réseau d’exploiter au mieux les ressources dans le cadre
d’un déploiement en environnement de production.
Cette solution permet à CAMTEL d’offrir un nouveau type de service à ses employés pour son
propre réseau d’entreprise et ses clients raccordés à son nuage MPLS. Contrairement aux
techniques de déploiement dans WAN traditionnels, les techniques développées dans ce travail
permettent aux clients d’avoir une croissance rapide de leur réseau indépendamment du type de
transport, un contrôle centralisé de leur architecture réseau pour les déploiements, les politiques
de routages et la sécurité à un coût qui sera beaucoup plus accessible en réduisant l’intervention
des équipes sur site, le tout en évitant de dépendre d’un seul fournisseur d’interconnexion. La
solution SD-WAN permettra également d’exploiter au mieux les ressources de son nouveau
DATA-CENTER en étant parmi les premiers à offrir ce type de service en Afrique Sub-
saharienne.
La mise en place de cette solution a été effectué par une conception architecturale du système,
précédée d’une compréhension de la technologie et des outils facilitant son exploitation et son
utilisation. L’acquisition des images logicielles de contrôleurs SD-WAN ainsi que le
provisioning du fichier serial avec les paramètres adéquats, le tout avec l’association des
certificats constituent la base de la conception. Il est à noter que l’intégration de la solution en
environnement virtuel a couté 0 FCFA en termes de budget néanmoins les mises en place de
prérequis sur le plan logiciel et procédurale peut rendre les déploiements longs au début mais
une fois fonctionnel le logiciel de Cisco se charge de tout.
En guise de perspectives, nous pouvons dire que certains points pourront être dans le futur
améliorés pour rendre cette migration encore plus performante. On note :
- L’implémentation pour tous les segments du réseau d’entreprise et de production
impliquant les services aux abonnes.
- La réflexion sur une stratégie marketing permettant de créer le besoin du service sur le
marché afin de vendre la solution aux entreprises avant même de la déployer
- L’étude avec l’équipementier Cisco des implications intellectuelles et de redevance liée
à la commercialisation de leur solution (Brevet, Achats des contrôleurs, Formations,
transfert de technologie).

ANNEXES
REFERENCES BIBLIOGRAPHIQUES
[1] Marcus Oppitz and Peter Tomsu. Inventing the Cloud Century. Springer, 2018.
[2] Luc De Ghein. MPLS Fundamentals. Cisco Press, 2007.
[3] Dennis Fowler. Virtual Private Networks — Making the Right Connection. Morgan
Kaufmann Publishers, 1999
[4] Mallikarjun Tatipamula Eiji Oki Roberto Rojas-Cessa and Chris- tian Vogt. Advanced
Internet Protocols, Services, and Applications. John Wiley Sons, 2012.
[5] André Perez. Network Security. Wiley, 2014
[6] Randy Zhang and Micah Bartell. BGP Design and Implementation. Cisco Press, 2004.
[7] Luc De Ghein. MPLS Fundamentals. Cisco Press, 2007.
[8] James S. Tiller. A Technical Guide to IPSec Virtual Private Net- works. CRC Press, 2000.
[9] Juniper Networks. VPN Feature Guide for Security Devices. Juniper Networks, 2018.
[10] Colin Bookham. Versatile Routing and Services with BGP: Under- standing and
Implementing BGP in SR-OS. John Wiley Sons, 2014.
[11] Tonye Emmanuel. Réseaux de télécommunications et transmission de données. Chapitre
dans le livre Problématique de l’informatisation des processus électoraux en Afrique, paru
chez L’Harmattan, Paris, France en 2004, sous la direction d’Alain Nkoyock.
[12] Statista. SD-WAN revenues worldwide by geography 2016-2022. 2020. url
: https://www.statista.com/statistics/802591/worldwide-sd-wan-revenue-by-
geography/ (Consulté le 05/06/2020)
[13] Huawei. MPLS Overview. url:
https://support.huawei.com/enterprise/en/doc/EDOC1000178173/953f01ce/overview-of-mpls
(Consulté le 08/06/2020)
[14] Forbes. SD-WAN: Entry Point For Software-Defined Everything. 2017. url:
https://www.forbes.com/sites/jasonbloomberg/2017/03/20/sd-wan-entry-point-for-software-
defined-everything/#60983cd846ee (Consulte le 04/06/2020)
[15] www.bgp.potaroo.net. BGP Routing Table Analysis Reports. 2018. url:
https://bgp.potaroo.net/. (Consulté le 09/06/2020)
[16] Cisco Press. WAN Concepts. 2017. url:
http://www.ciscopress.com/articles/article.asp?p=2832405&seqNum=5 (Consulté le
06/06/2020)

ANNEXES
[17] Cisco Systems. Introduction to Cisco MPLS VPN Technology. url:
https://www.cisco.com/c/en/us/td/docs/net_mgmt/vpn_solutions_center/2-
0/mpls/provisioning/guide/PGmpls1.html (Consulté le 06/06/2020)
[18] Citrix. NetScaler SD-WAN : Meilleures pratiques - Sécurité 2017.
url:https://docs.citrix.com/en-us/netscaler-sd-wan/9-2/security-best-practices.html. (Consulté
le 10/06/2020)
[19] www.sdxcentral.com.Que sont les contrôleurs SDN? url:https://www.sdxcentral.com/sdn
/définitions/contrôleurssdn/ (Consulté le 10/06/2020)
[20] www.sdxcentral.com. Who is the Open Networking Foundation (ONF)? url: https://
www.sdxcentral.com/sdn/definitions/who-is-open-networking-foundation-onf/ (Consulté le
10/06/2020)
[21] Metzler Associates Ashton. The Need to Rethink the WAN. url:
http://www.velocloud.com/sd-wan-resources/white-papers/need-to-rethink-the-wan-jim-
metzler (Consulté le 06/06/2020)
[22] Cisco SD Wan Design Guide. 2020 url :
https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.
(Consulté le 10/06/2020)
[23] Cisco wan edge deloyment url :
https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/EE/DG/ee-WAN-dg.pdf. (Consulté
le 10/06/2020)
[24] www.sdxcentral.com. What are SDN Southbound APIs? url:
https://www.sdxcentral.com/sdn/definitions/southbound-interface-api/. (Consulté le
10/06/2020)
[25] SANS Institute. Border Gateway Protocol - The Language of the Internet url:
https://www.sans.org/reading-room/whitepapers/protocols/border-gateway-protocol-the-
language-internet-379. (Consulté le 09/06/2020)
[26] Cisco Systems. Introduction to Border Gateway Protocol (BGP). 2012. url:
https://www.petri.com/introduction- border-gateway-protocol-bgp. (Consulté le 09/06/2020)
[27] www.sdxcentral.com. What are SDN Northbound APIs? url:
https://www.sdxcentral.com/sdn/definitions/ north-bound-interfaces-api/. (Consulté le
10/06/2020)
[28] RIPE NCC. Autonomous System (AS) Number Assignment Policies. 2017. url:
https://www.ripe.net/publications/docs/ripe-679. (Consulté le 09/06/2020)

ANNEXES
[29] The Internet Society. A Border Gateway Protocol 4 (BGP-4). 2006. url:
https://tools.ietf.org/ html/ rfc4271. (Consulté le 09/06/2020)
[30] Cisco SD Wan Certificates Deploy. 2019. url :
https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/SDWAN/cisco-sd-wan-
certificates-deploy-2019sep.pdf. (Consulté le 10/06/2020)
[31] Cisco Systems. What Is a VPN? - Virtual Private Network. url:
https://www.cisco.com/c/en/us/products/security/vpn-endpoint-security-clients/what-is-
vpn.html. (Consulté le 11/06/2020)
[32] Cisco Systems. Remote-Access VPNs: Business Productivity, Deployment, and
Security Considerations. 2006. url:
https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-
firewalls/prod_white_paper0900aecd804fb79a.html. (Consulté le 11/06/2020)
[33] The Internet Society. BGP/MPLS IP Virtual Private Networks (VPNs).. 2006. url:
https://tools.ietf.org/html/ rfc4364. (Consulté le 10/06/2020)
[34] Cisco Systems. MPLS: Layer 3 VPNs Configuration Guide. 2018. url:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-
vpns-15-mt-book/mp-bgp-mpls-vpn.html (Consulté le 11/06/2020)
[35] Cisco Systems. BGP-VPN Distinguisher Attribute. url:
https://www.cisco.com/c/en/us/td/docs/ios- xml/ios/iproute_bgp/configuration/xe-16/irg-xe-
16-book/bgp-vpn-distinguisher-attribute.pdf. (Consulté le 11/06/2020)
[36] Cisco Systems. How Virtual Private Networks Work. 2008. url:
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-
protocols/14106- how-vpn-works.html. (Consulté le 11/06/2020)


Memoire ENSP - OTTOU - Corrige1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Memoire ENSP - OTTOU - Corrige1

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I

CONCEPTION ET DÉPLOIEMENT D’UNE

Mémoire de Fin d’études

Sous la supervision académique du :

Devant le jury composé de :

 Président : NDZANA Benoît, Maître de Conférences E.N.S.P.Y

Année Académique : 2019-2020

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

J’adresse mes profonds remerciements à la société « Cameroun Télécommunications » qui

Je tiens aussi à témoigner ma reconnaissance à :

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

AES: Advanced Encryption Sandard IaaS: Infracstructure As A Service

D MPLS-VPN: Multi-Protocol Label Switching -

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Mots clés : SD-WAN, MPLS, VPN, administration réseau, CISCO, déploiements.

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Keywords: SD-WAN, MPLS, network administration, CISCO, deployments.

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

LISTE DES FIGURES

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Figure 48: Modèle de configuration OSPF cote VPN de service ---------------------------------- 68

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

LISTE DES TABLEAUX

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

TABLE DES MATIERES

Liste des figures ................................................................................... 7

Liste des tableaux ................................................................................. 9

Introduction Générale ........................................................................... 11

Contexte et Problématique .................................................................... 13

1.2- Problématique ......................................................................... 30

1.3- Bilan ...................................................................................... 37

2.1. SD-WAN ....................................................................................... 39

2.2. Généralités sur la méthodologie de déploiement ................................... 61

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

2.3. Choix de l’outils de simulation .......................................................... 68

2.4. Analyse des besoins et contraintes ..................................................... 70

2.5- Bilan ...................................................................................... 71

Résultats et commentaires ..................................................................... 72

3.1- Rappel des objectifs .................................................................. 73

3.2- Architecture Structurelle de la simulation ....................................... 73

3.3- Etapes préliminaires .................................................................. 77

3.4- Présentation des résultats ........................................................... 81

3.5- Bilan ...................................................................................... 95

Annexes ............................................................... Erreur ! Signet non défini.

Annexe 1 : Présentation de CAMTEL ............................ Erreur ! Signet non défini.

Annexe 2 : Configurations contrôleurs et vEdges lors de la mise en œuvre .. Erreur !

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

e chapitre présente le contexte du travail et la problématique associée. En effet dans un

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

1.1.1- RÉSEAUX ÉTENDUS

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Figure 1: Arbre Technologique WAN [11]

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Tout dépend des exigences spécifiques de l'entreprise.

Figure 2: Mécanisme de commutation de paquets [12]

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Figure 3 : Architecture MPLS [13]

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Figure 4 : Mécanisme d'étiquette MPLS [7]

Mémoire de fin d’études en vue de l’obtention du diplôme d’ingénieur de conception

Figure 5: L’en-tête MPLS [21]