Memoire BADAROU Youssouf Master2 SDN LAN Corrigé Corrigé Final PDF

REPUBLIQUE DU BENIN
******
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE
SCIENTIFIQUE (MESRS)
*******
DIRECTION GENERALE DE L’ENSEIGNEMENT SUPERIEUR (DGES)
*********
UNIVERSITE AFRICAINE DE LA TECHNOLOGIE ET DE MANAGEMENT
(UATM GASA-FORMATION)
MEMOIRE DE FIN DE FORMATION POUR L’OBTENTION

DU DIPLOME DE MASTER PROFESSIONNEL
FILIERE : Génie Electrique OPTION : Réseaux Informatiques
et Télécommunications
THEME :
MISE EN PLACE D’UNE SOLUTION SDN POUR

LA GESTION DES RESEAUX LAN :
CAS DE L’UATM
REALISE PAR :
BADAROU Youssouf Adjassa
Sous la Direction de :
M. Florentin Y. AGOSSOU
Ingénieur des Télécommunications Réseaux
Enseignant des Technologies Télécoms
Année Académique : 2021-2022

Mise en place d’une solution SDN pour la gestion des réseaux LAN : Cas de l’UATM
AVERTISSEMENT
Les opérations réalisées ci-après sont fondées sur des hypothèses dont la
réalisation présente par nature un caractère incertain. Les résultats réels peuvent différer
de manière significative des informations présentées. Ces opérations ne sont fournies
qu’à titre indicatif, et ne peuvent être considérées comme un engagement ferme ou
implicite.
L’Université Africaine de Technologie et de Management (UATM/GASA

FORMATION) n’entend donner aucune approbation ou improbation aux opinions
émises dans le cadre de ce mémoire. Elles doivent être considérées comme propres à
leurs auteurs.
Réalisé par BADAROU Youssouf Adjassa i

DEDICACE
Je dédie le présent mémoire à mes parents Sefou BADAROU et

Koudirathou GBADAMASSI, pour tous les efforts et le soutien indéfectibles
qui m’ont permis d’être à cette étape dans mes études. Que ALLAH vous
comble de toute sa grâce.
BADAROU Youssouf Adjassa
Réalisé par BADAROU Youssouf Adjassa ii

REMERCIEMENTS
Nos remerciements vont de prime abord à DIEU Tout puissant pour le souffle
de vie et la santé qu’Il nous a donné et pour tout ce qu’il continue de faire pour nous.
Nos sincères remerciements vont également à l’endroit de :
• Monsieur Théophane AYI, le président directeur général de l’UATM / GASA

Formation ;
• Monsieur Florentin Y. AGOSSOU, mon Directeur de mémoire pour avoir accepté

de nous assister dans la réalisation de ce travail malgré ses nombreuses occupations ;
• Messieurs Lafitte NGUEMEGNE et Marc-Aurel AKPONNA et tout le personnel

de l’Administration de l’UATM pour leur accompagnement et soutien ;
• Tout le Corps enseignant de l’UATM pour les connaissances transmises ;
• Monsieur Jean AFOKPE, pour tous les enseignements qu’il nous a donnés et les
sacrifices qu’il fait pour notre réussite ;
• Nos parents et amis, pour leurs soutiens matériel et moral dont ils ont fait preuve
à notre égard ;
• Tous les camarades de promotion pour le bon parcours vécu ensemble ces années
de formation ;
• Tous ceux qui de près ou de loin ont contribué à la réalisation de ce mémoire.
Réalisé par BADAROU Youssouf Adjassa iii

SOMMAIRE
AVERTISSEMENT ...................................................................................................................................... i
DEDICACE ................................................................................................................................................ ii
REMERCIEMENTS ................................................................................................................................... iii
SOMMAIRE ............................................................................................................................................. iv
LISTE DES SIGLES ET ABREVIATIONS ...................................................................................................... vi
LISTES DES FIGURES ............................................................................................................................. viii
LISTE DES TABLEAUX .............................................................................................................................. ix
RESUME................................................................................................................................................... x
ABSTRACT............................................................................................................................................... xi
Contexte et Justification ....................................................................................................................... xii
INTRODUCTION GÉNÉRALE ................................................................................................................. - 1 -
PROBLÉMATIQUE .................................................................................................................................... 2
OBJECTIFS................................................................................................................................................ 2
Objectif général................................................................................................................................... 2
Objectifs spécifiques ........................................................................................................................... 2
Première Partie : État de l'art des réseaux de campus ................................................................. 3
CHAPITRE 1 : LES RESEAUX TRADITIONNELS DE CAMPUS ...................................................................... 4
Introduction ........................................................................................................................................ 4
1.1 Les équipements réseau ............................................................................................................... 4
1.2 Architecture des réseaux de campus ............................................................................................ 7
Conclusion ......................................................................................................................................... 13
CHAPITRE 2 : PRESENTATION DU SDN .................................................................................................. 14
Introduction ...................................................................................................................................... 14
2.1 Des réseaux traditionnels vers le SDN ........................................................................................ 14
2.2 Principes du SDN ......................................................................................................................... 16
2.3 Avantages du SDN ....................................................................................................................... 18
2.4 Le protocole OpenFlow dans l'architecture SDN ....................................................................... 19
2.5 Cas d’utilisations du SDN ............................................................................................................ 28
Conclusion ......................................................................................................................................... 30
Deuxième Partie : RESULTATS ET DISCUSSIONS ............................................................................ 31
CHAPITRE 3 : DESIGN ET IMPLEMENTATION D’UNE SOLUTION SDN POUR L’UATM ........................... 32
Introduction ...................................................................................................................................... 32
3.1 Analyse de l’existant ................................................................................................................... 32
3.2 Hypothèses de travail ................................................................................................................. 33
3.3 Analyse critique........................................................................................................................... 38
Réalisé par BADAROU Youssouf Adjassa iv

3.4 Proposition d’architecture basée sur le SDN .............................................................................. 39

Conclusion ......................................................................................................................................... 40
CHAPITRE 4 : SIMULATION DU RESEAU SDN LAN ................................................................................. 41
Introduction ...................................................................................................................................... 41
4.1 Mise en place des prérequis ....................................................................................................... 41
4.2 Administration d’un réseau SDN................................................................................................. 46
4.3 Test de fonctionnement.............................................................................................................. 51
Conclusion ......................................................................................................................................... 53
CONCLUSION GENERALE ....................................................................................................................... 55
Perspectives .......................................................................................................................................... 56
Problèmes rencontrés........................................................................................................................... 56
REFERENCE BIBLIOGRAPHIQUES ........................................................................................................... 57
Liens Web .............................................................................................................................................. 58
Annexe: Installer le contrôleur POX ......................................................................................................... I
Réalisé par BADAROU Youssouf Adjassa v

LISTE DES SIGLES ET ABREVIATIONS

API : Application Programming Interface
ARP : Address Resolution Protocol
ASIC : Application Specific Integrated Circuit
BGP : Border Gateway Protocol
CLI : Command Line Interface
DARPA : Defense Advanced Research Projects Agency
DOD : Department Of Defense EEs Execution Environments
FAI : Fournisseur d’Accès Internet
FTP : File Transfert Protocol
GENI : Global Environment for Network Innovations
HAL : Hardware Abstraction Layer
HDFS : Hadoop Distributed File System
HTTP : Hyper Text Transfer Protocol
IaaS : Infrastructure-as-a-Service
IETF : Internet Engineering Task Force
IP : Internet Protocol
ISO : International Standardization Organization
LAN : Local Area Network
LPU : Line Processing Unit
MAC : Media Access Control
MD-SAL : Model Driven SAL
MPLS : Multiprotocol Label Switching
MPU : Main Processing unit
NaaS : Network as a Service
NE : Network Equipment
NETCONF : NETwork CONFiguration protocol
NFV : Network Functions Virtualization
NodeOS : Node Operating System
Réalisé par BADAROU Youssouf Adjassa vi

OFM: Open Flow Manager

OSI : Open Systems Interconnection
SAL : Service Abstraction Layer
SDN : Software Defined Network
SNMP : Simple Network Management Protocol
SOHO : Small Office Home Office
SSH : Secure Shell
STP : Spanning Tree Protocol
SFU : Switch Fabric Unit
TCAM : Tenary Contenant Addressables Memory
TCP : Transmission Control Protocol
TLS : Transport Layer Security
UATM : Universite Africaine de Technologie et de Management
VLAN : Virtual Local Area Network
Réalisé par BADAROU Youssouf Adjassa vii

LISTES DES FIGURES

Figure 1 : SFU ....................................................................................................................................... 5
Figure 2 : Panneau typique d'un équipement réseau modulaire ...................................................... 5
Figure 3 : MPU ...................................................................................................................................... 5
Figure 4 : LPU ...................................................................................................................................... 6
Figure 5 : Équipement non modulaire ................................................................................................ 6
Figure 6 : Panorama d'un Campus Network ..................................................................................... 7
Figure 7 : Architecture générale d’un réseau de campus .................................................................. 8
Figure 8 : Architecture typique des petits réseaux de campus ....................................................... 10
Figure 9 : Architecture typique des réseaux de campus de taille moyenne .................................. 11
Figure 10 : Architecture typique des grands réseaux de campus .................................................. 12
Figure 11 : Architecture réseau de Gasa Formation ....................................................................... 12
Figure 12 : Consternation du plan de contrôle dans un routeur . ................................................. 15
Figure 13 : Architecture du SDN ....................................................................................................... 17
Figure 14 : Diagramme de flux des messages OpenFlow ............................................................. 21
Figure 15 : Structure d'une table de flux openflow ......................................................................... 21
Figure 16 : Fonctionnement d’une table de flux ............................................................................. 22
Figure 17 : Schématisation du modèle de flux OpenFlow ............................................................... 23
Figure 18 : Processus de communication entre le Switch et le contrôleur ..................................... 26
Figure 19 : Communication inter-contrôleur dans une architecture distribuée ........................... 28
Figure 20 : Architecture traditionnelle proposée ............................................................................. 36
Figure 21 : Architecture SDN proposée ............................................................................................ 39
Figure 22 : Topologie proposé pour le loadbalancing...................................................................... 47
Figure 23:Connexion à la CLI de mininet ........................................................................................ 49
Figure 24 : Création de machine serveur.......................................................................................... 50
Figure 25 : Mise en place du loadbalancing sur le contrôleur ........................................................ 50
Figure 26 : Requêtes des clients ......................................................................................................... 51
Figure 27 : Réponse des serveur ........................................................................................................ 52
Réalisé par BADAROU Youssouf Adjassa viii

LISTE DES TABLEAUX
Tableau 1: Matériels réseau de l'UATM (Gbegamey) ..................................................................... 32

Tableau 2: Besoin en matériels informatique de l'UATM .............................................................. 33
Tableau 3 : Répartion de matériels ................................................................................................... 35
Tableau 4 : Adressage des hôtes ........................................................................................................ 48
Réalisé par BADAROU Youssouf Adjassa ix

RESUME
Le présent mémoire s’est intéressé à la mise en place d’une solution SDN pour
les réseaux locaux d’entreprise. Nous y avons fait une application au cas de l’Université
Africaine de Technologie et de Management, UATM.
Pour y arrivé, après avoir présenté les réseaux de campus, nous avons abordé une étude
des préceptes et fondements du paradigme SDN. Le travail principal a ciblé
l’implémentation et l’administration d’un réseau SDN, en exploitant les fonctionnalités
du protocoles Openflow et du contrôleur POX.
Une simulation sous mininet nous a permis de réaliser des tests d’accessibilité et de
partage de charges afin de valider l’architecture SDN proposée pour l’UATM, dans une
perspective de digitalisation de ses activités.
Mots-clés : SDN, OpenFlow, OFM, Contrôleur, POX.
Réalisé par BADAROU Youssouf Adjassa x

ABSTRACT
We deal with the implementation of an SDN solution for corporate local
networks “Case of UATM”. After presenting the campus networks, we approached a
study of the precepts and foundations of the SDN paradigm. The main work focused on
the implementation and administration of an SDN network, by exploiting the
functionalities of the Openflow protocols and the POX controller. Accessibility and
load sharing tests validated our SDN architecture.
Keywords: SDN, OpenFlow, OFM, Controller, POX.
Réalisé par BADAROU Youssouf Adjassa xi

Contexte et Justification
Dès le premier jour où le réseau informatique existe, ce dernier est complexe et
difficile à gérer, ce qui se traduit par les aspects suivants : la coexistence de divers
périphériques réseau tels que les routeurs, point d’accès sans fil. Les appareils de
différents ou même de mêmes fournisseurs sont gérés de différentes manières, la
complexité des équipements entraîne une gestion complexe du réseau.
Limites des réseaux traditionnels :
• Sur un réseau traditionnel, un système de gestion de réseau est généralement

déployé en tant que plan de gestion, tandis que le plan de contrôle et le plan de
données sont répartis sur chaque périphérique réseau.
• Les réseaux traditionnels utilisent des protocoles complexes, tels que les
protocoles IGP, BGP, MPLS et multidiffusion, et davantage de protocoles sont
continuellement introduits dans les réseaux.
• Les fournisseurs d’équipements développent également leurs protocoles
propriétaires. Les périphériques réseau ont un grand nombre de commandes et
les interfaces de fonctionnement des périphériques de différents fournisseurs
varient considérablement, ce qui rend le fonctionnement et la maintenance du
réseau complexes.
• Le déploiement d’une nouvelle fonction sur un réseau traditionnel peut prendre
beaucoup de temps, car les plans de contrôle des périphériques réseau sont
fermés et les périphériques de différents fournisseurs peuvent utiliser différents
mécanismes de contrôle. De plus, des mises à niveau logicielles doivent être
effectuées sur chaque appareil, ce qui réduit considérablement l’efficacité du
travail.
Réalisé par BADAROU Youssouf Adjassa xii

INTRODUCTION GÉNÉRALE
Avec l’avènement des innovations technologiques récentes telles que la
virtualisation des systèmes et le cloud computing, les limites actuelles des
architectures réseaux deviennent de plus en plus problématiques pour les opérateurs
et les administrateurs réseaux. En effet, depuis déjà plusieurs années, il est
communément admis que les architectures IP traditionnelles sont, d’une part,
particulièrement complexes à configurer à cause de la nature distribuée des
protocoles réseaux et, d’autre part, difficile à faire évoluer en raison du fort couplage
qui existe entre le plan de contrôle et le plan de données des équipements
d’interconnexion existants. Le problème est en effet que le manque d’innovation
dans l’univers des réseaux a fait peser des contraintes importantes sur le déploiement
des applications réseaux. Les constructeurs ont donc fini par se décider à tenter
d’apporter aux réseaux le niveau de flexibilité et de simplicité dont ont besoin les
entreprises et les fournisseurs de services. Les principaux domaines d’innovation au
cours des dernières années sont à chercher du côté du contrôle centralisé, de la
programmabilité, et de la virtualisation. Ces innovations sont regroupées sous
l’appellation commune de SDN (ou software-defined network) et visent à résoudre
les problèmes que les entreprises rencontrent avec leurs réseaux. Le paradigme SDN
est une nouvelle approche qui a pour ambition de répondre à cette rigidité
architecturale des réseaux IP actuels, notamment en les rendant plus programmables.
C’est dans cet ordre d’idée que s’inscrit notre mémoire dont le thème s’intitule
« Mise en place d’une solution SDN pour la gestion des réseaux LAN : Cas de
l’UATM »
L’objectif de ce travail est de faciliter gestion des réseaux locaux d’entreprises.
Pour mener à bien cette étude nous avons organisé ce document en quatre
chapitres. Le chapitre 1 présentera les réseaux de campus. Dans le chapitre 2, nous
allons développer les principes fondamentaux du paradigme SDN. Le chapitre 3 sera
mis à profit pour bâtir une architecture SDN pour le compte de l’UATM. Dans le
Réalisé par BADAROU Youssouf Adjassa -1-

dernier chapitre, nous présenterons notre contribution par une simulation de la

solution SDN conçue sous mininet.
PROBLÉMATIQUE
De cet contexte nous ressortons le problème principale de notre thème qui est la
complexité de gestion des réseaux locaux d’entreprises, dans ce monde en perpétuelle
évolution technologiques.
Ce problème principale peut être divisée en de petits problème à savoir :
• Coûts élevé en matière de matériels et logiciels lourds pour les entreprises.

• Prolifération de matériels informatiques (serveurs, ordinateurs..) dans les
entreprises due à un choix d’infrastructures hétérogènes.
• Difficultés de maintenance vu qu’elle sera effectué sur plusieurs machines.
OBJECTIFS
Objectif général
La mission principale de ce projet est de montrer la nécessité de l’adoption d’une
architecture SDN dans les réseaux locaux d’entreprises, en mettant en œuvre un contrôle
centralisé du réseau tout en fournissant un bon support pour l’innovation des
applications réseau.
Objectifs spécifiques
Pour atteindre notre objectif principal, il est important de se fixer des taches précises
allant dans ce sens, d’où les objectifs spécifiques qui suivent :
• Permettre une gestion simple et centralisée du réseau,

• Une meilleure sécurisation des données, car elles sont centralisées.
• Raccourcissement du temps de déploiement des services réseau.
• Offrir une optimisation automatique, améliorant ainsi l’utilisation du réseau.
Réalisé par BADAROU Youssouf Adjassa -2-

Première Partie : État de l'art des réseaux de campus
Réalisé par BADAROU Youssouf Adjassa 3

CHAPITRE 1 : LES RESEAUX TRADITIONNELS DE

CAMPUS
Introduction
L'échelle du réseau du campus est flexible en fonction des besoins réels. Il peut
s'agir d'un petit bureau à domicile (SOHO), d'un campus scolaire, d'un campus
d'entreprise, d'un parc ou d'un centre commercial. Cependant, le réseau du campus ne
peut pas être étendu à l'infini. En règle générale, les grands campus, tels que les campus
universitaires et les campus industriels, sont limités à plusieurs kilomètres carrés. De
tels réseaux de campus peuvent être construits à l'aide de la technologie de réseau local
(LAN).
Les technologies LAN typiques utilisées sur les réseaux de campus comprennent
les technologies Ethernet (câblées) conformes à la norme IEEE 802.3 et les technologies
Wi-Fi (sans fil) conformes à la norme IEEE 802.11 [9].
1.1 Les équipements réseau

L'infrastructure réseau se compose entre autres de commutateurs, de routeurs et
de pare-feu.
Quels sont les composants d'un périphérique réseau ? Comment ces composants
fonctionnent-ils ?
Les équipements réseau traditionnels sont de deux types :
➢ Les équipements modulaires ;
➢ Les équipements fixés.
1.1.1 Les équipements modulaires

Les modules constitutifs d’un équipement modulaire sont indépendants les uns
des autres. Ils sont aux nombres de trois[9].
Nous avons :
➢ Main Processing unit (MPU);
➢ Switch Fabric Unit (SFU);
➢ Line Processing Unit (LPU).

Nous utiliserons un S12700E-8 pour décrire l’architecture traditionnelle d’un

équipement réseau.
Figure 2 : Panneau typique d'un équipement réseau

modulaire
Sur ce panneau on retrouve les trois éléments dont nous avons parlé
précédemment. Voyons plus en détail à quoi ils servent.
➢ Le MPU
Main Processing unit (MPU) : il est responsable du plan de contrôle et du plan

de gestion de tout le système.
➢ Le SFU Figure 3 : MPU
Switch Fabric Unit (SFU) : il est responsable du plan de donnée de tout le

système.
Le plan de données fournit des canaux de données à grande vitesse pour la
commutation de données entre les modules de services.
Figure 1 : SFU

➢ LPU
Line Processing Unit (LPU) : il permet la transmission de données et fournit des
interfaces (optiques et électriques) avec des débits différents.
Figure 4 : LPU
1.1.2 Les équipements fixes

À la différence d'un appareil modulaire, les modules de service des appareils fixes
ne sont pas des modules matériels indépendants. Au lieu de cela, ils sont intégrés
dans un châssis.
Interface d’accès
Figure 5 : Équipement non modulaire

1.2 Architecture des réseaux de campus

Un réseau de campus est un réseau local (LAN) qui connecte des personnes et
des objets dans une zone spécifiée. En règle générale, un réseau de campus n'a qu'une
seule entité de gestion. S'il y a plusieurs entrées de gestion dans une zone, la zone est
considérée comme ayant plusieurs réseaux de campus[10].
Figure 6 : Panorama d'un Campus Network
Une large gamme de lieux, tels que les campus, les espaces de bureaux et les centres
commerciaux, sont couverts par des réseaux. Vous pouvez accéder aux ressources
internes de votre école, accéder aux imprimantes internes de votre entreprise pour
imprimer des documents, ou accéder à internet pour parcourir les actualités à travers
les réseaux.
Ces réseaux appartiennent aux réseaux de campus et sont généralement construits par
des entreprises ou des organisations. Les réseaux de campus améliorent non seulement
l'efficacité opérationnelle des entreprises, mais fournissent également des services
d'accès au réseau pour les utilisateurs externes.

1.2.1 Architecture générale d’un réseau de campus
Figure 7 : Architecture générale d’un réseau de campus
Couches et zones typiques d'un réseau de campus :

• La couche centrale est la zone dorsale d'un réseau de campus, qui est le
noyau de commutation de données. Il connecte différentes parties du réseau
du campus, telles que le centre de données, le centre de gestion et la sortie
du campus[10].

• La couche d'agrégation : est une couche intermédiaire d'un réseau de

campus et complète l'agrégation ou la commutation des données. Certaines
fonctions réseau fondamentales, telles que le routage, la qualité de service et
la sécurité, sont également fournies au niveau de cette couche.
• Couche d'accès : En tant que périphérie d'un réseau de campus, cette couche
connecte les utilisateurs finaux au réseau de campus.
• Zone de sortie : En tant que périphérie qui connecte un réseau de campus à

un réseau externe , cette zone permet un accès mutuel entre les deux
réseaux. En règle générale, un grand nombre de dispositifs de sécurité réseau,
tels que des dispositifs de système de prévention des intrusions (IPS), des
dispositifs anti-DDoS et des pare-feu, sont déployés dans cette zone pour se
défendre contre les attaques provenant de réseaux externes.
• Zone de centre de données : dispose de serveurs et de systèmes

d'application déployés pour fournir des services de données et d'application
aux utilisateurs internes et externes d'une entreprise.
• Zone de gestion du réseau : les systèmes de gestion du réseau, y compris le

contrôleur SDN WAC et eLog (serveur de journal), sont déployés dans cette
zone pour gérer et surveiller l'ensemble du réseau du campus.
Généralement, un réseau de campus est conçu de manière hiérarchique et

modulaire. Les réseaux de campus peuvent être classés en petits, moyens et grands
réseaux de campus en fonction du nombre de terminaux ou de NE (équipements
réseau)[10].

1.2.2 Architecture typique des petits réseaux de campus
Figure 8 : Architecture typique des petits réseaux de campus
Les petits réseaux de campus sont généralement déployés dans des scénarios où le
nombre d'utilisateurs d'accès est faible (plusieurs ou dizaines d'utilisateurs). Un
réseau de petit campus ne peut couvrir qu'un seul emplacement, a une architecture
simple et est conçu pour permettre un accès mutuel entre les ressources internes.
Caractéristiques des petits réseaux de campus :
• Petit nombre d'utilisateurs
Nombre de bornes<200
Nombre de NE<20
• Un seul emplacement
• Architecture réseau simple
• Configuration réseau simple

1.2.3 Architecture typique des réseaux de campus de taille

moyenne
Figure 9 : Architecture typique des réseaux de campus de taille

moyenne
Un réseau de campus de taille moyenne prend en charge l'accès de centaines à des

milliers d'utilisateurs.
La conception modulaire est introduite dans les réseaux de campus de taille

moyenne, c'est-à-dire que les réseaux peuvent être partitionnés par fonction.
Cependant, le nombre de modules fonctionnels est faible. Dans la plupart des cas, un
réseau de campus de taille moyenne est partitionné de manière flexible en fonction
des exigences de service.
Caractéristiques des réseaux de campus de taille moyenne :
• Échelle de réseau de taille moyenne

Nombre de bornes 200 à 2000
Nombre de NE 25 à 100
• partition de fonction
• Architecture de réseau typique à trois couches : cœur, agrégation et accès.

1.2.4 Architecture typique des grands réseaux de campus

v
1.3 Architecture des réseaux de campus
Dans l'architecture réseau traditionnelle, un réseau a un plan de gestion, un plan

de contrôle et un plan de données.
Le plan de gestion se compose de systèmes de gestion de dispositifs et de
gestion de services. Le système de gestion de dispositifs gère les topologies de réseau,
les interfaces de dispositifs et les fonctionnalités de dispositifs, et peut fournir des
scripts de configuration aux dispositifs. Le système de gestion de service fournit des
fonctions telles que la surveillance des performances de service et la gestion des
alarmes de service.
Le plan de contrôle est responsable du traitement et du calcul du protocole.
Par exemple, les protocoles de routage sont utilisés pour calculer des routes et créer
des tables de routage.
Figure 10 : Architecture typique des grands réseaux de campus
Le plan de données traite et transmet les paquets de service conformément aux
instructions du plan de contrôle. Par exemple, les routeurs transfèrent les paquets de
Un grand
données réseau
reçus via lesdeinterfaces
campus sortantes
peut couvrir plusieurs bâtiments
correspondantes et se connecter
conformément aux tables àde
plusieurs
routage campus
générées pard'une ville via de
les protocoles WANS. En règle générale, un grand réseau de
routage.
campus fournit des services d'accès et permet aux employés en déplacement
d'accéder au réseau interne de leur entreprise grâce à des technologies telles que le
réseau privé virtuel (VPN).
Caractéristiques des grands réseaux de campus :
• Large couverture
• Grand nombre d'utilisateurs :
Nombre de bornes > 2000
Nombre de NE > 100
• Exigences réseau complexes
• Modules fonctionnels complets
• Architecture réseau complexe

Conclusion
Dans ce chapitre nous avons présenté les réseaux de campus et leurs architectures
traditionnelles, dans la suite nous allons montrer les limites de cette architecture et
présenter une solution « le SDN » pour améliorer la gestion de ces réseaux de campus.

CHAPITRE 2 : PRESENTATION DU SDN

Introduction
Récemment, les réseaux programmés par logiciel (SDN, Software-Defined
Networking) ont gagné en popularité dans les milieux industriels et de recherches, un
paradigme qui vient bouleverser la sphère réseau avec la promesse de changer notre
perception de l’infrastructure. Dans ce chapitre nous allons revenir à la source de cette
évolution, comprendre les facteurs qui ont poussé à l’apparition de ce paradigme.
Ensuite nous nous étalerons sur les principes de fonctionnement du SDN, d’Openflow
et de leurs applications les plus significatives.
2.1 Des réseaux traditionnels vers le SDN

2.1.1 Architecture des réseaux traditionnels
À l'intérieur de chaque périphérique réseau et de sécurité, à savoir chaque
commutateur, routeur et pare-feu, vous pouvez séparer le logiciel en quatre couches ou
plans .
Transfert : A pour rôle d'acheminer les paquets réseau. Il est optimisé afin de
déplacer les données aussi rapidement que possible.
Contrôle : Ce plan décide de la direction des flux réseau, il décode les protocoles
pour assurer la fluidité du trafic. Celui-ci se trouve dans un logiciel dédié intimement
relié au hardware.
Services : Cette couche n’existe pas dans les commutateurs. Un exemple de son
utilisation est le pare-feu, elle permet d’exploiter et de déployer des services plus
complexes sur l’appareil en question.
Gestion : Le plan Gestion fournit les instructions de base indiquant comment le

périphérique réseau doit interagir avec le reste du réseau. On y accède par l’interface
de ligne de commande (CLI) pour insérer la configuration du périphérique [1].

Figure 12 : Consternation du plan de contrôle dans un routeur .
2.1.2 Le besoin de faire évoluer les réseaux

D’après Cisco Visual Networking (Cisco VNI, 2017), à l’horizon 2022 le
nombre d’appareils mobiles connectés dépassera le nombre de personnes sur terre à
hauteur de 4,8 milliards mobile par personne. Ce chiffre est représentatif de l’ampleur
exponentielle que prennent les technologies de télécommunication dans la société
moderne, et avec l’avènement d’internet des objets (Internet of Things IoT) tout sera
connecté, ce qui implique une infrastructure réseau d’une complexité ingérable et la
nécessité d’un réseau programmable, réduisant ainsi l’intervention humaine qui est la
source principale des failles dans les réseaux.
L’architecture fondamentale des réseaux traditionnels n’a connu aucun

changement majeur depuis plus de 20 ans. Ce statu quo est en partie dû à l’architecture
des appareils en eux même, le fait est que la coexistence du plan de contrôle et du plan
de données dans chaque équipement physique ce qui rend très difficile tout déploiement
de nouvelle fonctionnalité ou protocole, car ceux-ci doivent être incorporés dans
l’équipement physique, 5 à 10 ans pour concevoir et déployer un protocole de routage.
Cet environnement n’encourage pas le développement, car seuls les fabricants ont accès
au hardware. Mais ce système a aussi créé une dépendance des particuliers envers leurs
fabricants, faute de problèmes d’interopérabilité entre les différentes marques, les
utilisateurs se trouvent comme liés à leurs fabricants et ne peuvent en aucun cas changer
de fournisseur, une atmosphère sans compétitivité et qui encourage la flambée des prix

des appareils réseaux. Ces systèmes renfermés ont instauré une inertie dans le réseau en
comparaison avec l’informatique et les technologies de stockage, et si on devait
s’inspirer de celles-ci et d’un des pionniers du développement de l’informatique qu’est
Linux, l’open source est la meilleure initiative[1].
Mais le point qui force le networking à sortir de sa bulle est le contraste de sa

nature rigide et statique avec les nouvelles techniques dans les data center que ce soit la
virtualisation des machines ou le cloud computing. Ces dernières apportent une
flexibilité sans précédent au déploiement des services et l’exploitation des ressources,
or l’infrastructure réseau opère comme un frein dans ce modèle qui requiert une agilité
particulière, car là où il suffit de quelques minutes pour créer une nouvelle instance
d’une VM, l’ajout d’une instance quelconque dans le réseau pourrait durer des jours.
Ceci crée des problèmes d’extensibilité dans les data center qui sont censés croitre au
besoin. C’est la virtualisation qui fait toute la différence. La tendance du cloud est le «
everything as a service » (Tout en service : Ressources RAM, CPU, Stockage,
Applications …), et la dernière pièce manquante pour le tout virtuel est le « Network as
a service (NaaS) » (Le réseau en service).
Toutes ces limitations ont mené à l’émergence du Software Defined Networking.
2.2 Principes du SDN

2.2.1 Définition
SDN signifie littéralement Software Defined Networking, c’est-à-dire le réseau
défini par logiciel. On comprend donc immédiatement que le sujet est vaste et qu’il va
être difficile d’avoir une définition unique.
La définition académique consistait à voir le SDN comme une architecture qui

découplait les fonctions de contrôle et de transfert des données du réseau afin d’avoir
une infrastructure physique complètement exempte de tout service réseau .
Dans ce modèle, les équipements réseau se contentent d’implémenter des règles,

injectées par les applications, de traitement des flux de données. Plus besoin d’avoir sur
ces équipements de protocoles de routage : une entité intelligente, appelée « contrôleur

» voit le réseau dans sa globalité et injecte directement les règles de traitement des
données sur chaque équipement [1].
Le SDN est donc reconnu aujourd’hui comme une architecture permettant d’ouvrir le
réseau aux applications. Cela intègre les deux volets suivants :
• Permettre aux applications de programmer le réseau afin d’en accélérer le

déploiement ;
• Permettre au réseau de mieux identifier les applications transportées pour
mieux les gérer (qualité de service, sécurité, ingénierie de trafic...).
2.2.2 Architecture du SDN

Le SDN présente une architecture réseau où le plan de contrôle est totalement
découplé du plan de données, cela est illustré par la figure 13.
Figure 13 : Architecture du SDN

La figure ci-dessus présente l’architecture SDN et la place du protocole

Openflow, alors nous observons que SDN se compose de 3 couches :
➢ La couche infrastructure contient les éléments de réseau responsable de

l’acheminement du trafic et qui supportent le protocole OpenFlow qu’ils
partagent avec le contrôleur .
➢ La couche de contrôle est logicielle, basée sur le contrôleur SDN qui offre une
visibilité globale du réseau et des équipements d’infrastructure .
➢ La couche applicative apporte l’automatisation des applications à travers du
réseau, et à l’aide des interfaces programmables.
Ainsi, dans une approche SDN, la charge de calcul associée au contrôleur est en
grande partie retirée des routeurs. Le contrôleur est donc chargé du calcul et de la mise
à jour des tables de routage [2].
2.3 Avantages du SDN

2.3.1 Réseaux programmables
Avec SDN, il est plus simple de modifier les stratégies réseau, car il suffit de changer
une politique de haut niveau et non de multiples règles dans divers équipements de
réseau.
De plus, la centralisation de la logique dans un tel contrôleur entièrement

personnalisé avec des connaissances globales et une puissance de calcul élevée
simplifient le développement des fonctions plus sophistiquées. Cette aptitude à
programmer le réseau est l'élément clé du SDN [2].
2.3.2 Flexibilité
SDN apporte également une grande flexibilité dans la gestion du réseau. Il devient
facile de rediriger le trafic, d'inspecter des flux particuliers, de tester de nouvelles
stratégies ou de découvrir des flux inattendus.

2.3.3 Politique unifiée

Avec son contrôleur, SDN garantit également une politique réseau unifiée et à jour,
puisque le contrôleur est responsable de l'ajout de règles dans les commutateurs, il n'y
a aucun risque qu'un administrateur de réseau ait oublié un commutateur ou installé des
règles incohérentes entre les dispositifs[2].
En effet, l'administrateur va simplement spécifier une nouvelle règle et le contrôleur

adaptera la configuration pour envoyer des règles cohérentes dans chaque dispositif
pertinent.
2.3.4 Routage
SDN peut également être utilisé pour gérer les informations de routage de manière
centralisée en déléguant le routage et en utilisant une interface pour le contrôleur [2].
2.3.5 Gestion du Cloud

SDN permet également une gestion simple d'une plateforme cloud. En effet, la
dynamique apportée par SDN traite des problèmes spécifiques aux clouds tels que
l'évolutivité, l'adaptation, ou des mouvements de machines virtuelles.
2.3.6 Simplification matérielle

SDN a tendance d'utiliser des technologies standard et de base pour contrôler les
équipements du réseau, tandis que la puissance de calcul n'est requise qu'au niveau du
contrôleur. Ainsi, les équipements de réseau deviendront des produits à bas prix offrant
des interfaces standard.
Avec ce type de matériel, il serait également simple d'ajouter de nouveaux

périphériques, puisqu'ils ne sont pas spécialisés, de les connecter au réseau et de laisser
le contrôleur les gérer conformément à la politique définie. Ainsi, le réseau devient
facilement évolutif dès que le contrôleur est évolutif [2].
2.4 Le protocole OpenFlow dans l'architecture SDN

OpenFlow est un protocole de lien entre le plan de contrôle et le plan de données.
L’échange de messages se fait au cours d’une session TCP établie via le port 6633 ou
6335 du serveur contrôleur .

Openflow est donc une composante du SDN, son développement a commencé en

2007 dans le cadre d'une collaboration entre les mondes de l'université et des affaires.
Établie à l'origine par l'université de Stanford et l'université de Californie à Berkeley.
Un switch OpenFlow est déterminé par une ou plusieurs tables de flux (flow table).
Chaque table s’assimile à un ensemble de flux. Lorsqu’un paquet parvient au switch,
les valeurs contenues dans ses en-têtes sont comparées aux différentes règles
enregistrées dans la table de flux du switch [3].
2.4.1 La genèse d’OpenFlow

L’histoire d’OpenFlow est intéressante et permet de mieux comprendre son rôle
fondamental dans la conception de l’architecture SDN.
OpenFlow a été initié comme un projet à l’université de Stanford lorsqu’un groupe

de chercheurs exploraient la manière de tester de nouveaux protocoles dans le monde
IP (créer un réseau expérimental confondu avec le réseau de production) mais sans
arrêter le trafic du réseau de production lors des tests .
C’est dans cet environnement que les chercheurs à Stanford ont trouvé un moyen
de séparer le trafic de recherche du trafic du réseau de production qui utilise le même
réseau IP.
OpenFlow est donc un protocole ouvert (open protocol) qui permet aux
administrateurs de réseau de programmer les tables de flux (flow tables) dans leurs
différents commutateurs, chacun avec son ensemble de fonctionnalités et
caractéristiques de flux [4].
2.4.2 Structure d’un commutateur OpenFlow

Les commutateurs OpenFlow contiennent des tables de flux qui sont utilisées pour
effectuer des fonctions de transfert indiquées dans les en-têtes de paquets [4].
À l'aide de la table de flux, une des actions suivantes est exécutée :
A. Relayer le paquet sur un port de sortie,

B. Supprimer le paquet,

C. Passer le paquet au contrôleur. Le paquet est encapsulé dans un message

OpenFlow PACKET_IN.
Figure 14 : Diagramme de flux des messages OpenFlow
2.4.3 Table de flux

Une table de flux "Flow Table" est composée de plusieurs entrées de flux , chacune
est structurée comme suit :
Figure 15 : Structure d'une table de flux openflow
➢ Champ de correspondance ( Match fields ) : Utilisé lors de la recherche de

l'entrée correspondante au paquet. Ils sont constitués essentiellement des entêtes
des paquets et des ports d'entrées .
➢ Compteurs ( Counters ) : Servent essentiellement à garder des statistiques sur
les flux pour ensuite décider si une entrée de flux est active ou non . Pour chaque
table, chaque flux , chaque port, des compteurs de statistiques sont maintenus.
➢ Instructions : Représentent l'ensemble des instructions OpenFlow qui servent à
modifier le traitement que va subir le paquet. Les instructions supportées sont :
1. Apply-Actions : Pour appliquer les actions sur le paquet immédiatement.
2. Clear-Actions : Pour supprimer une liste des actions du paquet.

3. Write-Actions : Ajouter une liste d'actions au paquet.

4. Write-Metadata : Ajouter des données utiles pour le séquencement entre
les tables OpenFlow.
5. Goto-Table : Indique que le paquet doit être acheminé vers une table
d'indice supérieur.
Figure 16 : Fonctionnement d’une table de flux
Les instructions d'une entrée de flux peuvent explicitement diriger le paquet vers
une autre table de flux "Flow Table" via l'instruction "Goto". Si le paquet ne
correspond à aucune entrée de flux, le comportement du switch vis-à-vis ce paquet
dépendra de la configuration de la table. Le comportement par défaut est d'envoyer le
paquet au contrôleur avec un message PACKET_IN. La table peut aussi spécifier que
dans ce cas, le paquet doit continuer son chemin vers la table suivante . Le contrôleur
répondra généralement par un PACKET_OUT donnant l’instruction à suivre.

Figure 17 : Schématisation du modèle de flux OpenFlow

La figure ci-dessus illustre le traitement d’un paquet parvenant à un switch
OpenFlow contenant une seule table de flux : parmi les différents champs d’en-têtes de
la trame, l’appartenance au VLAN 10 fait correspondre cette trame à un des flux du
switch, dont l’action associée consiste en un transfert par l’interface 1.
2.4.4 Message OpenFlow

Les messages OpenFlow entre le contrôleur et le commutateur sont transmis via un
canal sécurisé, implanté via une connexion TLS sur TCP. Le commutateur initie la
connexion TLS lorsqu’il connaît l’adresse IP du contrôleur. Il existe trois catégories de
message : symétrique, contrôleur-commutateur et asynchrone [4].
❖ Messages symétriques
Les messages symétriques peuvent être émis indifféremment par le contrôleur ou le
commutateur sans avoir été sollicité par l’autre entité. Par exemple, on trouve les
messages HELLO qui sont échangés une fois que le canal sécurisé a été établi.
Les messages ECHO sont utilisés par n’importe quelle entité (contrôleur,
commutateur) pendant le fonctionnement du canal pour s’assurer que la connexion est
toujours en vie et afin de mesurer la latence et le débit courants de la connexion. Chaque
message ECHO_REQUEST doit être acquitté par un message ECHO_REPLY .

❖ Messages asynchrones
Les messages asynchrones sont émis par le commutateur au contrôleur sans que le
commutateur ait été sollicité par le contrôleur. Par exemple, on peut citer le message
PACKET_IN qui est utilisé par le commutateur pour passer les paquets de données au
contrôleur pour leur prise en charge (lorsqu’aucune entrée de flux ne correspond au
paquet entrant ou lorsque l’action de l’entrée correspondante spécifie que le paquet doit
être relayé au contrôleur). Si le commutateur dispose d'une mémoire suffisante pour
mémoriser les paquets qui sont envoyés au contrôleur, les messages PACKET-IN
contiennent une partie de l’en-tête (par défaut 128 octets) , les commutateurs qui ne
supportent pas de mémorisation interne (ou ne disposant plus de mémoire) émettent le
paquet entier au contrôleur dans le message PACKET-IN.
Le commutateur peut informer le contrôleur qu’une entrée de flux a été supprimée

de la table de flux via le message FLOW_REMOVED. Cela survient lorsqu’aucun
paquet entrant n’a de correspondance avec cette entrée pendant un temporisateur
spécifié par le contrôleur lors de la création de cette entrée au niveau de la table de flux
du commutateur.
Le message PORT_STATUS est utilisé afin de communiquer un changement

d’état du port (le lien est hors service). Finalement le commutateur utilise le message
ERROR pour notifier des erreurs au contrôleur .
❖ Messages contrôleur-commutateur
Les messages contrôleur-commutateur représentent la catégorie la plus
importante de messages OpenFlow. Ils peuvent être représentés en cinq sous-
catégories : switch configuration, command from controller, statistics, queue
configuration, et barrier [4].
1. Les messages switch configuration consistent en un message unidirectionnel et

deux paires de messages requête-réponse :
a. Le contrôleur émet le message unidirectionnel SET_CONFIG afin de

positionner les paramètres de configuration du commutateur .

b. Le contrôleur utilise la paire de messages FEATURES_REQUEST et

FEATURES_REPLY afin d’interroger le commutateur au sujet des
fonctionnalités qu’il supporte.
c. La paire de messages GET_CONFIG_REQUEST et
GET_CONFIG_REPLY est utilisée afin d’obtenir la configuration du
commutateur.
2. Les messages command from controller sont au nombre de 3 : PACKET-OUT

est analogue à PACKET_IN mentionné précédemment :
a. Le contrôleur utilise PACKET_OUT afin d’émettre des paquets de

données au commutateur pour leur acheminement .
b. Le contrôleur modifie les entrées de flux existantes dans le commutateur
via le message FLOW_MOD.
c. PORT_MOD est utilisé pour modifier l’état d’un port OpenFlow.
3. Des statistiques sont obtenues du commutateur par le contrôleur via la paire de

messages STATS_REQUEST et STATS_REPLY.
4. La configuration de files d’attente associées à un port n’est pas spécifiée par

OpenFlow. Un autre protocole de configuration doit être utilisé pour ce faire.
Toutefois le contrôleur peut interroger le commutateur via
QUEUE_GET_CONFIG_REQUEST et QUEUE_GET_CONFIG_REPLY
pour apprendre quelle est la configuration des files d’attente associées à un port afin
de pourvoir acheminer des paquets sur des files d’attente spécifiques et ainsi fournir
à ces paquets un niveau de QoS désiré [4].
5. Le message BARRIER_REQUEST est utilisé par le contrôleur pour s’assurer

que tous les messages OpenFlow émis par le contrôleur et qui ont précédé cette
requête ont été reçus et traités par le commutateur. La confirmation est retournée par
le commutateur via la réponse BARRRIER_REPLY .

2.4.5 Les interfaces de communication

Les interfaces de communication ou API permettent au contrôleur d’interagir avec
les autres couches du réseau SDN. On leur attribue la notation Nord/Sud/Est/Ouest
en fonction de la position de la couche avec laquelle communique le contrôleur dans
la hiérarchie de l’architecture. Pour communiquer avec une couche basse (Underlay),
l’interface utilisée est une interface Sud. Inversement pour les couches hautes c’est
une interface Nord. La communication avec d’autres contrôleurs se fait via les
interfaces Est/Ouest.
❖ L’interface Sud
Ce sont les interfaces (South-bound) qui permettent le processus de communication
entre le contrôleur et les switchs/routeurs et autres éléments de la couche
infrastructure réseau. C’est par le biais de cette interface et notamment le protocole
Openflow dans le cas du standard Open SDN (Open Networking Foundation, 2012)
que le contrôleur injecte les différentes politiques aux équipements, et récupère les
informations permettant aux applications de construire une vue globale du réseau .
La figure ci-dessous illustre le type de messages transitant par l’interface sud (ex :
Openflow), lors de l’instauration d’une nouvelle règle sur un switch.
Figure 18 : Processus de communication entre le Switch et le contrôleur

Hormis le standard Openflow, plusieurs protocoles faisant office d’interface sud ont
été développés et sont utilisés dans certaines implémentations appelées SDN à base
d’API. On peut en citer :
▪ Path Computation Element communication Protocol (PCEP)

▪ Interface to Routing System (I2RS)
▪ Simple Network Management Protocol (SNMP)
▪ NETwork CONFiguration protocol (NETCONF)
▪ BGP flow-spec
❖ Interface Nord
Les interfaces Nord (North-bound) servent à programmer les éléments de la
transmission en exploitant l’abstraction du réseau fourni par le plan de contrôle. En
d’autres termes elles permettent la communication entre le contrôleur la couche
applicative. Elles sont considérées davantage comme des API que comme protocole de
programmation et de gestion de réseau. Il n’existe aucun standard intervenant entre la
couche de contrôle et celle d’application. Selon l’ONF (Open Networking Foundation,
2012), plusieurs niveaux d’abstraction et différents cas d’utilisation peuvent être
caractérisés, ce qui signifie qu’il peut y avoir plusieurs interfaces Nord pour servir tous
les cas d’utilisation. Parmi les propositions des industriels, nous trouvons une API basée
sur REST API (REpresentational State Transfer) pour fournir une interface
programmable utilisable par les applications.
❖ Interface Est/Ouest
Ce sont des interfaces inter-contrôleurs, on les trouve dans les architectures
distribués (Multi-contrôleurs). Ils permettent la communication entre contrôleurs pour
synchroniser les états du réseau. Aucun standard n’est encore disponible pour ce type
d’interfaces.

Figure 19 : Communication inter-contrôleur dans une architecture distribuée
2.5 Cas d’utilisations du SDN

Le marché du SDN est en constante évolution depuis son apparition sur la scène
mondiale en 2011, et ceci grâce aux nombreux avantages apportés par la technologie
dans les différents domaines. Ce qui fait que les cas d’utilisations sont très variés et
s’étendent sur toutes les parties du réseau [1].
2.5.1 QoS sur internet

Internet a toujours été une architecture qui ne garantit pas la stabilité, or les
services nouvelle génération de streaming vidéo, VoD ou autre Visioconférence sont
très peu tolérant des délais et erreurs de transmissions et nécessitent donc un réseau
stable pour l’acheminement des paquets. En se basant sur la vue centralisée du réseau
offerte par SDN, on peut sélectionner selon le débit, des chemins différents pour les
divers flux de trafic. C’est à partir de là qu’est né le concept du VSDN (Video over
SDN), une architecture qui détermine le chemin optimal en se basant sur la vue globale
qu’offre la centralisation de contrôle.
2.5.2 Data center

Oracle SDN est un exemple de système qui fournit un réseau virtualisé du data
center. Ce système relie dynamiquement des machines virtuelles avec les serveurs de

réseau. À l’aide de l’interface du gestionnaire d’Oracle Fabric, la configuration et la

surveillance de réseau virtuel sont possibles en tout lieu, et le déploiement de nouveaux
services comme le pare-feu, l’équilibrage de charge et le routage devient à la demande.
Selon Oracle, leur proposition augmente de 30 fois les performances des applications,
et peut faire gagner un débit de serveur à serveur de 80 Gb/s (Oracle, 2015).
2.5.3 Réseaux mobiles

Avec l’avènement imminent de la 5G, les opérateurs se doivent d’optimiser leur
infrastructure de sorte à pouvoir gérer des masses de données de plus en plus
importantes tout en assurant la qualité de service qui accompagne une telle technologie.
Le SDN est une des pièces maitresses qui permettront aux opérateurs d’exploiter le
potentiel de l’infrastructure et permettre d’optimiser les débits au maximum tout en
gardant une importante visibilité sur le comportement de leurs équipements réseau. Une
architecture appelée CSDN (Cellular SDN) a été proposée, c’est une approche qui
utilise les concepts SDN pour une exploitation dynamique et centralisée des ressources,
elle collecte les données des utilisateurs et les conditions du réseau, et les fait remonter
au contrôleur afin d’optimiser la consommation d’énergie, l’utilisation des ressources
et la personnalisation des services aux utilisateurs.
2.5.4 Sécurité
La nature dynamique de SDN a été exploitée par un groupe de chercheurs qui
ont réussi à réduire de 99% le risque de récupération d’information par un analyseur de
paquet externe. Leur approche s’est basée sur une mutation aléatoire et assez fréquente
de l’adresse IP de l’hôte. Des propositions ont été faites et notamment des mécanismes
pour contrer les attaques de déni de service (DDoS), dans l’architecture suggérée, deux
éléments clés ont été exploités : les IDS pour la détection d’intrusions intra-LAN et les
switchs Openflow pour l’isolation dynamique des équipements infectés.

2.5.5 Réseau de campus et d’entreprise

Les dernières années ont été marquées par un changement radical de la
perception des équipements de travail en entreprise et dans les campus universitaires.
En effet la mode BYOD (Bring Your Own Device), ou chaque employée et étudiant
utilise son propre matériel sur le campus, ce qui nous pousse à repenser le réseau pour
y infuser un souffle de flexibilité sans lequel l’administrateur du réseau est très vite pris
de court par la quantité de trafic à gérer manuellement et par les opérations manuelles
qui pourraient permettre de connecter tous les utilisateurs à internet par exemple. Le
SDN dont l’un des avantages est l’automatisation et la programmation des réseaux nous
apparemment comme une évidence pour combler les lacunes des réseaux de campus
qui deviennent de plus en plus complexes [1].
Une des applications les plus intéressantes pour les campus au-delà de la
virtualisation est la programmation d’un réseau conscient d’applications (Application
aware routing). Le nombre d’applications tournant sur les équipements des utilisateurs
est considérable (Réseaux sociaux, streaming audio et vidéo …), ce qui conduit dans la
plupart des cas à une surcharge sur le réseau et peut induire une latence sur les
applications déployées dans un but business ou académique. SDN permet de gérer ces
applications en introduisant des priorités pour les différentes applications et en installant
un équilibreur de charge (Load Balancer), éliminant ainsi toute forme de congestion,
ce qui offre aux professionnels et étudiants un environnement de travail fluide.
Conclusion
Au cours de cette première partie, nous avons fourni une base théorique sur les
réseaux définis par logiciels ( SDN ), en présentant l'architecture et les avantages de ce
dernier, puis nous avons traité les composants essentiels de cette solution afin
d’appliquer ses concepts à notre contexte.

Deuxième Partie : RESULTATS ET DISCUSSIONS

CHAPITRE 3 : DESIGN ET IMPLEMENTATION D’UNE

SOLUTION SDN POUR L’UATM
Introduction
Ce chapitre constitue pour nous l'une des parties essentielles de notre étude. Il a
pour but de détecter et détailler les besoins réels de l'amélioration pour obtenir les
objectifs attendus de la réalisation du projet. Nous voulons comprendre le
fonctionnement actuel du réseau informatique de l’UATM, relever ces insuffisances et
proposer une solution pour l’améliorer.
3.1 Analyse de l’existant

L’étape d’analyse de l’existant nous a permis d’analyser le réseau actuel de
l’UATM pour identifier la meilleure stratégie d’intégration du SDN en son sein.
Le tableau 1 présente les éléments du réseau actuel de l’UATM.

Tableau 1: Matériels réseau de l'UATM (Gbegamey)
Numéro Matériels Marque Nombre
1 Routeur-Wifi Microtik 1
2 Borne wifi Ubiquiti 3
3 Imprimante réseau HP 1
4 commutateur Cisco 2
5 Ordinateur DELL ~50
Les bornes wifi sont réparties entre les membres de l’administration de l’UATM et ses
étudiants. En effet deux bornes wifi sont réservées au personnel de l’UATM, le
troisième est réservé aux étudiants. Chacune de ses bornes wifi a une portée de 4km, ce
qui permet de couvrir une partie importante de l’université.
Le routeur wifi relie toutes les bornes wifi à internet à travers une liaison à fibre
optique de l’opérateur SBIN.

L’imprimante réseau ainsi que les commutateurs sont en train d’être intégrés au réseau.
Cette architecture présentée ne nécessite pas l’intégration du SDN.
3.2 Hypothèses de travail

L’UATM GASA FORMATION comme toute entreprise se doit de tendre vers la
digitalisation dans le contexte actuel de l’évolution des usages du numérique. A cet effet,
plusieurs projets sont identifiés et en cours d’analyse . Au nombre de ces projets, nous
pouvons citer la mise en place d’une plateforme d’e-learning, la consultation en ligne
des mémoires, la numérisation de tout le système d’information.
Ainsi l’architecture à considérer est celle intégrant les infrastructures de ces

plateformes en projet. Dans ce cadre, l’UATM aura besoin de mettre en place des
serveurs, des imprimantes réseau, des plateformes d’e-learning et autres infrastructures
informatiques.
3.2.1 Analyse du besoin

Tableau 2: Besoin en matériels informatique de l'UATM
Matériels Marques Caractéristiques techniques Nb

Serveur Dell CPU I5 : 8,40 GHZ
RAM : 16 Go 5
HDD : 2 To
Ordinateur fixe DELL CPU 4 GHZ Core i7
RAM 16 Go 4
HDD 2 To
Ordinateur portable DELL CPU 4 GHZ 3
RAM 2 Go
HDD 500Go
Imprimantes Laser ML 2160 Print 1
Canon USB parallèle et Ethernet base IT 2

Switch Catalyst 2950 Ethernet 10/100Mbps 16 ports 4

Routeur Cisco Ethernet, wifi, 100Mbps, 4 ports 1

Câble UTP Câble à paire torsadée 1095m
Bande passante 100Mbps

Onduleur APC 650VA 50 minutes 3
Connecteur Rj45 160
Goulotte Dimension 100mmx500mm 250m
Extincteur Hauteur 50 Cm 3
Poids net 50 Kg
Television LG 9000 Btu/h 2
CD S.E unix unix 1
Anti-virus kapersky 50
Pare-feu 1
Le tableau analyse des états de besoin nous montre les matériels dont qui ont servir
à la réalisation du présent projet. Le choix de ce matériel a été poussé par le faite que
nous avons voulu choisir les machines de même marque avec celle que la mairie
possède pour cherche une compatibilité.
3.2.2 La répartition des matériels

L’ architecture logique de l’Université Africaine de Technologie et de Management,
est divisé divisée en dix VLANs, 1 VLAN pour les serveurs,1 VLAN pour les étudiants
et 8 VLANs pour les 8 services qui le compose.
Les 8 services sont les suivants :
1. Comptabilité
2. Informatique
3. Recherche Système industriel
4. LMD
5. OPS (Opération de saisie)
6. SET ( Service Examen et Test)
7. Renseignement

8. Administratif
Le tableau ci-après montre les éléments constitutifs de ses différents services.
Tableau 3 : Répartion de matériels
N° Equipement Nbre Bureaux

01 Ordinateur fixe 1 Informatique
tablette 1
02 Ordinateur fixe 1 Recherche Système industriel
tablette 1
03 Ordinateur fixe 1 OPS (Opération de Saisie)
tablette 1
04 Ordinateur fixe 2 SET ( service Examen et Test)
Ordinateur portable 1
Imprimante 1
05 Ordinateur fixe 3 Renseignement
Imprimante 2
scanneur 1
06 Ordinateur fixe 7 administratif
tablette 1
07 Ordinateur fixe 1 Salle serveurs
08 Ordinateur fixe 1 Comptabilité
tablette 1
09 Ordinateur fixe 2 LMD
tablette 1
1
Ordinateur portable

Le tableau ci-dessus montre la possibilité de positionnement de matériels dans les

différents locaux de l’UATM.
En nous basant sur les services futurs du réseau de l’UATM, l’architecture de

l’existant pourrait se présenter comme illustrée sur la figure 20.
Figure 20 : Architecture traditionnelle proposée
Cette architecture réseau à nécessité l’utilisation de 4 commutateurs d’accès sur

lesquelles sont branchés les différents hôtes. Pour avoir accès à des services comme
internet ou le cloud, le passage vers le cœur du réseau devra se faire via l’un de 3 switchs
de distribution. Ceci fournit aux paquets une multitude de routes et offre une redondance
considérable. Le Core switch LSW5 devra être relié aux ressources externes par un lien
de très large bande passante, vu que tout le trafic sortant du réseau (hôte vers ressources)

y sera acheminé. Nous avons mis des pare-feu au niveau des serveurs, pour éviter qu’il
y’ait des cyberattaques.
L’architecture illustrée au niveau de la figure 20 est divisée en 4 couches:
La couche des terminaux comprend : les ordinateurs, les serveurs, les imprimantes
réseau, les pare-feu, etc.
La couche de réseau d’accès : En tant que couche de périphérie d'un réseau de

campus, cette couche connecte les utilisateurs finaux au réseau.
La couche d’agrégation : est une couche intermédiaire d'un réseau et permet

l'agrégation ou la commutation des données. Certaines fonctions réseau fondamentales,
telles que le routage, la qualité de service et la sécurité, sont également fournies au
niveau de cette couche.
La couche cœur du réseau : est la zone dorsale d'un réseau de campus, qui est le
noyau de commutation de données. Il connecte différentes parties du réseau du campus,
telles que le centre de données, le centre de gestion et la sortie du campus.

3.3 Analyse critique

Le parc informatique de l’UATM compte environ 50 ordinateurs DELL, sur le site
de Gbegamey. Les 8 huit services de l’UATM sont répartis sur les 4 switchs d‘accès.
Au rez de chaussez nous avons les services informatiques, comptabilité,
renseignement, administratif, et le LMD. Au premier étage nous avons les services
OPS,
On note certains points forts aussi bien de point de vue physique que logiques.
Au niveau physique, on note :
- Une redondance des liens ce qui permet d’assurer la haute disponibilité même
en cas de problème sur un lien.
- Une segmentation du réseau en quatre couches ce qui limite les intrusions ;
- Une présence de pare-feu qui protège le réseau de serveurs contre les intrusions
de l’extérieur ;
Au niveau logique, nous remarquons :
- Une exploitation de l’authentification par adresses MAC ;

- La segmentation du réseau en plusieurs VLANs ;
- L’utilisation de l’agrégation de lien , ce qui permet d’accroitre le débit et de
faire en sorte qu’un autre lien prend le relais si un lien tombe en panne
(redondance)
Malgré ces points forts du réseau, nous notons des limitations dont les plus
pertinentes sont :
• Difficultés de déploiement, car on devra configurer chaque périphérique réseau
individuellement ;
• L’utilisation de protocoles complexes, tels que les protocoles IGP, BGP, MPLS
et multidiffusion ;
• La non programmabilitée du réseau, ce qui rendra pénible son administration.
• Difficultés de maintenance vu qu’elle sera effectuée sur chaque machine ayant
un problème ;
• Le cout élevé des équipements à payer ;

De tout ce qui précède, il est nécessaire au regard de l’importance des services

offerts et de la nécessité d’une disponibilité de ces services pour les acteurs de
l’Université (Étudiants, Administration et Enseignants), d’intégrer de nouvelles
technologies dans la gestion de ce réseau en vue d’une disponibilité et d’une facilité
d’administration du réseau et du système d’information de l’UATM. Le SDN vu plus
haut est une solution idéale pour atteindre ces objectifs.
3.4 Proposition d’architecture basée sur le SDN

Nous avons choisi l’approche SDN, car elle permet de simplifier l’architecture
physique des réseaux et d’améliorer leur architecture logique.
Figure 21 : Architecture SDN proposée
Cette architecture est divisée en 3 couches :
La couche des terminaux : est constitués des différents terminaux (serveurs,

imprimantes, ordinateurs, etc);
La couche d’acheminement : cette couche est la base du réseau et est constituée des
switchs physiques standard (utilisant le protocole openflow) et des switchs virtuels.

Le protocole Openflow permet au switch physique de communiquer avec les switchs

virtuels à travers des ports virtuels souvent appelés « br N » avec br pour bridge
(pont) et N pour le numéro du port. Cette capacité permet de réduire
considérablement le cout de déploiement d’un réseau SDN.
La couche de contrôle : est le centre de contrôle du réseau. Il génère des chemins
de commutation internes et des itinéraires de services transfrontaliers et traite les
évènements de changements d’état du réseau.
Les liaisons en bleues représentent le lien d’interconnexion entre :
Les terminaux et les switchs physiques standard, les switchs physiques et les switchs
virtuels.
Les liens en rouge représentent le lien d’interconnexion entre les switchs virtuels et
le contrôleur.
Conclusion
Dans ce chapitre nous avons présenté les limites de l’architecture réseau de
l’UATM et ensuite proposé une solution basée sur SDN pour faciliter la gestion des
ressources réseau de l’UATM. Cette architecture proposée nous servira dans la suite
pour faire nos simulations.

CHAPITRE 4 : SIMULATION DU RESEAU SDN LAN

Introduction
. Dans ce projet nous nous sommes fixé pour objectifs de mettre en place un
serveur web et du loadbalancing sur le réseau, pour faciliter numérisation future de
l’université.
Faute de moyens, le déploiement ne s’est pas fait avec des switchs matériels,
nous avons exploité la nature portable et orientée logiciel du SDN pour implémenter
l’infrastructure dans un environnement virtuel. Cette option est d’autant plus
intéressante pour notre projet vu la richesse des switchs virtuels en possibilités
(correspondances/actions) comparés à leurs équivalents hardware.
4.1 Mise en place des prérequis

Pour pouvoir simuler notre réseau, nous avons eu mettre en place un laboratoire
logiciel constitué de :
1. Lémulateur mininet
2. L’Open Vswitch
3. POX controlleur
4.1.1 Outil d'émulation de réseau : Mininet

Mininet permet de créer, d’interagir, de personnaliser et de partager
rapidement un prototype de réseau définit par logiciel, et offre un chemin fluide
pour fonctionner sur le matériel.
L’outil d’émulation mininet, peut être installer de différente manières :
• Installation de la machine virtuelle Mininet

• Installation native à partir de la source
• Installation native à partir de la source

❖ Configuration utilisée
Afin de bien visualiser le fonctionnement du SDN, nous avons choisi de
procéder à une installation native depuis la source car elle comprends tous les
outils nécessaire à la simulation d’un réseau SDN:
• Nous avons créé une machine virtuelle sous vmware 15 pro, avec une image
iso d’Ubuntu 20.04 ;
• Nous avons mis à jour notre système d’exploitation, nos applications et nos
outils de sécurité via le gestionnaire de paquets apt, en entrant la commande :
sudo apt-get -y update.
• Pour installer mininet nous avons entré les commandes suivantes :
➢ cd mininet
➢ git tag # listes les versions disponibles
➢ git checkout -b mininet-2.3.0 2.3.0 # on a choisi la version 2.3.0
2.3.0
➢ cd..
➢ mininet/util/install.sh -a # pour installer toutes les dépendances de
mininet
❖ Fonctionnement de base du Mininet

Mininet permet avec un simple jeu de commande de réaliser des réseaux
virtuels en utilisant la commande mn :
• Création d'une topologie basique avec la ligne de commande

Démarrons une topologie minimale pour entrer dans l’interface de ligne de
commande.
➢ sudo mn

Une fois dans la CLI de mininet on peut vérifier notre topologie en entrant les
commandes suivantes.
➢ mininet> help # affiche l’aide

➢ mininet> nodes # affiche les nœuds
➢ mininet> nodes # affiche les liens
➢ mininet> dump # Vider les informations sur tous les nœud
❖ Topologies personnalisées
La topologie par défaut est un commutateur unique connecté à deux hôtes et
un contrôleur. Nous pouvons personnaliser la topologie. Deux méthodes sont
possibles.
❖ Utilisation de la CLI
Cet exemple montre comment connecter deux commutateurs directement,
avec un seul hôte hors de chaque commutateur.
➢ $ sudo mn --test pingall --topo single,3 # creation de topologie avec 3

hôtes
Cet exemple montre comment connecter deux switch chacun relié à un hôte .
➢ $ sudo mn --test pingall --topo linear,4# créations de topologie

linéaire avec 2 hôtes et deux commutateurs.

❖ Utilisation d’API python
Mininet prend en charge une simple API Python pour créer des topologies de réseau
personnalisées.
from mininet.topo import Topo

class YoussoufTopo( Topo ):
def build( self ):
"Création de la topologie personnalisée."
# Ajout de terminal, de switch et de lien
leftHost = self.addHost( 'h1' )
rightHost = self.addHost( 'h2' )
leftSwitch = self.addSwitch( 's3' )
rightSwitch = self.addSwitch( 's4' )
self.addLink( leftHost, leftSwitch )
self.addLink( leftSwitch, rightSwitch )
self.addLink( rightSwitch, rightHost )
topos = { 'memoire': ( lambda: MyTopo() ) }
Après, nous avons sauvegardé le code dans un fichier memoire.py, et nous

l’exécutons avec la commande suivante:
➢ $ sudo mn --custom /chemin/vers/memoire.py --topo memoire
4.1.2 Open vSwitch

Open vSwitch est un commutateur logiciel multicouches conçu par Nicira et
supporté par la fondation Linux .
Son implémentation principale étant dans les réseaux virtualisés et les data
center, de par sa mobilité et sa réaction dynamique aux changements d’état, elle

s’étend aux architectures physiques ou Open vSwitch peut être installé sur matériel
open source.
❖ Le commutateur virtuel Open vSwitch

Tout d’abord nous allons procéder à l’installation de Open vSwitch
❖ Installation de Open vSwitch

▪ On charge le module openvswitch et on vérifie s'il est chargé avec le noyau :
➢ $ sudo /sbin/modprobe openvswitch
➢ $ sudo lsmod | grep openvswitch
▪ Initialisation de la BDD (Base de donnée) :

➢ $ sudo mkdir -p /usr/local/etc/openvswitch
➢ $ sudo ovsdb-tool create /usr/local/etc/openvswitch/conf.db
/usr/share/openvswitch/vswitch.ovsschema
▪ On autorise les transferts de paquets IPv4 et IPV6

➢ $ sudo nano /etc/sysctl.conf
➢ $ sudo sysctl -p /etc/sysctl.conf
▪ Quelques commandes de prises en main d’Open vSwitch

• On crée le bridge br0
➢ $ sudo ovs-vsctl add-br br0
• On pourra vérifier si le bridge est bien créé
➢ $ sudo ovs-vsctl show
• On pourra vérifier les ports
➢ $ sudo ovs-vsctl add-port br0 ens33
➢ $ sudo ovs-vsctl add-port br0 ens34
• On pourra retirer les ports
➢ $ sudo ovs-vsctl del-port ens34

4.1.3 Le contrôleur POX

POX est une plate-forme de développement open source pour les applications de
contrôle de réseau défini par logiciel ( SDN ) basées sur Python , telles que les
contrôleurs OpenFlow SDN . POX, qui permet un développement et un prototypage
rapides, est de plus en plus utilisé que NOX , un projet frère.
➢ Les fonctionnalitées de POX sont les suivantes.

➢ Interface « Pythonic » OpenFlow.
➢ Exemples de composants réutilisables pour la sélection de chemin, la découverte
de la topologie, etc.
➢ Fonctionne n’importe où - Peut être associé à l’environnement d’exécution PyPy
sans installation pour un déploiement facile.
➢ Cible spécifiquement Linux, Mac OS et Windows.
➢ Découverte de la topologie.
➢ Prend en charge des outils d’interface graphique et de visualisation .
4.2 Administration d’un réseau SDN

Le paradigme SDN a révolutionné les tâches de l’administrateur réseau de maints
aspects. Les tâches rugueuses qui nécessitaient des connaissances accrues des
protocoles et du langage de l’équipementier sont à présent réalisées par des applications,
ce qui permet la programmation du comportement d’un réseau de manière plus fluide
et automatisée en précisant uniquement la fonction souhaitée.
Ces changements sont accompagnés de possibilités de plus en plus riches en ingénierie

de trafic. La capacité du contrôleur à récupérer les informations et les statistiques du
réseau, combiné aux libertés considérables dans l’orientation des flux de données
offrent des solutions d’optimisations sans précédent.
L’administration du réseau n’est plus limitée par la complexité du matériel. En effet, les
plateformes utilisées pour l’administration du réseau sont basées exclusivement sur
l’open source Linux. Par conséquent, les longues journées passées à configurer les
appareils ligne par ligne, où à chercher la source d’une panne ou d’une latence, ne sont

désormais plus d’actualité. Dans notre exemple nous avons un peu modifié
l’architecture proposée pour l’université pour pouvoir faciliter la réalisation de ce
projet.
4.2.1 Topologie proposée

Pour notre premier exemple, nous avons simplifié la topologie du réseau proposé,
ainsi nous avons choisi d’utiliser 6 machines (deux serveurs web, quatre clients HTTP),
un contrôleur SDN (pox controller), un switch Openflow kernel.
Le switch openflow kernel sera connecté au contrôleur pox, d’où il recevra les
instructions, et pourra gérer les flux de trafic générer par les hôtes qui lui sont connectés.
La partie infrastructure de notre architecture sera customisée et générée sur la

plateforme MininetEdit (interface graphique de mininet). Pour ce faire nous avons
exécuter le script python se trouvant à l’emplacement ~/mininet/examples/miniedit.py.
Celle-ci générera les différents éléments de la couche physique qui sera connectée au
contrôleur pox .
L’architecture ciblée est illustrée dans la figure suivante (architecture réalisée sous
miniedit).
Figure 22 : Topologie proposé pour le loadbalancing

La configuration de base des différents hôtes est fourni dans le tableau suivant
Tableau 4 : Adressage des hôtes
Hôtes Adresse IP
H1 10.0.0.1
H2 10.0.0.2
H3 10.0.0.3
H4 10.0.0.4
H5 10.0.0.5
H6 10.0.0.6
4.2.2 Opération d’administration : Les Policies

Les automatisations sécurisées par la mise en place de politique réseau sont
utilisées dans le SDN pour remplacer le paradigme traditionnel de gestion des réseaux.
L’idée est la suivante mettre en place les policies ou encore politique réseau définies
en fonction des utilisateurs sans se soucier de l’architecture technique et physique du
réseau. Que l’utilisateur soit connecté en filaire en ou wifi à n’importe quel endroit du
réseau, cela ne changera rien, car une politique existe le concernant et elle a été
paramétrée par l’administrateur ou par une application.
Pas de configuration pour chaque élément actif du réseau pour mettre en place des vlans,
des protocoles de routage, ou même les ACL.
4.3.3 Planification du comportement du réseau

Ici nous allons résumer le comportement du réseau.
• Les machines h1 et h2 représentent les serveurs web, pour ce faire nous allons
lancer un script sur ces machines pour les transformer en serveurs web.
• Les machines h3, h4, h5, h6 représentent les clientes HTTP. Lorsqu’elles
vendront accéder au contenu web de GASA, le contrôleur POX les redirigera
vers un serveur (soit h1 ou h2), pour éviter qu’il y est surcharge sur un seul
serveur.

• Si toutes machines devaient accéder à un seul serveur, il pourra être surchargé,

notre but est de configurer le partage de charge entre les deux serveurs HTTP.
4.2.4 Création des serveurs

Pour créer les serveurs nous sommes entrés sur la ligne de commande de mininet en
tapant :
➢ sudo mn --topo single,6 --controller=remote,port=6633
On obtient en sortie l’image ci-dessous
Figure 23:Connexion à la CLI de mininet
Ensuite nous avons lancé la commande xterm pour lancer nos deux machines que nous
allons transformer en serveur web, avec la commande :
➢ python3 -m http.server # on peut préciser le port en entrant son numéro

Figure 24 : Création de machine serveur
Nous nous sommes rendus dans le dossier où se trouve notre contrôleur pox, puis nous
avons lancé le script python de loadbalancing.
➢ pox.py log.level --DEBUG misc.ip_loadbalancer --ip=10.0.1.1 --

servers=10.0.0.1,10.0.0.2
Ce qui nous donne en sortie.
Figure 25 : Mise en place du loadbalancing sur le contrôleur
On note ici que les adresses IP des serveurs h1= 10.0.0.1 et h2 = 10.0.0.2 ont été
transformés en 10.0.1.1. En effet ces deux serveurs partagent la même adresse IP pour
permettre le loadbalancing et pour sécuriser le réseau.

4.3 Test de fonctionnement

Nous allons à présent faire des tests de pour voir si nos clients HTTP peuvent se
connecter aux serveurs web, à travers le contrôleur d’une part et voir si le contrôleur va
permettre le partage de charge entre les deux commutateurs. Pour cela nous avons
effectué deux tests.
4.3.1 Test de connectivité

Ici nous avons vérifié si nos deux serveurs sont joignables.
Figure 26 : Requêtes des clients

Figure 27 : Réponse des serveur
Lorsque nous avons entré la commande : curl 10.0.1.1, on arrive à pu voir la page web
enregistré sur les serveurs (la page par défaut est un code html).
Comme le montrent les images ci-dessus nous avons accédé 25 fois aux serveurs web,
13 requêtes sont reçues par le serveur h1 et 12 requêtes par le contrôleur h2.

4.4.2 Test de loadbalancing

Ici nous allons voir si notre contrôleur arrive à voir les paquets et applique le partage de
charge.
Les serveurs utilisent la même adresse IP, lorsqu’on essaie de se connecté à l’adresse
IP =10.0.1.1 le contrôleur voir les paquets et décide du serveur qui va recevoir la requête.
Il fait ainsi de la redirection de paquets et permet de faire le loadbalancing. De plus
lorsqu’on essaie d’accéder aux serveurs grâce à leurs propres adresses IP le contrôleur
leurs bloquent l’accès, ce qui permet de ne pas surcharger intentionnellement un serveur.
Conclusion
Dans ce chapitre, nous avons exploité mininet, Pox et OpenFlow. Notre contribution
principale est la mise en place d’une politique d’accès aux serveurs des entreprises dans
un environnement SDN, pour cela nous avons programmé le comportement du réseau
pour montrer le côté programmable de la SDN. Les résultats des tests ont montré la

fiabilité de cette méthode à gérer efficacement le partage de charge. En effet nous avons
pu équilibré les trafics sur les différents serveurs .

CONCLUSION GENERALE
Notre objectif dans ce travail est de comprendre ce que représentait le SDN, pour
ensuite l’implémenter et en déduire son apport sur le comportement du réseau tout en
testant sa fiabilité.
Le premier constat à prélever est le manque cruel de standardisation. Nous avons

rencontré au court de notre étude bibliographique d’innombrables définitions sur ce
qu’est ou ce que devrait être le SDN. Par contre l’objectif de celui-ci reste clair et unifié ;
apporter une plateforme de contrôle et de programmation pour la communication et le
déploiement de services automatisés, simplifier les périphériques réseau et accélérer le
développement en adoptant le modèle Open Source de linux. Le seul standard à l’heure
actuelle reste OpenFlow, qui a ouvert les discussions sur le SDN, avec l’idée de
découplage du plan de contrôle et du plan de données. Malgré son déploiement massif
par les plus grandes sociétés (Google, Microsoft, Facebook, Amazon …), il reste tout
de même à l’état embryonnaire dans sa façon d’aborder les applications.
Dans ce projet nous avons choisis l’implémentation du modèle Openflow, en

l’intégrant dans un environnement virtuel. L’un des points forts de celui-ci est la facilité
de son déploiement grâce notamment à la portabilité du switch OVS, qui peut
fonctionner en virtuel ou être installé sur du très simple matériel (Rasberry,
whitebox …). L’étude s’est ensuite focalisée sur le contrôleur POX d’OpenFlow, il
offre diverses fonctionnalités et permet la programmablilitée du réseau. Ainsi nous
l’avons utilisé pour faire du programmé le réseau à faire du loadbalancing, ce qui permet
la gestion plus efficace des ressources réseaux.
Ce projet a été pour nous une chance et une formidable opportunité de découvrir
un réseau reposant sur les technologies SDN avec une console centrale et des outils «
intelligents », capables de prendre en charge une grande partie de ces tâches fastidieuses.
La programmabilitée opérée par le SDN est la chose la plus étonnante que nous
avons pu voir dans notre projet. Nous avons, par exemple, passé peu de temps à créer
une topologie réseau en utilisant des outils d'émulation puis connecté cette topologie
avec un contrôleur SDN, l’automatisation limitant alors les risques d’erreurs humaines.

Ainsi, pouvoir proposer des équipements ou technologies basées sur le SDN devient
une priorité et nous citons quelques rapprochement ou rachat de petites startups
spécialisées dans le SDN par les grands acteurs des réseaux et du logiciel : Oracle
rachetant la startup Xsigo qui offre des services réseaux basés sur le SDN, Juniper
s’alliant à la société Contrail, Cisco se rapprochant de la société Insiemi. Des acteurs
comme HP se sont intéressés très tôt au SDN et se positionnent aujourd’hui parmi les
leaders du marché.
Perspectives
Découvrir le SDN a été un vrai plaisir. L’automatisation ouvre tellement de nouvelles
perspectives. Pour cela, il serait intéressant dans le futur d'appliquer notre projet sur le
réseau physique de l’UATM GASA FORMATION.
Problèmes rencontrés
1- Au début nous avons trouvé le sujet un peu vaste , et la difficulté était de trouver
une structure à notre projet
2- En ce qui concerne Mininet, le fait d’avoir très peu de référence qui explique le
fonctionnement et surtout l’architecture de cette plateforme , rend la
compréhension un peu difficile
3- Des bugs dans le fonctionnement de Mininet . qui ne sont pas expliquées dans
mininet.org - Par exemple, si on un a un réseau qui comporte plusieurs hosts , et
on veut ouvrir un Xterm à H1, mais cela ne fonctionne pas.
4- Des bugs lors de l’installations du contrôleur Opendaylight, que nous n’avons
pas pu utiliser.
5- Incompatibilité entre les informations fournies sur internet et notre propre
configuration.

REFERENCE BIBLIOGRAPHIQUES
Ouvrages :
[1] AICHAOUI Anis Mr AITBELKACEM Yanis << Etude et implémentation d’une

architecture SDN LAN>>, Mémoire de Fin d’Etudes De MASTER ACADEMIQUE
Filière : Télécommunications Spécialité : Réseaux et Télécommunications, Soutenu le :
04/07/2018.
[2] Mme BOUIDA Hafida née SAIDI, Etude et mise en oeuvre d'une solution SDN :
Application de Gestion de VLANs : Mémoire de fin d’études pour l’obtention du
diplôme de Master en Informatique Option: Réseaux et Systèmes distribués (R.S.D ),
Présenté le 12 Juin 2017
[3] Traore Issa, Kouassi Brou Médard, et Atta Ferdinand, « Etude du nomadisme dans
un Cloud éducatif administré par la technologie SDN/OpenFlow », Institut de
recherches mathématique Université Félix Houphouët-Boigny, conférence WACREN
2016.
[4] Enric Caceres, « Le Protocole OpenFlow dans l’Architecture SDN », EFORT 2016.
[5] Cisco VNI. (2017). Global Mobile Data Traffic Forecast Update, 2016–2021 (livre
blanc)
[6] Cisco. (2013). Cisco Global Cloud Index: Forecast and Methodology, 2013–2018.
Livre blanc.
[7] Cocker, O., & Azodomolky, S. (2017). Software Defined Networking with
Openflow. Packt Publishing. Seconde édition. Birmingham, Royaume uni.
[8] Dubey, N. (2016). From Static Network to software-defined networking. Icasa
journal. vol4. disponible.pdf
[9]Huawei Technologies; HCIP -Datacom-Core-Technology (2021); Chapter 1.
[10] Huawei Technologies; HCIA -Datacom-Technology (2020); Chapter 22.

Liens Web
[11]https://www.journaldunet.com/ebusiness/telecoms-fai/1119471-les-trois-
grandes-tendances-des-reseaux-d-entreprise/ 17/07/2022 18 H: 15 min
[12] Télécharger/Démarrer avec Mininet - Mininet 17/07/2022 19h13min

[13] Procédure pas à pas Mininet - Mininet 17/07/2022 19h34min
[14] Installez OpenDaylight sur Ubuntu 20.04 LTS (toutes les fonctionnalités, n’importe
quelle version) (soban.ski) 17/07/2022 22h34min

Annexe: Installer le contrôleur POX

Nous avons choisi utilisé la version de POX , contenu dans mininet.
1. Pré-requis
• La façon la plus simple pour commencer avec Mininet est de

télécharger une machine virtuelle préinstallée sous Ubuntu.
• Cette machine virtuelle comprend Mininet lui-même, tous les

binaires OpenFlow et les outils préinstallés, et ajuste la
configuration du noyau pour prendre en charge les grands
réseaux Mininet.
2. Téléchargement
• Télécharger la machine virtuelle à partir du lien :
https://github.com/mininet/mininet/wiki/Mininet-VM-Images
• Télécharger et installer un système de virtualisation. Le système

le plus recommandé et que nous l'avons utilisé est VirtualBox,
il est gratuit et il peut fonctionner sous windows et sous linux.
Réalisé par BADAROU Youssouf Adjassa I

• Utiliser le compte : mininet avec le mot de passe mininet pour

se connecter au système.
3. Accédez au controlleur pox
Lorsqu’on installe mininet avec toutes ces dépendances, plus besoin

d’installation supplémentaire pour accéder au contrôleur POX. On peut directement y
accéder dans le répertoire : /mininet/pox.
Réalisé par BADAROU Youssouf Adjassa II

TABLE DES MATIERES

AVERTISSEMENT ...................................................................................................................................... i
DEDICACE ................................................................................................................................................ ii
REMERCIEMENTS ................................................................................................................................... iii
SOMMAIRE ............................................................................................................................................. iv
LISTE DES SIGLES ET ABREVIATIONS ...................................................................................................... vi
LISTES DES FIGURES ............................................................................................................................. viii
LISTE DES TABLEAUX .............................................................................................................................. ix
RESUME................................................................................................................................................... x
ABSTRACT............................................................................................................................................... xi
Contexte et Justification ....................................................................................................................... xii
INTRODUCTION GÉNÉRALE ................................................................................................................. - 1 -
PROBLÉMATIQUE .................................................................................................................................... 2
OBJECTIFS................................................................................................................................................ 2
Objectif général................................................................................................................................... 2
Objectifs spécifiques ........................................................................................................................... 2
Première Partie : État de l'art des réseaux de campus ................................................................. 3
CHAPITRE 1 : LES RESEAUX TRADITIONNELS DE CAMPUS ...................................................................... 4
Introduction ........................................................................................................................................ 4
1.1 Les équipements réseau ............................................................................................................... 4
1.1.1 Les équipements modulaires ................................................................................................. 4
1.1.2 Les équipements fixes ............................................................................................................ 6
1.2 Architecture des réseaux de campus ............................................................................................ 7
1.2.1 Architecture générale d’un réseau de campus ...................................................................... 8
1.2.2 Architecture typique des petits réseaux de campus ........................................................... 10
1.2.3 Architecture typique des réseaux de campus de taille moyenne ................ 11
Conclusion ......................................................................................................................................... 13
CHAPITRE 2 : PRESENTATION DU SDN .................................................................................................. 14
Introduction ...................................................................................................................................... 14
2.1 Des réseaux traditionnels vers le SDN ........................................................................................ 14
2.1.1 Architecture des réseaux traditionnels ................................................................................ 14
2.1.2 Le besoin de faire évoluer les réseaux ................................................................................. 15
2.2 Principes du SDN ......................................................................................................................... 16
2.2.1 Définition....................................................................................................................... 16
Réalisé par BADAROU Youssouf Adjassa III

2.2.2 Architecture du SDN ..................................................................................................... 17

2.3 Avantages du SDN ....................................................................................................................... 18
2.3.1 Réseaux programmables............................................................................................... 18
2.3.2 Flexibilité ....................................................................................................................... 18
2.3.3 Politique unifiée ............................................................................................................ 19
2.3.4 Routage ......................................................................................................................... 19
2.3.5 Gestion du Cloud ........................................................................................................... 19
2.3.6 Simplification matérielle ............................................................................................... 19
2.4 Le protocole OpenFlow dans l'architecture SDN ....................................................................... 19
2.4.1 La genèse d’OpenFlow .................................................................................................. 20
2.4.2 Structure d’un commutateur OpenFlow....................................................................... 20
2.4.3 Table de flux .................................................................................................................. 21
2.4.4 Message OpenFlow ....................................................................................................... 23
2.4.5 Les interfaces de communication ................................................................................. 26
2.5 Cas d’utilisations du SDN ............................................................................................................ 28
2.5.1 QoS sur internet ............................................................................................................ 28
2.5.2 Data center.................................................................................................................... 28
2.5.3 Réseaux mobiles ........................................................................................................... 29
2.5.4 Sécurité ......................................................................................................................... 29
2.5.5 Réseau de campus et d’entreprise ............................................................................... 30
Conclusion ......................................................................................................................................... 30
Deuxième Partie : RESULTATS ET DISCUSSIONS ............................................................................ 31
CHAPITRE 3 : DESIGN ET IMPLEMENTATION D’UNE SOLUTION SDN POUR L’UATM ........................... 32
Introduction ...................................................................................................................................... 32
3.1 Analyse de l’existant ................................................................................................................... 32
3.2 Hypothèses de travail ................................................................................................................. 33
3.2.1 Analyse du besoin ................................................................................................................ 33
3.2.2 La répartition des matériels ................................................................................................. 34
3.3 Analyse critique........................................................................................................................... 38
3.4 Proposition d’architecture basée sur le SDN .............................................................................. 39
Conclusion ......................................................................................................................................... 40
CHAPITRE 4 : SIMULATION DU RESEAU SDN LAN ................................................................................. 41
Introduction ...................................................................................................................................... 41
4.1 Mise en place des prérequis ....................................................................................................... 41
4.1.1 Outil d'émulation de réseau : Mininet ................................................................................. 41
.......................................................................................................................................................... 42
Réalisé par BADAROU Youssouf Adjassa IV

4.1.2 Open vSwitch ................................................................................................................ 44

4.1.3 Le contrôleur POX .................................................................................................................... 46
4.2 Administration d’un réseau SDN................................................................................................. 46
4.2.1 Topologie proposée ...................................................................................................... 47
4.2.2 Opération d’administration : Les Policies ..................................................................... 48
4.3.3 Planification du comportement du réseau ................................................................... 48
4.2.4 Création des serveurs ................................................................................................... 49
4.3 Test de fonctionnement.............................................................................................................. 51
4.3.1 Test de connectivité ...................................................................................................... 51
4.4.2 Test de loadbalancing ................................................................................................... 53
Conclusion ......................................................................................................................................... 53
CONCLUSION GENERALE ....................................................................................................................... 55
Perspectives .......................................................................................................................................... 56
Problèmes rencontrés........................................................................................................................... 56
REFERENCE BIBLIOGRAPHIQUES ........................................................................................................... 57
Liens Web .............................................................................................................................................. 58
Annexe: Installer le contrôleur POX ......................................................................................................... I
Réalisé par BADAROU Youssouf Adjassa V

Memoire BADAROU Youssouf Master2 SDN LAN Corrigé Corrigé Final PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire BADAROU Youssouf Master2 SDN LAN Corrigé Corrigé Final PDF

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU BENIN

MEMOIRE DE FIN DE FORMATION POUR L’OBTENTION

MISE EN PLACE D’UNE SOLUTION SDN POUR

BADAROU Youssouf Adjassa

Année Académique : 2021-2022

L’Université Africaine de Technologie et de Management (UATM/GASA

Réalisé par BADAROU Youssouf Adjassa i

Je dédie le présent mémoire à mes parents Sefou BADAROU et

BADAROU Youssouf Adjassa

Réalisé par BADAROU Youssouf Adjassa ii

Nos sincères remerciements vont également à l’endroit de :

• Monsieur Théophane AYI, le président directeur général de l’UATM / GASA

• Monsieur Florentin Y. AGOSSOU, mon Directeur de mémoire pour avoir accepté

• Messieurs Lafitte NGUEMEGNE et Marc-Aurel AKPONNA et tout le personnel

• Tout le Corps enseignant de l’UATM pour les connaissances transmises ;

• Tous ceux qui de près ou de loin ont contribué à la réalisation de ce mémoire.

Réalisé par BADAROU Youssouf Adjassa iii

Réalisé par BADAROU Youssouf Adjassa iv

3.4 Proposition d’architecture basée sur le SDN .............................................................................. 39

Réalisé par BADAROU Youssouf Adjassa v

LISTE DES SIGLES ET ABREVIATIONS

Réalisé par BADAROU Youssouf Adjassa vi

OFM: Open Flow Manager

Réalisé par BADAROU Youssouf Adjassa vii

LISTES DES FIGURES

Réalisé par BADAROU Youssouf Adjassa viii

LISTE DES TABLEAUX

Tableau 1: Matériels réseau de l'UATM (Gbegamey) ..................................................................... 32

Réalisé par BADAROU Youssouf Adjassa ix

Mots-clés : SDN, OpenFlow, OFM, Contrôleur, POX.

Réalisé par BADAROU Youssouf Adjassa x

Keywords: SDN, OpenFlow, OFM, Controller, POX.

Réalisé par BADAROU Youssouf Adjassa xi

Limites des réseaux traditionnels :

• Sur un réseau traditionnel, un système de gestion de réseau est généralement

Réalisé par BADAROU Youssouf Adjassa xii

L’objectif de ce travail est de faciliter gestion des réseaux locaux d’entreprises.

Réalisé par BADAROU Youssouf Adjassa -1-

dernier chapitre, nous présenterons notre contribution par une simulation de la

Ce problème principale peut être divisée en de petits problème à savoir :

• Coûts élevé en matière de matériels et logiciels lourds pour les entreprises.

• Permettre une gestion simple et centralisée du réseau,

Réalisé par BADAROU Youssouf Adjassa -2-

Première Partie : État de l'art des réseaux de campus

Réalisé par BADAROU Youssouf Adjassa 3

CHAPITRE 1 : LES RESEAUX TRADITIONNELS DE

1.1 Les équipements réseau

1.1.1 Les équipements modulaires

Réalisé par BADAROU Youssouf Adjassa 4

Nous utiliserons un S12700E-8 pour décrire l’architecture traditionnelle d’un

Figure 2 : Panneau typique d'un équipement réseau

Main Processing unit (MPU) : il est responsable du plan de contrôle et du plan

➢ Le SFU Figure 3 : MPU

Switch Fabric Unit (SFU) : il est responsable du plan de donnée de tout le

Réalisé par BADAROU Youssouf Adjassa 5

1.1.2 Les équipements fixes

Figure 5 : Équipement non modulaire

Réalisé par BADAROU Youssouf Adjassa 6

1.2 Architecture des réseaux de campus

Figure 6 : Panorama d'un Campus Network

Réalisé par BADAROU Youssouf Adjassa 7

1.2.1 Architecture générale d’un réseau de campus

Figure 7 : Architecture générale d’un réseau de campus