Sunteți pe pagina 1din 75

INSTITUT AFRICAIN D’INFORMATIQUE SOCIETE INFORMATIQUE APPLIQUE RESEAU ET SECURITE

_______________________ _______________________

AFRICAN INSTITUTE OF COMPUTERS SCIENCE COMPUTER APPLIED NETWORK AND SECURITY

BP : 15052 Yaoundé, Cameroun


____________________
BP : 13719 Yaoundé, Cameroun Tel :(+237) 695 549 714/678 080 502
____________________ __________________
Tel :(+237) 242 72 99 58/242 72 99 57 Site web : www.sinaress.com
__________________ ____________________
Site web : www.iaicameroun.com Email : sinares.sales@gmail.com
____________________
Email : contact@iaicameroun.com

RAPPORT DE STAGE

THEME :

IMPLEMENTATION D’UNE ACHITECTURE


SDN LAN : cas SENARES

En vue de l’obtention d’un diplôme de travaux informatiques option système réseau


Stage réalisé du 10 aout au 30 septembre 2020

Rédigé par : NJIMOLUH MOUSTAPHA Said

Sous la supervision :

Académique de :
Professionnelle de :
Dr DJOUSSE Hugues Marceluce
Enseignant à l’IAI-CAMEROUN

Année académique
2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : cas SENARES

DEDICACES

Je dédié ce travail principalement à ma défunt maman qui ne sera hélas pas présente pour
partager mon stress et ma joie le jour de la soutenance, j’espère simplement qu’elle est fière
de moi !!
A mon papa même si aucune dédicace ne saurait exprimer ma profonde gratitude et ma vive
reconnaissance envers tous les sacrifices qu’il a faits pour moi.
A mes frères et sœurs, mes neveu et nièces,
Ainsi qu’à toute ma famille : petits et grands
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

REMERCIEMENTS

La réussite d’un projet ne saurait être l’œuvre d’une seule personne, qu’il nous soit
permis de nous acquitter d’une dette de reconnaissance auprès de toutes ces personnes, qui ont
apporté d’une certaine manière, leur part de pierre à l’édifice. Ainsi, nous tenons
particulièrement à leur affirmer notre reconnaissance. Il s’agit de :

 M. Armand Claude ABANDA, Représentant Résident de l’IAI-Cameroun, pour la


qualité de formation reçue durant ces trois années ;
 M. Jérémie Serge WOUANSI TOW, Directeur Général de SENARIS qui nous a
offert l’opportunité d’effectuer notre stage dans son entreprise ;
  M. …………
 Dr Hugues Marceluce DJOUSSE, notre encadreur pédagogique de stage pour sa
disponibilité, son suivi, ses conseils et remarques, qui nous ont permis la réalisation à
terme de ce projet ainsi que tout le corps administratif et professoral de l’IAI-
Cameroun pour l’encadrement qu’ils ne cessent de nous prodiguer ;
 Ma grande sœur la Reine Chetou NJOUPOUO, aucune dédicace ne saurait exprimer
mon amour et ma considération pour les sacrifices que tu as consenti pour mon
instruction et mon bien être ;
 A tous mes grands frères et sœurs MOUSTAPHA pour tous leurs soutiens
multiformes ;
 A tous mes camarades pour les moments partager durant ces trois années ;
 A tous ceux, qui de près ou de loin, ont contribué à la réalisation à terme de ce travail,
qu’ils trouvent ici, l’expression de nos sentiments les plus distingués, et nos vœux les
plus sincères.

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
II
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

SOMMAIRE

DEDICACES...............................................................................................................................I

REMERCIEMENTS..................................................................................................................II

SOMMAIRE.............................................................................................................................IV

LISTE DES TABLEAUX ET FIGURES.................................................................................VI

RESUME...................................................................................................................................V

ABSTRACT.............................................................................................................................VI

PARTIE I : DOSSIER D 'INSERTION......................................................................................1

INTRODUCTION..............................................................................................................2

I. ACCUEILLE................................................................................................................2

II. PRESENTATION DE LA STRUCTURE...............................................................2

CONCLUSION...................................................................................................................8

PARTIE II : DOSSIER TECHNIQUE.......................................................................................9

CHAPITRE I : ANALYSE DU PROJET.............................................................................10

I. PRESENTATION DU THEME.................................................................................10

II. ETUDE DE L’EXISTANT....................................................................................10

III. PROBLEMATIQUE..............................................................................................13

CHAPITRE II : CAHIER DES CHARGES.........................................................................14

INTRODUCTION............................................................................................................14

I. OBJECTIFS...............................................................................................................14

II. EXPRESSION DES BESOINS DE L’UTILISATEUR.........................................14

III. LES ACTEURS DU PROJET................................................................................15

IV. LES CONTRAINTES DU PROJET......................................................................15

V. CONTEXT..............................................................................................................15

VI. PLANIFICATION..................................................................................................16

VII. EVALUATION FINANCIERE.............................................................................16

CHAPITRE III : ETAT DE L’ART.....................................................................................19

Rédigé par : NJIMOLUH MOUSTAPHA IV


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

I. ETAT ACTUEL DES RESEAUX.............................................................................19

II. ARCHITECTURE DES NŒUDS RE....................................................................20

III. LE SOFTWARE DEFINED NETWORK..............................................................21

IV. CAS D’UTILISATION DU SDN..........................................................................31

V. COMPARAISON ENTRE LE RESEAU TRADITIONNEL ET LE SDN...........32

CHAPITRE IV : IMPLEMENTATION DE LA SOLUTION.............................................33

INTRODUCTION............................................................................................................33

I. CHOIX DU CONTROLEUR.....................................................................................33

II. PuTTY....................................................................................................................39

III. INTEGRATION DE L’APPLICATIONOPENFLOW MANAGER ODL...........42

IV. MININET...............................................................................................................44

V. INSTALLATION DE WIRESHARK DANS MININET......................................54

CHAPITRE V : TEST DE LA SOLUTION.........................................................................55

I. PLANIFICATION DU COMPORTEMENT DU RESEAU.....................................55

II. TEST DE FONCTIONNEMENT..........................................................................57

CONCLUSION.................................................................................................................59

ANNEXE..............................................................................................................................60

BIBLIOGRAPHIE................................................................................................................61

GLOSSAIRE.........................................................................................................................62

Rédigé par : NJIMOLUH MOUSTAPHA V


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

LISTE DES TABLEAUX ET FIGURES

Tableau 1: ressources matérielles.............................................................................................10


Tableau 2 : ressources logicielles.............................................................................................11
Tableau 3: Ressource humaine.................................................................................................17
Tableau 4 : Ressource matérielles et logiciels..........................................................................17
Tableau 5: Montant du projet....................................................................................................18
Tableau 6:Comparaison entre le réseau traditionnel et le SDN................................................32
Tableau 7: Tableau comparatif OpenDaylight et Floodlight....................................................34
Tableau 8 :Adresse des hôtes....................................................................................................48
Tableau 9 : tableau des flux OpenFlow 1.................................................................................55
Tableau 10 : tableau des flux OpenFlow 2...............................................................................56
Tableau 11 : tableau de flux OpenFlow 3.................................................................................56

Figure 1: Organigramme de la structure.....................................................................................6


Figure 2: plan de localisation......................................................................................................7
Figure 3 : architecture réseau....................................................................................................11
Figure 4 : diagramme de Gant..................................................................................................16
Figure 5 : informatique dans le nuage.......................................................................................17
Figure 6 : architecture routeur...................................................................................................20
Figure 7 : objectif SDN.............................................................................................................21
Figure 8: modèle de programmabilité.......................................................................................23
Figure 9 : architecture SDN......................................................................................................24
Figure 10 : Processus de communication entre le Switch et le contrôleur...............................25
Figure 11 : Communication inter-contrôleur dans une architecture distribuée........................26
Figure 12 : Architecture OpenFlow..........................................................................................27
Figure 13 : Pipeline OpenFlow v1.1.........................................................................................27
Figure14 : Entrée de flux..........................................................................................................28
Figure 15 : Champs de correspondance OpenFlow v 1.0.........................................................28
Figure 16: Schématisation du modèle de flux...........................................................................29
Figure 17 : Anatomie logique d’un switch SDN.....................................................................31
Figure 18 : Contrôleur SDN : éléments, services et interfaces.................................................33
Figure 19 : Architecture SDN avec un orchestrateur................................................................34

Rédigé par : NJIMOLUH MOUSTAPHA VI


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 20 : communauté ODL..................................................................................................37


Figure 21 : ODL lithium...........................................................................................................39
Figure 22 : virtual box...............................................................................................................40
Figure 23 : ODL lancer.............................................................................................................42
Figure 24 : login ODL...............................................................................................................42
Figure 25 : GUI ODL................................................................................................................43
Figure 26 : structure OFM........................................................................................................44
Figure 27: topologie vue GUI ODL..........................................................................................50
Figure 28 : topologie vue GUI OFM........................................................................................51
Figure 29 : installation de l'entrée flux 102..............................................................................54
Figure 30 : test d'accessibilité des hôtes...................................................................................55
Figure 31 : capture wireshark d'un ping entre h1 et h2.............................................................56
Figure 32 : capture wireshark d'un ping entre h2 et h4.............................................................56
Figure 33 : capture wireshark d'un ping entre h4 et h5.............................................................56
Figure 34 : détection de la perte de liaison s1 s5 ODL.............................................................57
Figure 35 : capture wireshark test de redondance.....................................................................57

Rédigé par : NJIMOLUH MOUSTAPHA VII


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

RESUME

Notre stage s’est déroulé au sein de SENARIS. Durant notre phase d’insertion dans
cette entreprise d’intégration open source, de fourniture de services et biens informatiques
basés sur les technologies à la pointe, il nous a été demander d’étudier la nouvelle technologie
SDN – Software-Defined Networking – qui est certainement le sujet chaud qui agite le monde
du réseau depuis ces dernières années. Elle a déclenché un changement radical à long terme
dans la conception des réseaux, et le marché s’est rapidement approprié de cette technologie
comme ensemble de solutions/architectures permettant de supprimer les frontières existantes
entre les mondes des applications et du réseau. C’est dans cet optique que nous avons choisir
d’implémenté une architecture SDN LAN. Dans ce rapport nous avons présenté le contexte de
genèse du SDN, l’architecture, les différents modèles qui se développent en parallèle pour
mieux répondre à des usages spécifiques, les contrôleurs et orchestrateurs, les cas
d’utilisations du SDN, une comparaison entre l’architecture traditionnelle et le SDN. Au cours
d’une étude comparative entre le contrôleur OpenDaylight et Floodlight, notre choix s’est
porté sur OpenDaylight dans laquelle nous avons intégré l’application OpenFlow manager
pour la gestion des flux. Ceci dans le but d’avoir un réseau programmable et une gestion
centraliser.

Rédigé par : NJIMOLUH MOUSTAPHA V


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

ABSTRACT

Our internship took place within SENARIS. During our insertion phase in this open
source integration company, providing IT services and goods based on cutting-edge
technologies, we were asked to study the new SDN technology - Software-Defined
Networking - which is certainly the hot topic which agitates the world of the network for
these last years. It triggered a long-term radical change in network design, and the market
quickly adopted this technology as a set of solutions / architectures to remove the existing
boundaries between the application and network worlds. It is with this in mind that we have
chosen to implement an SDN LAN architecture with a flow management application. In this
report we have presented the context of the genesis of SDN, the architecture, the different
models that are developing in parallel to better meet specific uses, the controllers and
orchestrators whose mission is to provide a layer of network abstraction and the OpenFlow
manager application.

Rédigé par : NJIMOLUH MOUSTAPHA VI


Centre d’excellence technologique PAUL BIYA, Année 2019-2020
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

PARTIE I : DOSSIER D 'INSERTION

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

1
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

INTRODUCTION

Le dossier d’insertion est la partie du rapport de stage où, nous étudiants


présentons comment nous avons été accueillis dans notre lieu de stage. Dans cette partie nous
présentons également comment l’entreprise est structurée. Dans le cadre de notre formation
professionnelle dans le domaine des Systèmes et Réseaux, l’entreprise qui a retenu notre
attention et qui a bien voulu nous permettre d’effectuer un stage dans ses locaux afin d’asseoir
les connaissances acquises à l’école est SINARES (Société d’Informatique Appliquée
Réalisation Etudes et Sécurité). Cette partie concernera deux grandes sous-parties à savoir :
l’accueil en entreprise et la présentation de l’entreprise.

I. ACCUEILLE

La date du 10 aout 2020 marque notre arrivée dans les locaux de SINARES, où nous
avons été accueillis par le Directeur Général Monsieur WOUANSI TOWO Jérémie Serge.
Pour le bon déroulement de notre stage, le Directeur Général (DG) a organisé une première
réunion au bout duquel il nous a présenté le personnel de SINARES et l’objectif principal de
notre stage dans ses locaux.
Notre première phase de stage a consisté à prendre connaissance de la règlementation en
vigueur à SINARES. Pour mener à bien cela, nos premiers jours de stage ont été consacrés à
la lecture du protocole de confidentialité, du règlement intérieur et du code de conduite.

II. PRESENTATION DE LA STRUCTURE

1. Historique
SINARES est une entreprise d’intégration open source, de fourniture de services et biens
informatiques, enregistre au numéro du contribuable : M011712586189W et au RCCM
(Registre de Commerce et du Crédit Mobilier) : B/140. Il a été créé le 07 juillet 2014 par
Monsieur Jérémie Serge WOUANSI TOWO. Lors de sa création elle portait le nom de
SINARES, puis en 2017 elle est passée à SINARES SARL (Société A Responsabilité
Limitée). Le but de sa création est d’apporter aux entreprises et institutions de la sous-région,
une gamme de produits et services visant l’amélioration du contrôle et la gestion d’affaires, à
travers la remontée d’information sur les tableaux de bord d’aide rapide à la décision.

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

2
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

En 2017, elle intègre le Saas dans ses services qui est un modèle de distribution
de logiciel à travers le Cloud.
Aujourd’hui, il est membre de la communauté Open Source d’Odoo qui est l’un des
leaders des solutions ERP Open Source destinées aux entreprises de toutes tailles et qui
possède une architecture modulaire et paramétrable permettant de s’adapter aux processus de
l’entreprise.
SINARES a réussi à avoir des références assez connues dans la société camerounaise tel
que ORIDEL, CAMES, 3N PHARMA DISTRICT SARL, EXECUTIVE TELECOM,
ADISCO, DJEMO BTP et bien d’autres…

2. Visions
Être un intégrateur IT et un partenaire technologique de premier rang.

3. Missions

Promouvoir la modernisation numérique pour de nombreux métier et organisations


d’affaires, dans le monde et en Afrique en particulier.

4. Activités

Les activités de SENARES sont :

 Développement des applications Web ;

 Développement des applications mobiles ;

 Services de développement Offshore ;

 Intégration open source & service support ;

 Solution IT de bout en bout clé en main ;

 Produits logiciels d’entreprise ;

 Formation sur l’exploitation (utilisation, administration, intégration) de leurs solutions


(SRP, ERP, GRH-PAIE, HIS, GEC/GED/SAE, VISIBILITY, INFESEC, UCCOS,
GEP) ;

 Renforcement des capacités de production du personnel (Microsoft Office, Odoo,


Docker, OpenStack, COBIT, Liferay, Oracle, SQL Server, CISCO, Huawei, Mikrotik,
Juniper).

5. Produits

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

3
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Les produits fournis par SENARES sont :

 SRP (School Ressource Planning) : ensemble de logiciels web et outils pour l’aide
à la bonne gouvernance scolaire et universitaire ;

 ERP (Entreprise Ressource Planning) : ensemble de logiciels web et outils qui


permettent de gérer au quotidien, l’ensemble des opérations et informations d’une
entreprise ;

 GRH-PAIE (Gestion des Ressources Humaines et de la Paie) ;

 HIS (Hospital Information System) : application web permettent d’automatiser la


gestion des différentes prestations et suivis médicaux à différents niveaux ;

 GEC/GED/SAE (Gestion Electronique du Courrier/Gestion Electronique des


Documents/Service d’Archivage Electronique) : ensemble de logiciels web et
outils pour dématérialiser les procédures, gérer le cycle de vie des documents et
contenus en général d’une entreprise, depuis le courrier à l’archivage.

 VISIBILITY : ensemble de solution et outils pour promouvoir au quotidien la


visibilité d’une entreprise.

 INFSEC (Infrastructure and Security) : package de solution – Services


d’infrastructures- pour centraliser et sécuriser vos données et traitement, pour
gérer le travail en équipe de manière productive, et fournir des services à la
demande.

 UCCOS (Unified Communications & Collaboration Systems) : ensemble d’outils


web fournis pour gérer et unifier la communication et la collaboration au sein
d’une entreprise

 GEP (Gestion Electronique du Patrimoine) application web de gestion de


patrimoine mobilier, immobilier et matériel roulant ou celui d’une entreprise, à
travers des nombreuses fonctionnalités offertes.

3. Structure organisationnelle
3.1 Fonctionnement
SINARES est une structure hautement hiérarchisée, nous présentons dans cette partie
cette hiérarchie :
 Direction Générale

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

4
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Elle a les responsabilités suivantes :


 Identifier les problèmes de développement et proposer des solutions IT
complètes basées Open source ;
 Promouvoir l’Open source de la solution IT ;
 Trouver des financements pour les projets et les marchés IT ;
 Accompagner les Etats de la sous-région dans leurs politiques
d’émergence et en être un partenaire stratégique ;
 Accompagner les institutions et les entreprises dans leurs processus
d’automatisation et de suivi technique.
 Direction Technique :
Elle a pour responsabilité de :
 Résoudre les problèmes IT et les projets techniques ;
 Produire des supports, manuels et modèles ;
 Mettre en place l’infrastructure et l’administrer ;
 Réaliser des prestations et produire des livrables ;
 Accompagner dans la réalisation des objectifs commerciaux.
 Direction Commerciale 
Elle est responsable de :
 Identification et expressions des besoins du marché ;
 Actions marketing et commerciaux sur objectifs ;
 Gestion de projets commerciaux ;
 Cotation et facturation client, suivi des processus du marché et des paiements
 Utilisation des solutions commerciales et production des documents
commerciaux (catalogues, planches, flyers, rollups, présentations de produits
ou solutions, …) ;
 Tenue des présentations commerciales de produits ou solutions ;
 Organisation d’évènements commerciaux SINARES (promotions,
conférences, séminaires, foires, JPO, …).
 Direction Administrative et Financière 
Elle assure la :
 Gestion RH-paie ;
 Gestion financière ;

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

5
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

 Gestion comptable.
 R&D 
Elle est responsable de :
 Etudes, Audits, Expertises et rapports ;
 Identification des solutions aux problématiques recensées ;
 Découpage de la résolution en tâches (Intégration, Administration,
Utilisation) ;
 Recherche et tests des tâches d’Intégration d’administration et d’utilisation ;
 Production des modèles des différents rapports, des manuels d’intégration et
formation, et des présentations techniques ;
 Formation des équipes à l’Implémentation et l’Intégration des solutions
étudiées.
 La Direction de Production :
Elle a pour responsabilités :
 Visite de site, ingénierie avant-vente, ingénierie après-vente, implémentation,
intégration, développement, prestation de services informatiques divers ;
 Production des différents rapports de service en fin de service, des rapports
journaliers et hebdomadaires ;
 Identification des rubriques à coter dans chaque solution ou produit
facturable.
 Direction de l’Administration Technique 
Elle a pour responsabilité :
 Installation de l’infrastructure physique (serveur, réseau physique, …) ;
 Installation de l’infrastructure logique (OS, services, applications, sécurité,
…)
 Administration (gestion de l’infrastructure, monitoring, journalisation,
politique de sécurité, sauvegarde, gestion d’incidents, …) ;
 Production hebdomadaire des rapports d’administration.

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

6
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

3.2 Organigramme de la structure

Direction
Générale

Direction
Direction Direction Administrative
Technique Commerciale et
Financière

Administration
R&D Production
Technique

Figure 1: Organigramme de la structure

3.3 Plan de localisation

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

7
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 2: plan de localisation (logiciel Edrawn Max)

CONCLUSION

Au terme de cette phase marquant la période d’insertion au sein de SINARES,


nous avons pris connaissance du mode de fonctionnement de l’entreprise en lisant, le
protocole de confidentialité, le règlement intérieur, la structuration, et avons pris connaissance
des services de SINARES. Il en découle de cette prise de contact que SINARES fait dans
plusieurs services. SINARES voudrait être aux pointes de la nouvelle technologie des réseaux
défini par logiciel. C’est dans cet ordre d’idée qu’il m’a été affecté le thème « implémentation
d’une architecture SDN LAN ».

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

8
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

PARTIE II : DOSSIER TECHNIQUE

Rédigé par : NJIMOLUH MOUSTAPHA


Centre d’excellence technologique PAUL BIYA, Année 2019-2020

9
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

CHAPITRE I : ANALYSE DU PROJET

I. PRESENTATION DU THEME

Le Software-Defined networking est une approche de l’informatique des réseaux qui


permet aux administrateurs réseaux d’initialiser, contrôler, changer et gérer les ressources du
réseau de manière à programmer dynamiquement via des interfaces ouvertes et l’abstraction
des fonctionnalités de plus bas niveau. Dans ce rapport nous allons utiliser le modèle de
programmabilité via le contrôleur et implémenté une architecture LAN SDN avec
l’application OpenFlow Manager pour la gestion des flux.

II. ETUDE DE L’EXISTANT

1. Ressources matérielles
SINARES dispose de plusieurs équipements informatiques dont nous pouvons
énumérer :
Tableau 1: ressources matérielles

DESIGNATIO MARQUE NOMBRE NATURE


N
Onduleurs APC 4 Appareil électronique
de puissance
Scanners PANASONIC 1 Outil de numérisation
des documents
Imprimantes HP 2 Impression des
documents
Routeurs TP-LINK 1 Equipement réseau
Machine HP, DELL 8 Matériel informatique
de bureau

2. Ressources logicielles
SINARES dispose de plusieurs logiciels dont :

Tableau 2 : ressources logicielles

LOGICIELS VERSIONS
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Un système d’exploitation serveur : 8 (Jessie)


DEBIAN
Le système d’exploitation WINDOWS 10
pour le secrétariat et la division
commerciale
Un hyperviseur de type 1 : KVM 17
Permettant de virtualiser des systèmes
d’exploitation
La suite OFFICE 2016

D’autres OS tels que CentOS, Ubuntu


Serveur, Fedora pour les différents 7, 16.04
projets sur lesquels on travail.
L’antivirus AVAST 2019
Navigateurs web tels que : 68.0.1 et 75.0.3770.100
MOZILLA FIREFOX, GOOGLE
CHROME
La suite LIBRE OFFICE 5

3. Architecture réseau
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 3 : architecture réseau (logiciel Edrawn Max)

SINARES utilise l’adresse publique 169.255.6.18/19 et l’adresse privée 192.168.0.0/24.

4. Critique de l’existant

La méthode adoptée par SINARES pour son architecture réseau est traditionnelle. Cette
architecture est restée rigide et statique avec les nouvelles technologies comme la
virtualisation et le cloud computing qui apportent une flexibilité sans précédente au
déploiement des services et l’exploitation des ressources, Or cette 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.

5. Solutions proposées
Pour pallier à ce problème, nous proposons de :
 D’implémenté une architecture SDN LAN afin de rendre réseau flexible,
programmable et centraliser la gestion.

III. PROBLEMATIQUE
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Le problème à résoudre ici est celui de la flexibilité, programmabilité et de la


centralisation du réseau. Pour résoudre ce problème, nous devons nous poser un certain
nombre de questions :
 Quel est le contexte de genèse du SDN ?
 Quel sont les différents modèles du SDN ?
 Quel et l’architecture du modèle de programmabilité via un contrôleur ?
 Quel sera le contrôleur le plus approprié pour ce modèle ?
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

CHAPITRE II : CAHIER DES CHARGES

INTRODUCTION

Un cahier des charges synthétise les informations nécessaires à l’établissement


d’un projet afin que les objectifs et les caractéristiques soient fournis et compris par
l'ensemble des acteurs impliqués. Les informations fournies visent à clarifier la situation et
mettre tout le monde d'accord (le maître d’ouvrage et le maître d’œuvre). Le cahier des
charges prend des formes variables selon le type d’activité. Il pose le cadre du travail et
permet également de cadrer les missions qui vont être données à tous les acteurs du projet en
vue de son bon déroulement. Ses fonctions pour le cadre de notre projet sont : contexte,
objectifs, expression des besoins de L’utilisateur, les acteurs du projet, les contraintes,
planification, évaluation financière. Nous nous attarderons sur ces fonctions en détail dans la
suite de notre travail.

I. OBJECTIFS

1. Objectif global
L’objectif global de ce projet est d’implémenté une architecture SDN LAN pour :
 Séparé le plan de contrôle du plan de données
 Avoir un contrôle centraliser
 Programmer le réseau

2. Objectifs spécifiques
L’objectif spécifique de ce projet est d’utiliser L’application OpenFlow Manager pour la
gestion des flux réseau. Ce qui va nous permettre de :
 Avoir une vue globale de la topologie sous-jacente
 Visualiser, ajouter, modifier ou supprimer les différents flux
 Fournir les statistiques liées aux flux et aux ports des switchs
 Résumé les informations concernant les hôtes géré par OFM

II. EXPRESSION DES BESOINS DE L’UTILISATEUR

Les besoins de l’utilisateur pour ce projet seront :


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

 Un serveur Intel 3*3Ghz ; 16Gb de RAM ;

 Système d’exploitation Ubuntu server 16.04 64bits ;

 Un laptop Hp, 500GO HDD, 8Go RAM, corei7 ;

 Switch SDN.

III. LES ACTEURS DU PROJET

La réussite de l’élaboration d’une architecture SDN nécessite d’impliquer et d’associer


tout au long de la démarche un ensemble d’acteurs aux compétences relevant de son
périmètre. Le nombre d’acteurs à mobiliser peut donc naturellement varier selon les
thématiques retenues. On distinguera trois types d’acteurs :

 Les acteurs internes de l’entreprise : qui interviennent en tant que décideur,


contributeurs ou utilisateurs du SDN ;
 Les équipes projets : notamment les personnels dédiés à la conduite du projet SDN ;

 Les intervenants « extérieurs » : qui interviennent éventuellement au titre d’une


assistance (experts, assistant à maîtrise d’ouvrage, …).

IV. LES CONTRAINTES DU PROJET

1. Coût
La contrainte majeure est celle de change les nœuds réseau et d’acheter un serveur puissant qui aura
les capacités nécessaires pour supporte tous les calculs du réseau ce qui rend le cout du projet très élevé.

2. DELAI

V. CONTEXT

D’après Cisco Visual Networking, à l’horizon 2021 le nombre d’appareils mobiles


connectés dépassera le nombre de personne sur terre à hauteur de 1,5 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.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

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. D’où
notre intérêt d’implémenté une architecture SDN LAN pour SINARES qui est une entreprise
a la pointe de la technologie

VI. PLANIFICATION

La planification est très importante dans la conduite d’un projet. Elle définit le
temps de réalisation des différentes tâches d’un projet afin de mieux atteindre ses objectifs
dans les délais. La planification de nos différentes activités vous sera présentée suivant le
diagramme de GANTT ci-dessous.

Figure 4 : diagramme de Gantt (logiciel Gantt Project)


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

VII. EVALUATION FINANCIERE

L’ensemble des prix est faite CFA.

1. Ressource humaine
Nous avons recensé pour la réalisation de notre projet trois informaticiens. Le tableau suivant
donne un aperçue :

Tableau 3: Ressource humaine

Fonction Nombre Prix Nombre de Prix total


unitaire/jour jours
Analyste 01 10 000 10 100 000
programmeur
Ingénieur en 01 10 000 10 100 000
telecommunicatio
n
Ingénieur de 01 10 000 60 600 000
travaux
informatiques en
système réseau
Total 800 000

2. Ressources matérielles et logiciels


Ici il est question de présenter les différents outils nécessaires dont nous avons besoins pour la
réalisation de notre projet.

Tableau 4 : Ressource matérielles et logiciels

ENTITES CARACTERISTIQU QUANTITE PRIX MONTANTS


ES OU MODELE UNITAIR (https://www.h
E (FCFA) ardware.fr/prix/
)
LAPTOP Hp, 500GO HDD, 8Go 1 250 000 250 000
RAM, corei3
Switch SDN Nicira 8

SERVEUR Intel 3*3Ghz ; 16Gb de 1 1 300 000 1 300 000


RAM, 1To

SYSTEME Ubuntu server 16.04 1 Open Open source


D’EXPLOITATION 64bits source
Contrôleur OpenDaylight 1 Open Open source
source
TOTAL
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

3. Montant total du projet


Tableau 5: Montant du projet

Ressources Prix
Humaines 800 000
Logicielles
Imprévues 300 000
Total

CHAPITRE III : ETAT DE L’ART

I. ETAT ACTUEL DES RESEAUX

1. L’informatique en nuage
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Un nuage contient un réseau qui relie un grand nombre d'ordinateurs et de ressources


informatiques, mais peu importe ce qu'il y a dedans, car l'utilisateur n'a pas à le savoir,
l'essentiel est d'obtenir le service demandé. Selon la définition la plus communément admise,
l'informatique en nuage est un modèle pratique, permettant d'établir un accès par le réseau à
un réservoir partagé de ressources informatiques configurables (par exemple, réseaux,
serveurs, stockage, applications et services) qui peuvent être rapidement mobilisées et mises à
disposition. Les entreprises peuvent utiliser les technologies de l'informatique en nuage pour
fournir l'information, ce qui optimise l'utilisation des équipements, augmente la flexibilité et
la rapidité et réduit les dépenses en capital. Les technologies de l'informatique en nuage
facilitent l'accès des particuliers aux informations et aux contenus en ligne et offrent une plus
grande interactivité. L'utilisation de l'informatique en nuage diffère en fonction des
utilisateurs. Les particuliers utilisent en général cette technologie pour les services de
messagerie électronique, de stockage de fichiers, de partage d'informations, de paiement et de
diffusion des flux de musique et de vidéo. Les entreprises l'utilisent principalement pour les
activités de bureautique de base, la collaboration, la gestion de projet et la création
d'applications personnalisées.

Figure 5 : informatique dans le nuage

2. La virtualisation
La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitation
comme un simple logiciel sur un ordinateur, au lieu de ne pouvoir en installer qu'un seul par
machine, elle est utilisée donc pour permettre le fonctionnement de plusieurs machines
disposant chacune de leur système d'exploitation spécifique partageant la même infrastructure
physique. Le concept couvre différents aspects, on peut ainsi virtualiser les serveurs, le
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

stockage, les applications (simplification de l'administration) ou encore le poste client. A ce


stade, la virtualisation et l'informatique en nuage, ces deux sujets vont de pair, les avantages
de la virtualisation prennent tout leur sens à l'échelle de l'informatique en nuage.

II. ARCHITECTURE DES NŒUDS RE

À 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.
 Contrôle : Ce plan décide de la direction des flux réseau, il décode les protocoles pour
assurer la fluidité du trafic.
 Services : Cette couche n’existe pas dans les switchs. 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.

Figure 6 : architecture routeur

III. LE SOFTWARE DEFINED NETWORK

1. Contexte de genèse du SDN


1.1. Le besoin de faire évoluer le réseau
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

D’après Cisco Visual Networking, à l’horizon 2021 le nombre d’appareils mobiles


connectés dépassera le nombre de personne sur terre à hauteur de 1,5 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 connue aucun changement
majeur depuis plus de 20 ans. Ce statut 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ées 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 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 heures voir des jours dans les WAN. 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.

1.2. Principe du SDN

1.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.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

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. Mais le SDN est reconnu aujourd’hui
comme une architecture permettant d’ouvrir le réseau aux applications

1.2.2. Différents modèles du SDN

Comme expliqué dans la section précédente, le SDN englobe toutes les solutions
permettant une programmation du réseau, afin de mieux interagir avec les applications.
Diverses solutions coexistent, adaptées selon les besoins des utilisateurs. On comprend
aisément que les solutions permettant de simplifier le déploiement d’une application dans un
datacenter ne sont pas les mêmes que celles qui permettront de mieux contrôler l’éclairage
d’une ville à travers le réseau. On peut noter différents modèles de programmabilité :
 Programmabilité individuelle de chaque équipement. Dans ce modèle une application
interagit directement avec chaque équipement via des API. L’application est
centralisée ou peut être localisée directement sur l’équipement réseau pour réaliser des
tâches spécifiques.
 Programmabilité via un contrôleur. Dans ce modèle, une application donne un ordre
abstrait et global à un contrôleur, qui à son tour traduit cette requête en une suite
d’ordres auprès des équipements du réseau concerné. Ce modèle est certainement le
plus populaire puisqu’il permet de simplifier le réseau. Le contrôleur masque la
complexité du réseau. On peut distinguer plusieurs cas selon le type d’ordres échangés
entre le contrôleur et les équipements. Si, au départ, il était question d’avoir une
programmabilité du plan de données (via OpenFlow par exemple), des modèles plus
récents implémentent des modèles dans lesquels des ordres plus abstraits sont donnés
aux équipements, ces derniers restant libres de les implémenter au mieux.
 Création d’un réseau virtuel au-dessus du réseau physique. Dans ce modèle, les
applications créent leur propre réseau « overlay », s’affranchissant des contraintes du
réseau physique sous-jacent. Ce dernier n’a pour mission que la simple connectivité
entre les nœuds d’extrémité des tunnels, et le réseau d’overlay assure l’intégralité des
services. On parle également de virtualisation des fonctions réseau (NFV – Network
Function Virtualization) quand les routeurs, commutateurs, firewalls, etc. sont des
éléments virtualisés sur des serveurs
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 7: modèle de programmabilité

1.3. Le modèle de programmabilité via un contrôleur

1.3.1. Définition
Ce modèle est défini comme une architecture qui centralise toute l’intelligence du
réseau dans une entité programmable appelé contrôleur, afin de gérer plusieurs éléments du
plan de donnée via des API.

Figure 8 : Centralisation du réseau

1.3.2. Architecture
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Le réseau SDN est composé de 3 couches communiquant entre elles par le biais
d’interfaces APIs. De la plus basse à la plus haute nous avons :
 La couche infrastructure : Ici se trouve les périphériques qui contiennent les plans de
données du réseau. Autrement dit, les switchs SDN responsables de l’acheminement
du trafic.
 La couche contrôle : Elle se base sur le contrôleur SDN, il contrôle le plan de donnée
de façon réactive ou proactive en insérant les différentes politiques de transfert. Cette
partie est le cerveau du réseau et elle englobe la plupart des opérations de calcul.
 La couche application : Héberge les applications qui permettant d’exploiter la
panoplie d’avantages qu’apporte l’architecture, en introduisant de nouvelles
fonctionnalités réseaux. Dans cette disposition l’application communique les
décisions et politiques de routage au contrôleur, qui a son tour traduit ces décisions
pour programmer les équipements appropriés. Les dispositifs de transmission
comparent ensuite l’entête des paquets avec les tables de flux pour ensuite effectuer
les actions prédéfinies dans les tables.

Figure 9 : Architecture SDN

1.3.3. 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, l’interface utilisée est une interface
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

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.

1.3.4. Le protocole OpenFlow

L’histoire d’OpenFlow a commencé à l’Université de Stanford, par un groupe de


chercheurs appelé le Clean Slate Program dont l’objectif était d’explorer comment on
concevrait internet si on faisait table rase et qu’on avait 20 à 30 ans de recul. En 2008 l’Open
Networking Foundation (ONF) a publié OpenFlow qui est un protocole réseau permettant la
réalisation des architectures Software Defined Networking. Il permet d’accéder directement
au plan de données des périphériques réseau (routeurs, switch), il s’agit d’une façon
dynamique, centralisé et programmable d’interagir avec les différents équipements de
l’infrastructure. Ce protocole prend en compte les fonctions communes supportées par les
différentes tables des switchs Ethernet et routeurs conçus par les constructeurs, ce qui permet
l’utilisation des tables de flux par tous les dispositifs réseau. OpenFlow est utilisé comme une
interface sud dans les réseaux définies par architectures SDN.

a. Architecture du protocole OpenFlow

Le protocole OpenFlow définit la connexion entre un switch OpenFlow et un


contrôleur. L’essence de ce protocole consiste d’un set de messages qui transitent entre le
contrôleur et le switch dans les deux sens. Ce sont ces messages qui permettent au contrôleur
de garder un contrôle sur les switchs et sur le trafic des utilisateurs. Quant à l’architecture du
switch OpenFlow, comme nous en avons parlé dans la section précédente, celui-ci est régit
par les principes des tables de flux.

Figure 10 : Architecture OpenFlow


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

b. Tables de Flux

Les commutateurs OpenFlow sont composés d’un pipeline de tables de flux. Celui-
ci permet la gestion de l’acheminement des paquets, le mécanisme consiste à cumuler les
actions de chaque table de flux pour les exécuter à la sortie du pipeline.

Figure 11 : Pipeline OpenFlow v1.1

Les champs des entrées qui composent les tables de flux sont globalement structurés comme
suit.

 Champs de correspondance (Match fields)

 Compteurs

 Actions

Figure12 : Entrée de flux

1.3.5. Les switchs SDN

Par abus de langage, tous les équipements de transmission SDN sont appelés switch. Dans
ce jargon le terme switch est attribué à tout équipement de transmission qui compare l’entête
des paquets aux tables de flux, que la comparaison se fasse à base d’adresses MAC (Couche
2), d’adresses IP (Couche 3) ou une combinaison de plusieurs champs. La terminologie switch
a été adoptée en référence à l’unique tache de ces équipements qui est la transmission. Un
switch SDN est composé d’une API pour communiquer avec le contrôleur, une couche
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

d’abstraction qui consiste en un pipeline de tables de flux et une fonction de traitement de


paquets.

Figure 13 : Anatomie logique d’un switch SDN

Les tables de flux sont un élément fondamental du fonctionnement d’un switch SDN, elles
sont composées d’un nombre d’entrées de flux, les quelles consistent en deux composantes
principales :
 Champs de correspondance : Ils sont utilisés par ordre de priorités pour être
comparés aux entêtes des paquets entrants, le premier champ correspondant
est directement sélectionné.
 Les Actions : Ce sont les instructions qui doivent être exécutés si une
correspondance entre un paquet entrant et l’entrée pour laquelle ces actions
sont spécifiées.
La logique du traitement de paquets consiste en un nombre de mécanismes qui se
mettent en actions en fonction du résultat de l’évaluation de l’entête du paquet et la
correspondance de priorité la plus haute. Lorsqu’une correspondance est trouvée, le paquet est
traité localement dans le switch, à moins qu’il soit explicitement envoyé au contrôleur. Si
aucune correspondance n’est trouvée, une copie du paquet est envoyée au contrôleur qui
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

devra décider quoi en faire, et éventuellement mettre à jour la table de flux pour l’y introduire
comme entrée.
On distingue deux types de switchs SDN :
o Switch SDN logiciel (Open vSwitch).
o Switch SDN matériel

1.4. Le contrôleur
Le rôle du plan de contrôle est de contrôler et de gérer les équipements de l’infrastructure,
et de les relier avec les applications. Il est composé d’un ou de plusieurs contrôleurs et il est
considéré comme système d’exploitation du réseau. Les premières versions du SDN
présentent un plan de contrôle composé d’un seul contrôleur centralisé. Par la suite des
architectures distribuées utilisant plusieurs contrôleurs ont été proposées pour améliorer les
performances et la scalabilité du réseau. Les performances des contrôleurs SDN sont
caractérisées par le débit, qui est la quantité de flux traités par seconde et la latence, qui est le
temps d’installation d’une nouvelle règle. Afin de pouvoir interagir avec le réseau, le
contrôleur a besoin d’une vue précise de ce dernier. C’est ainsi que le concept de NIB
(Network Information Base) a vu le jour. Cette NIB est construite au niveau du contrôleur et
permet à ce dernier de savoir comment implémenter chaque ordre abstrait, trouver les
équipements qui doivent être reconfigurés, s’assurer de la capacité de ces derniers à
implémenter une directive et les API supportées par l’équipement.

Figure 14 : Contrôleur SDN : éléments, services et interfaces

Le contrôleur se base sur deux modes opérationnels : réactif et proactif.


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

 L’approche réactive fait tout transiter par le contrôleur. Lorsqu’il y a un paquet


entrant sur le Switch, celui-ci est directement redirigé vers le contrôleur pour que ce
dernier décide du comportement à adopter vis-à-vis du paquet. Ce model peut causer
des temps de latences considérable, en fonction des ressources à disposition du
contrôleur et la distance Switch-contrôleur.
 Dans l’approche proactive, le contrôleur introduit préalablement des règles dans les
switchs pour qu’ils puissent traiter les paquets localement. Ici il le nombre de paquets
envoyés au contrôleur diminue considérablement ce qui fait gagner en efficacité et en
débit à l’architecture. Plusieurs contrôleurs SDN sont développés, commerciales ou
Open source. Ils différent par leur architecture (Centralisé ou Distribuée), leurs
langages de programmation, les API qu’ils supportent, les techniques utilisés et leurs
performances comme le débit et la latence. Le tableau ci-dessous résume certains des
contrôleurs les plus en vigueur actuellement :

1.5. L’orchestrateur

L’orchestrateur vient répondre à la nécessité de pouvoir programmer le réseau de bout en


bout. Si l’application est déployée dans un data center, les usagers peuvent être connectés en
Wifi, connecté au LAN, derrière le WAN et des firewalls ou autres dispositifs réseau, ceux si
sont souvent des domaines indépendants formant une chaine d’exécution, ce qui rend la tâche
pratiquement impossible pour le contrôleur. Dans les architectures de fournisseur de services
des opérateurs par exemple, ce n’est pas le contrôleur mais l’orchestrateur qui va offrir cette
fonction de programmation de bout-en bout. Ce dernier reçoit un ordre depuis une application
et réalise ensuite la suite d’actions nécessaires pour mener à bien la tâche demandée. Pour
réaliser sa mission, l’orchestrateur va pouvoir s’appuyer pour chaque élément de la chaîne sur
le/les contrôleurs déployés.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 15 : Architecture SDN avec un orchestrateur

IV. CAS D’UTILISATION DU SDN

1. 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
est possible 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. 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.

3. Réseau de campus et d’entreprise


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Les dernières années ont été marqué par un changement radical de la perception des
équipements de travaille en entreprise et dans les campus universitaires. En effet la mode
BYOD, 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 a gérer manuellement et par les
opérations manuelles qui pourrait permettre de connecter tous les utilisateurs à internet par
exemple

4. 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.

5. Sécurité

La nature dynamique de SDN a été exploitée par un groupe de chercheurs (Jafarian,


AlShaer & Qi Duan 2012) 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.

V. COMPARAISON ENTRE LE RESEAU TRADITIONNEL

ET LE SDN
Tableau 6:Comparaison entre le réseau traditionnel et le SDN

Réseau SDN Réseau traditionnel


Fonctionnalité Découple le plan du contrôle Le contrôle du réseau est
du plan de données, offre un complexe
meilleur contrôle du réseau
et la possibilité de le
programmer
Configuration Configuration automatique a Une configuration manuelle
travers une centralisation du et la possibilité de faire des
contrôle du réseau, erreurs qui vont entraine un
optimisation de la comportement erroné du
configuration. réseau
Performance Contrôle global de Le problème de
l’information configuration statique
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Innovation Implémentation facile de Difficulté d’implémentation


logiciels et de mises à jour de logiciel et de mise a jour
dans le réseau, dans le réseau,
environnements de tests environnement de test limité
suffisants

CHAPITRE IV : IMPLEMENTATION DE LA SOLUTION

INTRODUCTION

Les réseaux SDN ont pour but pratique de rendre les réseaux programmables par le
biais d’un contrôleur centraliser. Un contrôleur central omniscient permet aux ingénieurs de
réseau de mettre en œuvre des politiques de transfert uniques et flexibles dont les seules
limitations sont liées à la capacité du logiciel faisant fonctionner le contrôleur.
Dans ce chapitre en premier lieu on va effectuer un choix du contrôleur SDN. Ensuit une
exploration du contrôleur SDN sera effectuée avec ses différentes version en se basant sur la
version utilisée dans le projet et son installation. Par la suit on va intégrer l’application
OpenFlow Manager au contrôleur, présenter et installer l’émulateur mininet, installer
wireshark dans mininet et en fin installer l’émulateur de terminal PuTTY.

I. CHOIX DU CONTROLEUR

Nous avons choisi d'étudier et de comparer deux contrôleurs : OpenDaylight et Floodlight


afin d'évaluer leurs paramètres leurs caractéristiques.

1. OpenDaylight

OpenDaylight est un projet open source pris en charge par IBM, Cisco, Juniper, VMWare
et plusieurs autres grands fournisseurs de réseau. OpenDaylight est une plate-forme de
contrôleur SDN implémentée en Java, il peut être déployé sur n'importe quelle plate-forme
matérielle et système d'exploitation prenant en charge Java.

Le projet OpenDaylight repose sur des principes de développements ouverts et


transparents, il vise à réunir les acteurs du réseau pour travailler sur des solutions communes.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Big Switch Networks, Cisco, Citrix, Ericsson, IBM, Juniper Networks, Microsoft, Red Hat ou
encore VMware sont ainsi les membres fondateurs d’OpenDaylight

Figure 16: interface Web OpenDaylight

2. Floodlight
Floodlight est un contrôleur de réseau défini par un logiciel, soutenu par la société Big
Switch, il offre un point de gestion central pour les réseaux OpenFlow et il peut gérer des
périphériques tel que open vSwitch de manière transparente. Il prend également en charge une
large gamme de commutateurs physiques OpenFlow, de sorte qu'il simplifie grandement la
gestion du réseau. Il est sous licence Apache et écrit en java.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 17: interface web Floodlight

3. Tableau comparatif
Tableau 7: Tableau comparatif OpenDaylight et Floodlight

Caractéristiques OpenDaylight Floodlight


Développé par Interface Linux Foundation Big Switch Networks
Soutenu par Cisco, HP, IBM, Juniper, Big Switch Networks
VMWare, etc.
Ecrit en Langage Java Java
Langages supportés Java Java
Open source Oui Oui
Interface utilisateur Web Web
Virtualisation Mininet, OpenVswitch Mininet, OpenVswitch
Interfaces Southbound (OpenFlow, Southbound (OpenFlow),
OVSDB, NETCONF, LESP, northbound (Java, REST)
SNMP etc.), northbound
(APIs REST, RESCONF,
NETCONF)
Plateforme Linux, Windows Linux, Windows
Documentation Site officiel Site officiel
Architecture Distribué Centralisé

Selon les caractéristiques présentées dans le tableau, nous avons opté pour le choix du
contrôleur OpenDaylight pour réaliser notre simulation SDN LAN.

4. Installation d’OpenDaylight
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Etape1 : Installer n’importe quelle machine virtuelle (VMware ou virtual box).


Etape 2 : créer une machine virtuelle avec Ubuntu 16.04 LTS comme système d’exploitation sous le
nom de sdnctlodl avec les caractéristiques qui sont dans la figure 22

Figure 18 : virtual caractéristiques de la machine

Etapes 3 : installation du système d’exploitation Ubuntu 16. 04 LTS


Etape 4 : Préparer le système d'exploitation
Exécutez une mise à jour apt-get pour vous assurer que votre serveur reçoit tous les packages
de sécurité et d'application les plus récents.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Maintenant, installez-les packages de commodité.

Etape 5 : Installez Java JRE


Exécutez la commande suivante pour installer le JRE

Maintenant, assurez-vous qu'Ubuntu pointe vers JAVA 8. Exécutez la commande


suivante. S'il ne pointe pas vers JAVA 8, veillez à sélectionner la version 8 dans la liste.

Exécutez la commande suivante pour mettre à jour votre fichier BASHRC.

Maintenant, la source de votre Bashrc fichier, puis vérifiez $ JAVA_HOME vie dans


l'environnement.

Vérifiez que $ JAVA_HOME se termine par / jre.

Télécharger une version complète (toutes les fonctionnalités) d'OpenDaylight 

 Installer OpenDaylight

Commencez par créer un répertoire pour le binaire

Déplacez l'archive zip vers l'espace de travail d'installation et dégonflez l'archive. Assurez-


vous d'utiliser la bonne version. J'ai téléchargé la version 0.8.4 et la vôtre peut être différente.

Installez karaf dans l'espace utilisateur.


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Maintenant que l’installation est terminée, vous pouvez lancer   OpenDaylight avec la


commande suivante :

Figure 19 : ODL lancer

Dans la ligne de commande d’ODL, la commande suivante permettra d’installer les interfaces
(REST, OpenFlow, Yang), la couche d’abstraction (mdsal) et l’apprentissage réactif des
nœuds de couche 2 (l2switch).

Saisissez l'URL http://192.168.56.101:8181/index.html dans votre navigateur.


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 20 : login ODL

Interface graphique du contrôleur ODL

Figure 21 : GUI ODL

II. PuTTY

PuTTY est un programme permettant de se connecter à distance à des serveurs en utilisant les


protocoles SSH, Telnet ou Rlogin. L'ensemble des sessions peuvent être automatiquement
enregistrées dans un rapport qui pourra être consulté ultérieurement. La fenêtre de
commandes est personnalisable afin de convenir à tous les utilisateurs : il est possible de
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

modifier le type de curseur, les couleurs, la police de caractère utilisée, etc. Les connexions
sont également paramétrables : il est possible de passer par un proxy, de préférer une
connexion SSH 1 ou SSH 2, de mettre en place la compression lors des sessions SSH,
d'utiliser un mode passif pour les négociations en Telnet, etc.
 Télécharger la version de Putty.exe :
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
 Installation
Démarrer le programme "putty.exe". Décompresser tous les fichiers dans "C:\winapp".
Un répertoire va être créé dans "C:\winapp" qui se nomme "PuTTY".

Figure 22: installation PuTTY

 Configuration
Démarrer le programme PuTTY et entrez l’adresse IP du contrôleur (192.168.56.101)
Veiller à configurer l'option "SSH" avec les options suivantes :
 Enable compression : oui
 Preferred SSH protocol version : 2
 Encryption cipher selection Policy : AES (SSH 2 only) en premier
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 23: Configuration PuTTY

Figure 24 : Configuration du SSH


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

 Etablissement de la connexion avec OpenDaylight

Figure 25 : connexion ODL

Le système demande de s'authentifier avec un nom d’utilisateur et un mot de passe du


contrôleur.
Nom : sdnctl
Mot de passe : voitur2012
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

III. INTEGRATION DE L’APPLICATIONOPENFLOW MANAGER

DANS OPENDAYLIGHT

1. L’Application OpenFlow Manager


L’un des objectifs clés du SDN en général et OpenDaylight en particulier, est
l’abstraction du réseau. Il s’agit de simplifier les opérations réseau gérés par l’administrateur,
de telle sorte à ce qu’il n’ait pas à savoir ce qui se passe entre le contrôleur et le switch.
L’utilisateur programmera l’infrastructure en dépit du type d’équipements ou des protocoles
utilisés, en langage développeur.
2. Architecture de l’application OFM
OpenFlow Manager est une application développée par Cisco pour son contrôleur
commercialisé basé sur OpenDaylight, ce qui fait que l’application est compatible avec ODL.
Elle est faite pour une architecture MD-SAL, offrant la possibilité de créer des flux aisément
grâce à une interface graphique accueillante. L’application communique avec les modèles
YANG se trouvant dans le contrôleur à travers l’interface RESTCONF (Les mêmes concepts
que la section antérieure). L’approche est simple, en cliquant sur une case pour choisir
l’action ou les champs de correspondance par exemple, on génère une ligne de code en Json
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

une fois l’opération validée, l’application envoie la requête via RESTCONF au contrôleur où
le SAL traduira le modèle au langage de l’équipement en question (Cisco Dev Net, 2014).

Figure 26 : structure OFM

3. Fonctionnalités d’OFM
Les fonctions de bases proposées par l’application affichée en haut de l’écran interface
sont subdivisées en 4 onglets :
- Basic view : Vue globale de la topologie sous-jacente. OFM schématise la structure
du réseau en affichant les switchs OpenFlow et les hôtes qui leurs sont connectés.
- Flow management : Ou gestion de flux. Permet de visualiser, ajouter, modifier ou
supprimer les différents flux.
- Statistics : Fournit les statistiques liées aux flux et aux ports des switchs. - Hosts :
Résume les informations concernant les hôtes gérés par OFM.

4. Installation
Installation de Nodejs, un environnement d’exécution Javascript côté serveur. Ceci
permettra de faire fonctionner grunt.

 Téléchargement d’OFM
Clonage du répertoire GitHub de l’application.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Configuration de l’adresse IP du serveur web :

Installation de grunt

 Exécution du serveur web d’OFM


La commande grunt démarrera une instance du serveur web, et affichera ceci sur la ligne
de commande

Saisir L’URL : http://192.168.56.101:9000

IV. MININET

Préalablement à tout déploiement, la conception du prototype est un processus qui permet


d’anticiper le comportement du réseau. Dans ce contexte Mininet vient offrir une plateforme
d’expérimentation et de développement avec la possibilité de créer un réseau virtuel réaliste,
extensible et interactif. Un terrain fertile pour l’innovation dans le domaine du SDN, grâce à
son interface programmable python (Python API) et sa ligne de commande (CLI), autrement
dit une route fluide vers l’implémentation sur matériel.

1. La ligne de commande Mininet

Grâce à la commande mn et la multitude d’options offertes par l’émulateur, il est possible


de réaliser maintes formes de topologies et de réseaux virtuels :

o L’option --topo permet de créer 3 types de topologies de base : tree (Arbre), linear
(linéaire) et single (topologie centralisée d’un seul switch).

o Pour connecter notre topologie à un contrôleur l’option adéquate est --Controller,


dans l’exemple d’un contrôleur distant on ajoute =remote, ip=192.168.56.102.

o D’autres options sont disponibles sur Mininet pour n’en citer que certaines : --switch
offre la possibilité de choisir le modèle de switch parmi ceux supportés par
l’émulateur, et --mac qui simplifie l’adresse mac des nœuds réseau en les faisant
correspondre à leur identifiant. L’option –x ouvre un terminal xterm pour chaque
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

élément du réseau généré, et pour pouvoir personnaliser la bande passante et la latence


des liaisons.

Après avoir inséré la commande mn suivie des options voulues et créé la topologie nous
accédons à la ligne de commande de Mininet identifiable par l’expression mininet> au début
de chaque ligne (Hors CLI les commandes sont précédées du symbole comme$ toute
plateforme sous linux). Les commandes principales de la CLI sont :

 Mininet> net Affiche toutes les liaisons du réseau, mininet> nodes qui cite tous les
nœuds réseau et mininet> dump qui affiche les informations liées aux nœuds du
réseau.

 Un simple test de connectivité peut se faire grâce au Ping et la commande mininet>


iperf permet de mesurer la bande passante entre deux hôtes.

 Un terminal xterm peut être ouvert pour chaque hôte en utilisant mininet> h1 xterm
ou h1 est le nom de l’hôte. On peut ainsi exécuter tout type de programme sur les
différents hôtes (Tout ce qui est disponible sous linux) et ainsi tester le réseau à l’aide
d’outils identiques à ceux de l’installation physique.

 Pour ce qui est la connectique avec OpenFlow mininet> dpctl dump-flows nous
permet d’afficher les différents flux installés sur les nœuds à partir de la ligne de
commande

2. Installation de mininet VM sur VirtualBox


Étapes d'installation et de configuration :

 Téléchargez Mininet VM

Les images de la VM Mininet sont disponibles sur :

https://github.com/mininet/mininet/wiki/Mininet-VM-Images

Afin de gagner du temps, votre instructeur vous fournira des instructions pour télécharger un
mininet OVA

Double-cliquez simplement sur le fichier mininet.ova et importez-le dans VirtualBox.


Assurez-vous de sélectionner la possibilité de réinitialiser toutes les adresses MAC.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 27: Images VM mininet

 Configurez les paramètres réseau de la VM. Dans VirtualBox, allez dans les
paramètres du VM et assurez-vous que la première carte réseau est connectée à «
Bridged Adapter », comme illustré en dessous de :

Figure 28: Configuration du VM mininet

Démarrez la machine virtuelle Mininet à partir de VirtualBox


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Connectez-vous à l'aide des informations d'identification suivantes :

 Nom d’utilisateur : mininet

 Mot de passe : mininet

3. Topologie proposée

Figure 29: Topologie proposée


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

La configuration de base des différents hôtes est donnée par la table suivante :

Tableau 8 : Adressage des hôtes

Hôtes Adresse MAC Adresse IP


DG 00 :00 :00 :00 :00 :01 10.0.0.1
Secrétariat 00 :00 :00 :00 :00 :02 10.0.0.2
H3 00 :00 :00 :00 :00 :03 10.0.0.3
H4 00 :00 :00 :00 :00 :04 10.0.0.4
H5 00 :00 :00 :00 :00 :05 10.0.0.5
H6 00 :00 :00 :00 :00 :06 10.0.0.6
H7 00 :00 :00 :00 :00 :07 10.0.0.7
H8 00 :00 :00 :00 :00 :08 10.0.0.8

L’émulateur Mininet fournit une interface de programmation Python, l’une de ces


utilisations consiste en la création de topologies customisées en y définissant toutes les
caractéristiques voulues des éléments du réseau, une approche pareille nous offre l’avantage
d’exploiter le temps et les ressources en main de la meilleure façon possible.

Le fichier .py doit être sauvegardé dans le répertoire mininet/custom/, de plus pour
pouvoir appeler la topologie par l’option --custom la dernière ligne du script est primordiale,
en gros nous y avons définis la topologie par le nom mytopo. La commande complète pour
générer cette topologie devra comporter le chemin d’accès du script et le nom de la topologie
en question

4. Création de la topologie

La partie infrastructure de notre architecture sera customisée et générée sur la plateforme


Mininet. La topologie a été créée par le biais d’un script Python sauvegardé dans le répertorie
mininet/custom
#!/usr/bin/python
from mininet.topo import Topo
from mininet.net import Mininet
from mininet.node import Node, Controller, RemoteController, OVSSwitch
from mininet.log import setLogLevel, info
from mininet.cli import CLI
from mininet.util import irange
from mininet.link import TCLink
class NetworkTopo( Topo ) :
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

def build( self ):


h1 = self.addHost( 'h1')
h2 = self.addHost(‘h2')
h3 = self.addHost( 'h3')
h4 = self.addHost( 'h4')
h5 = self.addHost( 'h5')
h6 = self.addHost( 'h6')
h7 = self.addHost( 'h7')
h8 = self.addHost( 'h8')
s1 = self.addSwitch( 's1')
s2 = self.addSwitch( 's2')
s3 = self.addSwitch( 's3')
s4 = self.addSwitch( 's4')
s5 = self.addSwitch( 's5')
s6 = self.addSwitch(‘s6')
#Coeur
self.addLink ( s6, s4 )
self.addLink ( s6, s5)
#distribution
self.addLink ( s1, s5 )
self.addLink ( s1, s4 )
self.addLink ( s2, s4 )
self.addLink ( s2, s5 )
self.addLink ( s3, s5 )
self.addLink ( s3, s4 )
#acccess
self.addLink( s1, h1 )
self.addLink( s1, h2 )
self.addLink( s1, h3 )
self.addLink( s2, h4 )
self.addLink( s2, h5 )
self.addLink( s3, h6 )
self.addLink( s4, h7 )
self.addLink( s4, h8 )
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

def run():
topo = NetworkTopo()
net = Mininet( topo=topo )
net.start()
CLI( net )
net.stop()
if __name__ == '__main__':
setLogLevel( 'info' )
run()
topos = { 'mytopo': NetworkTopo }
La commande pour créer le réseau personnalisé cité ci-dessus est la suivante :

Celle-ci générera les différents éléments de la couche physique qui sera connectée au
contrôleur OpenDaylight à distance.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Le contrôleur détecte les switchs OpenFlow, et après un ping global détecte les hôtes et
parvient à afficher la structure du réseau sous-jacent comme l’atteste la figure 27.

Figure 30: topologie vue GUI ODL

L’application OpenFlow Manager écrite en Node.js, est déployée à l’interface nord du


contrôleur sur un serveur web écoutant le PORT 9000. La topologie est tout de suite
récupérée par celui-ci, et sera affichée sur l’interface graphique comme suit.
http://192.168.56.101:9000/#/openflow_manager/index
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 31 : topologie vue GUI OFM

Cliquez sur le lien Flow Management en haut pour voir les entrées de flux.

Figure 32:Flow Manager

Cliquez sur l'icône « Afficher » pour voir les détails de l'entrée de flux avec la possibilité de
modifier et de supprimé. Une fois terminé, cliquez sur « Retour » pour revenir à la liste des
entrées de flux.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 33: Intégration des flux

Supprimé un flux

Cliquez sur le lien Host pour voir les informations liées aux hôtes

Figure 34 : informations sur les hôtes


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Cliquez sur le lien statistique en haut pour voir les statistiques liées aux flux et aux ports des
switchs

Figure 35 : statistique des ports des switch

V. INSTALLATION DE WIRESHARK DANS MININET

Wireshark est un analyseur de paquets libre et gratuit. Il est utilisé dans le dépannage et


l’analyse de réseaux informatiques, le développement de protocoles, l’éducation et la rétro-
ingénierie.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 36 : installation Wireshark

CHAPITRE V : TEST DE LA SOLUTION

I. PLANIFICATION DU COMPORTEMENT DU RESEAU


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Ici nous allons résumer le comportement du réseau en précisant, le trafic bloqué et les
chemins empruntés par les paquets qui seront transmis :
o Le switch S1 est isolé du reste du réseau, les hôtes qui y sont connectées ne
communiquent qu’entre eux. Nous avons utilisé des règles pare-feu de couche 3,
bloquant tous les paquets allant et venant du sous réseau aux quelles appartient les
hôtes h1 et h2.
o H3 et h5 ne communiquent pas, un pare-feu couche 2 leur sera appliqué.
Hormis la restriction citée préalablement, les chemins empruntés par les différents flux qui
atteignent les switchs de distribution sont les suivants :
o Le trafic provenant ou allant vers les laptops (h3 et h6), est distribué par s4. Le lien
vers le switchs 5 de distribution servira de redondance. Si une panne survient sur cette
liaison(s4), les paquets passeront par s5. Ceci peut être réalisé en instaurant un délai
d’inactivité. Si aucune correspondance n’est détectée durant un temps donné, les
entrées inactives sont retirées des tables de flux.
o Le reste du trafic entre les switchs h4 et h7 transitera par s5. S4 servira de redondance.

1. Installation des flux

 Synthèse des entrées de flux


Dans cette section les règles introduites dans les différents switchs sont résumés sous forme
de tables de flux. Concernant les adresses MAC seul le dernier octet sera mentionné.

Tableau 9 : tableau des flux OpenFlow 1

OpenFlow :1
ID MAC Src MAC Dest IP Src IP Dest Action Priorité
flux
105 00 :00 :00 :00 :00 :01 00 :00 :00 :00 :00 :0 * * Port de 2000
2 sortie : 3
110 00 :00 :00 :00 :00 :02 00 :00 :00 :00 :00 :0 * * Port de 2000
1 sortie : 4
115 * * 10.0.0.0 10.0.0.0 Effacer 1500

Tableau 10 : tableau des flux OpenFlow 2

OpenFlow :2
ID flux MAC Src MAC Dest IP Src IP Dest Action Priorité
205 00 :00 :00 :00 :00 :03 * * * Port de 2000
sortie : 1
210 00 :00 :00 :00 :00 :04 * * * Port de 2000
sortie : 2
215 * 00 :00 :00 :00 :00 :0 * * Port de 2000
6 sortie : 1
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

220 * 00 :00 :00 :00 :00 :0 * * Port de 2000


7 sortie : 2

Tableau 11 : tableau de flux OpenFlow 3

OpenFlow :3
ID flux MAC Src MAC Dest IP Src IP Dest Action Priorité
305 00 :00 :00 :00 :00 :06 * * * Port de 2000
sortie : 1
310 00 :00 :00 :00 :00 :07 * * * Port de 2000
sortie : 2
315 * 00 :00 :00 :00 :00 :0 * * Port de 2000
3 sortie : 1
320 * 00 :00 :00 :00 :00 :0 * * Port de 2000
4 sortie : 2

2. Méthode d’implémentation des flux


Les différentes méthodes ont été présentées dans le chapitre précédent. Pour la suite nous
allons nous baser sur l’application OFM. La raison principale de ce choix, est la visibilité
qu’offre l’interface graphique de l’application, ce qui simplifie l’édition et la suppression de
flux installés auparavant. Il serait encombrant d’illustrer l’introduction de tous les flux dans
l’application, et d’autant plus répétitif. Nous allons seulement afficher ci-dessous, l’un des
flux introduits.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 37 : installation de l'entrée flux 102

II. TEST DE FONCTIONNEMENT

Un nombre de test a été effectué pour confirmer que l’objectif du scénario a bien été atteint.
Nous avons subdivisé ces tests en 3 catégories.

1. Test d’accessibilité
Le réseau se comporte comme prévu en termes d’accessibilité, ce qui confirme la fiabilité des
restrictions appliquées.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 38 : test d'accessibilité des hôtes

2. Test d’orientation du trafic


Pour ce test nous avons utilisé l’analyseur de paquets wireshark. Celui-ci nous permettra
de visualiser le trafic traversant des interfaces prédéfinis.

Les 3 figures suivantes confirment que les flux empruntent les chemins précédemment définis
dans les tables de flux.

- H5 et H6 communiquent à travers S 4(Figure 40).

- H2 et H7 communiquent à travers S5 (Figure 41)

Figure 39 : capture wireshark d'un ping entre h5 et h6


IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 40 : capture wireshark d'un ping entre h5 et h8

3. Test de redondance
Pour tester la redondance des liens nous supprimerons la liaison entre s2 et s4 avec la
commande Link s2 s4 down sur Mininet.

Le contrôleur détecte que le lien est défectueux comme l’atteste la figure suivante. Cependant
il faut d’abord rafraichir la page pour voir la liaison entre s2 et s4 disparaître ce qui n’est pas
pratique en milieu de production.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

Figure 41 : détection de la perte de liaison s2 s4 ODL

Ensuite une capture wireshark nous permettra de voir que le trafic entre h1 et h3 a été
réorienté vers la liaison secondaire s1 s7.

Figure 42 : capture wireshark test de redondance

CONCLUSION

Au terme de ce chapitre ou il était question de testé la solution implémentée à travers


les tests d’accessibilités, d’orientations du trafic et de redondance. Il en ressort que ces tests
ont était réussi avec succès.

CONCLUSION GENERALE

Arrivé au terme de notre stage qui a porté sur le thème IMPLEMENNTATION


D’UNE ARCHITECTURE SDN LAN : CAS SINARES , il convient de rappeler qu’il était
question pour nous, d’une part de présenter SINARES en faisant ressortir la phase d’insertion,
présenter une étude de notre thème au travers

ANNEXE
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

BIBLIOGRAPHIE

[7] Ahmed Sonba et Hassan Abdalkreim, « Performance Comparison Of the state of the art
Openflow Controllers », mémoire de Master , Université Halmstad Sweden, Décembre 2014.
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

[3] Jérôme Durand, « Le SDN pour les nuls », Montpellier, JRES 2015.

Webographie
Github. (2017). Mininet VM images. Consulté sur :
https://github.com/mininet/mininet/wiki/Mininet-VM-Images
Open Networking Foundation, (2014). OpenFlow Switch Specification version 1.5.0.
Consulté sur : http://www.opennetworking.org/wp
Project Floodlight, (2016). Floodlight. Consulté sur :
http://www.projectfloodlight.org/floodlight/
The Linux Foundation. (s.d). Open vSwitch documentation. Consulté sur :
http://docs.openvswitch.org/en/latest/
Idoudi, K. (2014) Implémentation d'un plan de contrôle unifié pour les réseaux multicouches
IP / DWDM (Mémoire de Master). Université de Montréal.
Cisco Dev Net. (2014). OpenDaylight OpenFlow Manager (OFM) App. Consulté sur :
https://github.com/CiscoDevNet/OpenDaylight-Openflow-App
Sites Web
[40] http://www.openvswitch.org/ dernier access Juliet 2016
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

GLOSSAIRE

API : Application programing interface


BGP : BorderGatewayProtocol
CLI : Command Line Interface (Ligne de commande)
Gb : Giga Bit HTTP
IoT : Internet of Things (Internet des objets)
IP : Internet Protocol
LAN : Local Area Network
MAC : Media Access Control
Naas : Network as a Service
NETCONF : NETwork CONFiguration protocol
NIB : Network Information Base
ODL : OpenDaylight
OF : OpenFlow
OFM : OpenFlow Manager
ONF : Open Networking Foundation
ONOS : Open Network Operating System
OVF : Open View Finder
OVS : Open Virtual Switch
OXM : OpenFlow eXtensible Match
RAM : Read Access memory
REST : REpresentational State Transfer
SAL : Service Abstraction Layer
SDN : Software Defined Network
SNMP : Simple Network Management Protocol
SSH : Secure Shell
TCAM : Tenary contenant addressables memory
TCP : Transmission Control Protocol
TLS : Transport Layer Security
TTL : Time To Live
UDP : User Datagram Protocol
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

VLAN : Virtual Local Area Network


VM : Virtual Machine (Machine virtuelle)
WAN : Wide Area Network
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES

S-ar putea să vă placă și