Documente Academic
Documente Profesional
Documente Cultură
_______________________ _______________________
RAPPORT DE STAGE
THEME :
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 :
SOMMAIRE
DEDICACES...............................................................................................................................I
REMERCIEMENTS..................................................................................................................II
SOMMAIRE.............................................................................................................................IV
RESUME...................................................................................................................................V
ABSTRACT.............................................................................................................................VI
INTRODUCTION..............................................................................................................2
I. ACCUEILLE................................................................................................................2
CONCLUSION...................................................................................................................8
I. PRESENTATION DU THEME.................................................................................10
III. PROBLEMATIQUE..............................................................................................13
INTRODUCTION............................................................................................................14
I. OBJECTIFS...............................................................................................................14
V. CONTEXT..............................................................................................................15
VI. PLANIFICATION..................................................................................................16
INTRODUCTION............................................................................................................33
I. CHOIX DU CONTROLEUR.....................................................................................33
II. PuTTY....................................................................................................................39
IV. MININET...............................................................................................................44
CONCLUSION.................................................................................................................59
ANNEXE..............................................................................................................................60
BIBLIOGRAPHIE................................................................................................................61
GLOSSAIRE.........................................................................................................................62
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.
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.
1
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
INTRODUCTION
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.
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.
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
4. Activités
5. Produits
3
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
SRP (School Ressource Planning) : ensemble de logiciels web et outils pour l’aide
à la bonne gouvernance scolaire et universitaire ;
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
4
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
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.
6
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
Direction
Générale
Direction
Direction Direction Administrative
Technique Commerciale et
Financière
Administration
R&D Production
Technique
7
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
CONCLUSION
8
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
9
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
I. PRESENTATION DU THEME
1. Ressources matérielles
SINARES dispose de plusieurs équipements informatiques dont nous pouvons
énumérer :
Tableau 1: ressources matérielles
2. Ressources logicielles
SINARES dispose de plusieurs logiciels dont :
LOGICIELS VERSIONS
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
3. Architecture réseau
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
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
INTRODUCTION
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
Switch SDN.
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
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.
1. Ressource humaine
Nous avons recensé pour la réalisation de notre projet trois informaticiens. Le tableau suivant
donne un aperçue :
Ressources Prix
Humaines 800 000
Logicielles
Imprévues 300 000
Total
1. L’informatique en nuage
IMPLEMENTATION D’UNE ARCHITECTURE LAN SDN : CAS SINARES
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
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
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
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.
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.
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.
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.
Les champs des entrées qui composent les tables de flux sont globalement structurés comme
suit.
Compteurs
Actions
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
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.
1.5. L’orchestrateur
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
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
5. Sécurité
ET LE SDN
Tableau 6:Comparaison entre le réseau traditionnel et le SDN
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
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.
Big Switch Networks, Cisco, Citrix, Ericsson, IBM, Juniper Networks, Microsoft, Red Hat ou
encore VMware sont ainsi les membres fondateurs d’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
3. Tableau comparatif
Tableau 7: Tableau comparatif OpenDaylight et Floodlight
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
Installer OpenDaylight
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).
II. PuTTY
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".
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
DANS OPENDAYLIGHT
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).
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
Installation de grunt
IV. MININET
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 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
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 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
Téléchargez Mininet VM
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
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 :
3. Topologie proposée
La configuration de base des différents hôtes est donnée par la table suivante :
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
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.
Cliquez sur le lien Flow Management en haut pour voir les entrées de flux.
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
Supprimé un flux
Cliquez sur le lien Host pour voir les informations liées aux hôtes
Cliquez sur le lien statistique en haut pour voir les statistiques liées aux flux et aux ports des
switchs
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.
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
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
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
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
Les 3 figures suivantes confirment que les flux empruntent les chemins précédemment définis
dans les tables de flux.
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
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.
CONCLUSION
CONCLUSION GENERALE
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