Page de Garde

• Titre du rapport : Migration et Optimisation d'un Réseau d'Entreprise vers une

Architecture SDN

• Votre Nom et Prénom

• Nom de l'entreprise d'accueil

• Nom de votre établissement d'enseignement

• Tuteurs de stage (entreprise et académique)

• Période du stage

• Année universitaire

Remerciements

• Remerciez vos tuteurs en entreprise et à l'école, les membres de votre équipe, et toute
personne ayant contribué à la réussite de votre stage.

Résumé

• Un paragraphe concis en français qui présente le contexte du stage, la problématique de

la migration réseau, la démarche adoptée (analyse, conception, implémentation,
validation), les technologies clés (SDN, OpenFlow), et les principaux résultats obtenus
(amélioration de la flexibilité, de la gestion et de la sécurité).

Abstract

• Traduction du résumé en anglais.

Table des Matières

• Liste structurée de toutes les sections du rapport avec les numéros de page.

Liste des Figures

• Répertoire de toutes les figures (schémas d'architecture, graphiques de performance,

captures d'écran) avec leur titre et numéro de page.

Liste des Tableaux

• Répertoire de tous les tableaux (comparatifs, résultats de tests, configurations) avec leur
titre et numéro de page.
Liste des Acronymes

• Glossaire des termes techniques et abréviations utilisés (SDN, NFV, API, OVS, LAN, WAN,
etc.).

Introduction Générale

1. Contexte du Stage

o Présentation de l'entreprise d'accueil, son secteur d'activité et sa place sur le

marché.

o Description du département ou de l'équipe dans laquelle le stage s'est déroulé.

o Introduction à la problématique générale de l'évolution des infrastructures

réseau face aux nouvelles exigences (agilité, sécurité, automatisation).

2. Problématique et Objectifs

o Description des limites du réseau traditionnel existant (complexité de gestion,

manque de flexibilité, coûts opérationnels élevés).

o Définition de la problématique : Comment faire évoluer l'infrastructure réseau

actuelle pour répondre aux besoins futurs de l'entreprise de manière efficiente et
sécurisée ?

o Objectifs du stage :

▪ Analyser l'architecture réseau existante.

▪ Étudier et proposer une architecture cible basée sur le SDN.

▪ Définir une stratégie de migration progressive.

▪ Mettre en œuvre un PoC (Proof of Concept) ou une phase pilote de la

migration.

▪ Valider les bénéfices de la nouvelle architecture.

3. Démarche et Plan du Rapport

o Présentation de la méthodologie suivie (analyse, conception, implémentation,

tests).

o Annonce de la structure du rapport, en décrivant brièvement le contenu de

chaque chapitre.
Chapitre 1 : Contexte Général et État de l'Art

• Inspiration : Le document "A Migration Path to Software-Defined Networking (SDN) in

an Enterprise Network" d'Allied Telesis (pages 1-3) est excellent pour cette partie. Il
expose clairement pourquoi une migration progressive est nécessaire et quels en sont les
avantages. La thèse "Gestion dynamique et évolutive de règles de sécurité pour l’Internet
des Objets" (pages 9-19) offre une très bonne introduction académique au concept du
SDN.

1. Les Réseaux Traditionnels : Architecture et Limites

o 1.1. Architecture des réseaux d'entreprise classiques (modèle hiérarchique à 3

couches).

o 1.2. Couplage des plans de contrôle et de données.

o 1.3. Limites : gestion manuelle complexe, manque d'agilité, difficultés

d'automatisation et de sécurisation.

2. Le Paradigme Software-Defined Networking (SDN)

o 2.1. Définition et concept fondamental du SDN.

o 2.2. Architecture SDN : couche application, couche de contrôle (contrôleur SDN),

couche infrastructure.

o 2.3. Les interfaces clés : Northbound et Southbound APIs (ex: OpenFlow).

o 2.4. Avantages attendus : centralisation de la gestion, automatisation, flexibilité,

réduction des coûts.

▪ Pour cette section, référez-vous au document d'Allied Telesis, section

"Why change to SDN?" (page 2) qui détaille les avantages comme la
réduction des coûts, l'augmentation de la flexibilité et de la sécurité.

3. Stratégies de Migration vers le SDN

o 3.1. Les défis d'une migration réseau (risques d'interruption, complexité).

o 3.2. Approches de migration : "Big Bang" vs. Progressive (hybride).

o 3.3. Le modèle de migration en trois phases (unifié, hybride, déploiement

optimal).
 • Inspiration : La thèse "Gestion dynamique et évolutive de règles de sécurité..." (Chapitre
6 : Implémentation, pages 79-101) est une mine d'or pour cette partie. Elle détaille les
outils (OpenDaylight, Open vSwitch), la création des machines virtuelles, et la
configuration pas à pas.

1. Mise en Place de l'Environnement de Test (Maquette)

o 1.1. Description de la plateforme de virtualisation et de simulation (ex: GNS3,

EVE-NG, VMware).

o 1.2. Outils utilisés :

▪ Contrôleur SDN : OpenDaylight, ONOS, etc.

▪ Commutateurs virtuels : Open vSwitch (OVS).

▪ Machines virtuelles pour les tests.

2. Déploiement et Configuration du Contrôleur SDN

o 2.1. Installation et configuration de base du contrôleur.

o 2.2. Configuration des modules nécessaires (ex: L2 switching, OpenFlow plugin).

3. Configuration des Équipements Réseau

o 3.1. Intégration des commutateurs (physiques ou virtuels) avec le contrôleur.

o 3.2. Configuration du protocole OpenFlow et sécurisation du canal de

communication.

4. Déploiement des Politiques Réseau

o 4.1. Implémentation des règles de routage et de commutation via le contrôleur.

o 4.2. Configuration des politiques de sécurité (ex: règles de pare-feu dynamiques).

Chapitre 4 : Tests, Résultats et Validation

4.1. Protocole de Validation et Outils de Mesure

• 4.1.1. Scénarios de Validation

o Scénario 1 : Validation de la Connectivité Dynamique (Flow Provisioning)

 ▪ Objectif : Vérifier que le contrôleur SDN installe dynamiquement les
règles de flux nécessaires à la communication entre deux hôtes qui n'ont
jamais communiqué.

▪ Méthode : Lancer un premier ping entre PC1 et PC2. Le premier paquet

doit être envoyé au contrôleur (table-miss), qui doit ensuite installer les
règles aller-retour dans l'OVS. Les pings suivants doivent passer
directement via le plan de données.

o Scénario 2 : Validation des Politiques de Sécurité (Filtrage)

▪ Objectif : Démontrer la capacité du contrôleur à appliquer une politique

de sécurité de type pare-feu.

▪ Méthode : Après avoir établi la connectivité, utiliser l'API REST de

OpenDaylight pour pousser une règle interdisant le trafic ICMP (ping)
entre PC1 et PC2. Lancer un nouveau ping et vérifier que la
communication est bien bloquée.

o Scénario 3 : Tests de Performance (Latence)

▪ Objectif : Mesurer la latence de bout en bout et évaluer l'impact

potentiel de l'architecture SDN sur ce critère.

▪ Méthode : Effectuer une série de pings avec des tailles de paquets

variées entre PC1 et PC2 et analyser les temps de réponse moyens,
minimum et maximum.

o Scénario 4 : Test de Haute Disponibilité du Plan de Données

▪ Objectif : Vérifier que le plan de données continue de fonctionner même

en cas de perte de connexion avec le contrôleur.

▪ Méthode : Établir un flux de communication continu (ping -t). Simuler

une panne en coupant la connexion entre l'OVS et le contrôleur
OpenDaylight. Observer que le flux existant n'est pas interrompu.

• 4.1.2. Outils de Mesure et de Validation

o VPCS (Virtual PC Simulator) : Outil principal pour générer le trafic de test via la
commande ping et vérifier la connectivité de base.

o Open vSwitch Command Line Utilities (ovs-ofctl) : Outil essentiel pour inspecter
la table de flux de br0 avant et après chaque test, afin de visualiser les règles
installées ou supprimées par le contrôleur.
 o OpenDaylight API (via Postman ou cURL) : Outil utilisé pour interagir avec l'API
RESTCONF du contrôleur afin de pousser manuellement les règles de sécurité du
scénario 2.

o Interface Graphique OpenDaylight (DLUX) : Outil de supervision pour visualiser

la topologie découverte par le contrôleur et vérifier que les hôtes et les liens
sont correctement identifiés.

4.2. Résultats et Analyse des Tests

• Inspiration : Cette section doit être très visuelle, comme dans le rapport de Mälardalen
University (mohammed2019.pdf, pages 19-28), mais en utilisant vos propres captures
d'écran de terminal et de l'interface ODL.

• 4.2.1. Résultat de la Validation de la Connectivité Dynamique

o Présentation des captures d'écran de ovs-ofctl dump-flows br0 avant le premier

ping (table de flux vide ou avec seulement la règle par défaut).

o Présentation de la capture d'écran du terminal VPCS montrant le premier ping

avec une latence potentiellement plus élevée, suivi de pings réussis.

o Présentation des captures d'écran de ovs-ofctl dump-flows br0 après le premier

ping, montrant clairement les deux nouvelles règles de flux (aller et retour)
installées par le contrôleur.

o Analyse : Commenter le succès du processus, expliquant le rôle du contrôleur

dans l'établissement de la communication.

• 4.2.2. Résultat de la Validation des Politiques de Sécurité

o Présentation de la requête REST (via Postman ou cURL) envoyée à

OpenDaylight pour bloquer le trafic ICMP.

o Présentation de la capture d'écran de ovs-ofctl dump-flows br0 montrant la

nouvelle règle de "drop" (rejet) avec une priorité plus élevée.

o Présentation de la capture d'écran du terminal VPCS montrant l'échec des pings

(Request timed out ou Destination host unreachable).

o Analyse : Conclure sur l'efficacité de la gestion de la sécurité centralisée, qui

permet de modifier le comportement du réseau en temps réel depuis une seule
commande.
 • 4.2.3. Analyse des Performances (Latence)

o Présenter un tableau synthétisant les résultats des tests de ping (Min, Max,
Moyenne).

o Analyse : Discuter des résultats. La latence est-elle acceptable ? Est-elle stable ?

Comparer (si possible) avec une connexion directe sans OVS pour évaluer le
surcoût (overhead) du commutateur virtuel.

• 4.2.4. Résultat du Test de Haute Disponibilité

o Présenter une capture d'écran du terminal VPCS montrant la séquence de pings

continus qui ne s'interrompent pas après la coupure du lien avec le contrôleur.

o Présenter une capture d'écran de l'interface d'EVE-NG montrant le lien entre

OVS et ODL désactivé.

o Analyse : Expliquer le concept de séparation des plans : bien que le plan de

contrôle soit indisponible, le plan de données continue d'opérer sur la base des
règles déjà installées, garantissant ainsi la continuité du service pour les flux
existants.

4.3. Synthèse et Discussion

• 4.3.1. Synthèse des Validations

o Tableau récapitulatif des tests et de leurs résultats (Succès/Échec).

o Bref résumé confirmant que l'architecture déployée répond aux principaux

objectifs fonctionnels.

• 4.3.2. Discussion sur les Défis Rencontrés

o Décrire brièvement les difficultés techniques que vous avez pu rencontrer (ex:
configuration de la VM OpenDaylight, problèmes de compatibilité, complexité
de l'API REST).

o Expliquer comment vous avez surmonté ces défis.

Conclusion Générale et Perspectives

1. Bilan du Stage
 o Synthèse du travail accompli et rappel des objectifs atteints.

o Discussion sur l'apport de la solution SDN pour l'entreprise (ROI qualitatif).

2. Apports Personnels et Professionnels

o Compétences techniques et humaines acquises.

o Difficultés rencontrées et comment elles ont été surmontées.

3. Limites et Perspectives

o Limites du projet (périmètre du PoC, etc.).

o Perspectives d'évolution : extension du déploiement, intégration de la NFV,

développement d'applications réseau personnalisées.

Bibliographie

• Liste des ouvrages, articles scientifiques, documentations techniques et sites web

consultés.

Annexes

• Scripts de configuration, résultats de tests bruts, schémas détaillés, etc.

Ce plan vous fournit une structure solide et professionnelle pour rédiger un rapport complet et
bien argumenté. N'hésitez pas à l'adapter en fonction des spécificités exactes de votre projet de
stage. Bonne redaction