Mastère spécialisé – Réseaux et Services

NET 6511

Software Defined Networking

(SDN)
Intervenante : Dr. Nour El-Houda Yellas
[Link]@[Link]
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

2
 Evolution des réseaux (1)
▪ Terminaux
• Plus hétérogènes (sans fil, mobiles, capteurs…), nombreux, puissants, petits …

▪ Applications
• Web (e-commerce, e-learning…), courrier électronique, VoIP, streaming, réseaux sociaux, e-gaming,…

▪ Cloud computing
• Synchronisation des données depuis partout
• Accès à des ressources depuis partout (datacenters)

▪ Internet of Things (IoT)

• Capteurs, objets connectés (télé, enceinte, thermostat…)
• Industrie du futur, télémétrie, surveillance…
• Technologies réseaux d’accès : LoRa, Sigfox, BLE, Li-Fi…

3
Ces innovations concernent la périphérie de réseaux !!
Evolution des réseaux (2)
… mais peu dans les cœurs de réseau
▪ Des progrès quantitatifs
• Ex : Capacité des réseaux optiques Mbps → Tbps
▪ Mais assez peu d’innovations de ruptures
• Encore en commutation de paquets
▪ Même si MPLS (~2000)
• Encore des algorithmes de routage dynamique (OSPF, BGP)
▪ Pas de routage QoS
• Toujours pas (ou très peu) d’ingénierie de trafic
▪ Pas d’optimisation d’un réseau en analysant son trafic

4
Gestion complexe des réseaux
▪ Dimension gigantesque
• En taille et nombre de nœuds

▪ Hétérogénéité des équipements

• Inter-opérabilité entre équipementiers différents
• Bugs/incompatibilités dans les logiciels

▪ Jusqu’à 20 millions de lignes de code pour certains routeurs

• Interfaces de contrôles propriétaires et donc différentes

▪ Algorithmes/protocoles distribués
• Difficile d’anticiper ou de forcer des décisions (Ingénierie de trafic)

▪ Middleboxes
• Boîtes noires (fermés et propriétaires) 5
Coût de déploiement et d’exploitation élevé
▪ Un marché trop étroit
- Nombre limité d’équipementiers
- Environ une dizaine d’acteurs

▪ Equipements peu modulaires et évolutifs

- Fermés
- Logiciels livrés avec le hardware
- Code source fermé et propriétaire

6
 Défis pour le cœur du réseau
▪ Au début des années 2000, des chercheurs jugent urgent de
- Lever les freins à l’innovation
- Simplifier la gestion des réseaux
- Baisser leurs coûts

▪ Et proposent comme réponse à ces 3 défis

- Le SDN, le NFV et le network slicing

Feamster, N., Rexford, J., & Zegura, E. (2014). The road to SDN: an intellectual history of programmable networks. ACM
7
SIGCOMM Computer Communication Review, 44(2), 87-98.
Nouveaux paradigmes

8
Plan de contrôle et plan de données
▪ Plan : endroit où un traitement spécifique est exécuté → les paquets sont traités en
utilisant le plan de données et le plan de contrôle
▪ Plan de données
• Transporte les données des applications
• Achemine, filtre et modifie les paquets
▪ Plan de contrôle
• Pour le fonctionnement du réseau
• Décide comment acheminer les paquets (calcul des routes, surveillance de la topologie,
configuration automatique des équipements réseaux)
▪ Plan de gestion
• Généré par l’administrateur
• Agit sur le plan de contrôle par l’intervention de l’admin
▪ Le plan de données achemine les paquets selon les règles du plan de contrôle 9
Réseaux traditionnels (1)

• Plan de données : distribué sur les nœuds

• Plan de contrôle : distribué sur les nœuds
• Plan de gestion : distribué sur les nœuds
10
Réseaux traditionnels (2)
▪ Architecture d’un routeur : Plan de données et plan de contrôle

11
Réseaux traditionnels : plan de contrôle
▪ Souvent mis en œuvre par des algorithmes distribués

• Avantage
- Robustesse et tolérance aux pannes

• Inconvénients
- Nécessite un niveau élevé d’interopérabilité entre les équipements réseaux
- Complexe de “forcer” des opérations du plan de contrôle (congestion sur un lien → forcer le
passage sur un lien par l’administrateur)

12
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

13
Software Defined Networking (1)
▪ D'un contrôle distribué vers un contrôle centralisé

▪ Réseaux traditionnels (niveaux 2 et 3) : sont complètement dominés par les

protocoles de routage/commutation distribués
• RIP, OSPF, BGP, STP

▪ Aucun nœud n'a une vision globale du réseau

• manque un « cerveau » du réseau pour faire des optimisations difficiles et efficaces

▪ Les protocoles de contrôle et de données partagent le même réseau

• problèmes de sécurité, le trafic de données gêne le trafic de contrôle
14
Software Defined Networking (2)
▪ Réseaux SDN
• découplage du plan de contrôle du plan de données
▪ Plan de données
• mécanismes permettant de faire avancer les trames et les paquets dans le réseau
▪ Plan de contrôle
• fonctions nécessaires pour déterminer les tables de transfert (tables de flots)
▪ Un contrôleur (plan de contrôle) ayant une vision globale dirige les
commutateurs /routeurs (plan de données) avec les stratégies programmables
comme un logiciel
▪ Le plan de contrôle et le plan de données ne partagent pas le même réseau

15
Software Defined Networking (3)
▪ Propriétés
• Un plan de contrôle centralisé dans un ou plusieurs contrôleurs
• Une interface ouverte et universelle pour programmer le plan de données
• Des commutateurs plus simples remplacent les routeurs complexes

▪ Vers la fin de l’algorithmie distribuée dans les réseaux mais …

• Réseaux agiles et programmables
• Interface de contrôle simplifiée et universelle
• Développement de chaînes de traitement des paquets

16
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

17
Architecture SDN
▪ SDN sépare le plan de contrôle et le plan de données dans un réseau :

▪ Southbound
• OpenFlow
• NETCONF

▪ Northbound
• REST API

18
 Composantes et interfaces (1)

M. Rouse, L. Rosencance, J. English, and J. Burke, Software-defined Networking (SDN), [Link], Aug. 2019.
19
[Online]. Available: https : / / searchnetworking .[Link]/definition/software-defined-networking-SDN.
 Composantes et interfaces (2)
❑ La couche d'application

▪ Représente les programmes ou les applications qui

communiquent via NBI avec le contrôleur SDN et qui
fournissent le comportement requis du réseau.

▪ Ces applications peuvent inclure l'équilibrage de la

charge, le pare-feu, la topologie du réseau,
l'application de politiques, l'optimisation de la bande
passante du réseau et bien d'autres encore.

20
 Composantes et interfaces (3)
❑ L'interface NorthBound (NBI)

▪ Assure la communication entre l'application et le

contrôleur SDN. L'interface NorthBound est
constituée d'une variété d'API/protocoles différents,
comme l'API REST.

▪ Littéralement, l'interface NorthBound assure la «

compréhension » entre le contrôleur SDN et
l'application spécifiant le comportement du réseau.

21
 Composantes et interfaces (4)
❑ La couche de contrôle

▪ Principalement représentée par le contrôleur SDN ou

tout autre système d'exploitation de réseau (NOS).
Elle traduit les exigences de l'utilisateur dans un
format spécifique à l'appareil et abstrait la vue de
l'état du réseau. Doit inclure plusieurs interfaces NBI
et SBI.

▪ Peut également être représentée par plusieurs

contrôleurs SDN (cluster) communiquant entre eux via
l'interface East/WestBound..

22
 Composantes et interfaces (5)
❑ L'interface SouthBound (SBI)

▪ Assure la communication entre le contrôleur SDN et

l'équipement de réseau. SBI se compose d'une
variété de protocoles tels que OpenFlow, NETCONF,
RESTCONF, P4 et bien d'autres.

▪ Cette interface est également responsable de la

collecte des données de surveillance et de
l'information de l'utilisateur sur les changements
immédiats de l'état du réseau.

23
 Composantes et interfaces (6)
❑ La couche infrastructure

▪ Représentée par divers équipements réseau, tels

que les commutateurs OpenFlow, les routeurs TOR
ou les serveurs, avec des capacités de commutation
et de traitement annoncées.

▪ Dans le cadre de SDN, le commutateur est un

matériel de commutation. Ce type de commutateur
permet à l'application, située au-dessus du
contrôleur SDN, de spécifier la table de routage et de
déterminer comment acheminer les connexions
pour accomplir la tâche appropriée.

24
 Composantes et interfaces (7)
❑ L'interface East/WestBound (EWBI)

▪ Garantit la communication entre différents

contrôleurs SDN dans des réseaux
distribués.

▪ Elle nécessite une normalisation et

beaucoup de recherches à mener.

25
Normalisation des architectures SDN
▪ Normalisation des techniques SDN afin d'éviter des solutions hétérogènes
• ONF (Open Networking Foundation)

▪ Normalisation des communications entre le contrôleur et les nœuds de transfert

hétérogènes

▪ Plusieurs protocoles développés :

• OpenFlow : premier protocole à réaliser la communication entre le contrôleur et les nœuds
du réseau
• Utilisé par l'ONF comme modèle de base pour la communication
• D'autres protocoles ont été développés : NetConf, OpFlex (de Cisco), ...etc.

26
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

27
Protocoles de l’interface sud
▪ OpenFlow
▪ P4
▪ OVSDB
▪ NetConf
▪ RestConf

28
Interface southbound : OpenFlow
▪ OpenFlow est le protocole le plus utilisé dans les API Southbound. Premier protocole à être défini
pour le SDN et constitue la norme de facto pour le SDN.

▪ Permet au contrôleur SDN de programmer directement le comportement d'acheminement des

périphériques de réseau, tels que les commutateurs et les routeurs. Utilise un mécanisme simple
de mise en correspondance des paquets avec les flux et un ensemble d'actions à effectuer sur les
paquets correspondants.

▪ Largement pris en charge par de nombreux fournisseurs de réseaux, et de nombreux contrôleurs

SDN open-source, tels que OpenDaylight et ONOS.
29
 Interface southbound : P4
▪ Programming Protocol-independent Packet Processor ou P4

▪ Langage qui décrit comment les paquets doivent être traités par l'élément de
commutation. Ne spécifie pas le comportement du plan de contrôle du
commutateur.

▪ Comparé à OpenFlow, P4 se concentre uniquement sur le plan de données, sans

aucune interaction avec le plan de contrôle. Le langage P4 introduit un niveau ultime
d'agilité et offre une grande flexibilité en ajoutant de nouvelles fonctionnalités et en
supprimant les protocoles inutiles et non utilisés.
30
P4 project overview, Open Networking Foundation.
 Interface southbound : OVSDB
▪ Open vSwitch Database Management Protocol ou OVSDB

▪ Protocole de gestion dans un environnement SDN. Il a été spécifié dans la RFC 7047. Il a été
initialement créé dans le cadre du logiciel open-source Open vSwitch (OVS), un commutateur
virtuel pour les hyperviseurs basés sur Linux, avec de nombreuses fonctionnalités diverses.

▪ OpenFlow permet de gérer les flux ou les règles de commutation, tandis qu'OVSDB est une
solution pour la configuration des appareils. Le protocole Open vSwitch Database
Management Protocol permet de configurer les ports, les ponts, et de créer/supprimer des
interfaces sur l'appareil.

31
B. Pfaff and B. Davie, The Open vSwitch Database Management Protocol, RFC 7047, Internet Engineering Task Force.
Interface southbound : NETCONF
▪ Network Configuration Protocol ou NETCONF est un protocole utilisé pour
configurer les appareils réseau. Il offre une méthode normalisée pour gérer les
équipements et permet aux administrateurs réseau d'automatiser les tâches de
configuration.

▪ Utilise XML pour représenter les données de configuration et un ensemble

d'opérations normalisées pour manipuler les données.

▪ Largement soutenu par de nombreux fournisseurs de réseaux et est souvent

utilisé en combinaison avec YANG (Yet Another Next Generation), un langage de
modélisation de données utilisé pour définir les données de configuration et
d'état des appareils réseau.

32
Interface southbound : RESTCONF
▪ RESTful Network Configuration Protocol ou RESTCONF est un protocole utilisé
pour configurer les appareils réseau via une API RESTful.

▪ Version simplifiée de NETCONF, conçue pour être plus facile à utiliser et plus
intuitive.

▪ Utilise HTTP pour représenter les données de configuration et un ensemble

d'opérations normalisées, telles que GET, POST, PUT et DELETE, pour manipuler
les données.

33
Interface southbound : comparaison
Protocole Usage

OpenFlow Commutation/forwarding

P4 Commutation/forwarding

OVSDB Configuration

NETCONF Configuration

RESTCONF Configuration

34
OpenFlow
• Protocole de signalisation de l'interface sud pour SDN

• Permet la communication entre le contrôleur (plan de

contrôle) et l’équipement réseau (plan de données)

• Permettre au contrôleur de
• Ajouter
• Mettre à jour
• Supprimer
les règles de traitement des flux dans les équipements
réseaux
35
Installation des règles OpenFlow
• Packet-In
• Envoyé par un commutateur vers le contrôleur pour demander la règle de traitement d’un
flux
• Packet-Out
• Envoyé par un contrôleur vers un commutateur pour installer une règle de traitement d’un
flux

36
Commutateur OpenFlow

• Table de flux (Flow Table)

• Contient les règles de traitement des flux
• Il s’agit d’une table de commutation

• Table de groupe
• Chaque groupe contient un certain nombre d’ensembles
d’actions (action buckets) à appliquer sur chaque copie d’un
paquet

• Canal OpenFlow
• Pour la communication avec le contrôleur externe via le
protocole OpenFlow
• Permettre de mettre à jour les tables de flux
37
Table de flux (1)
▪ Définition des tables de flux
• réalisée par le contrôleur
• se trouvant dans d'autres machines en plus des routeurs et commutateurs (serveur physique,
VM dans un datacenter ou plusieurs serveurs distribués)
▪ Nœuds de transfert : utilisation des routes calculées par le contrôleur pour
forwarder les flots utilisateurs
▪ Possibilité de virtualiser le contrôleur pour le placer dans le Cloud

38
Table de flux (2)
Format des règles pour le traitement des paquets (plan de données)
- correspondance : selon les en-têtes des paquets
- action : supprimer, expédier, modifier ou transmettre au contrôleur
- priorité : arbitrer si plusieurs correspondances possibles
- compteur : #octets and #paquets pour chaque règle

Exemples :
- src=1.2.*.*, dest=3.4.5.* → drop
- src=*.*.*.*, dest=3.4.*.* → forward(2)
- src=[Link], dest=*.*.*.* → send to controller

39
 Table de flux (3)
• Matched fields -> counter -> instructions
• Quand un paquet correspond aux critères de sélection (matched fields) d’un flux dans la table de
flux, les instructions seront appliquées pour traiter le paquet
• Instruction (« Goto») peut orienter le paquet à une autre table de flux ou à la table de groupe
• Si le paquet ne correspond à aucun flux dans la table, le traitement dépend de l’entrée « Table-
miss » configurée (rejeter le paquet, envoyer le paquet au contrôleur, à une autre table, etc.)

Flow entry

40
Table de flux (4)
Routeur Pare-feu (Firewall)
• correspondance : plus long • correspondance : adresses IP et
préfixe IP partagé #ports (TCP/UDP)
• action : réexpédier sur un lien • action : autoriser ou refuser

Commutateur (switch) NAT

• correspondance : adresse MAC • correspondance : adresses IP et
destination #ports
• action : réexpédier ou inonder • action : réécrire les adresses et
ports
… 41
Table de flux (5)
• Matched fields

• ETH_DST : Adresse Ethernet destination

• ETH_SRC : Adresse Ethernet source
• ETH_TYPE : Type de données Ethernet
• VLAN_ID : Numéro de VLAN (Virtual Local Area Network)
• IP_DSCP : Numéro DSCP (DiffServ Code Point)
• IP_SRC : Adresse IP source
• IP_DST : Adresse IP destination
• MPLS_LABEL : Label MPLS

42
Table de flux (6)
• Actions

• PUSH_MPLS : Ajouter un label MPLS

• POP_MPLS : Retirer un label MPLS
• PUSH_VLAN : Ajouter un VLAN ID
• DECREMENT_TTL : Décrémenter la valeur TTL (Time To Live)
• OUTPUT : Envoyer vers le port de sortie indiqué
• GOTO_TABLE : Consulter la table de flux indiquée
• DROP : Rejeter le paquet

43
Table de flux : acheminement
• Mode Réactif
- 1er paquet d’un flot : le commutateur interroge le contrôleur
- Le contrôleur décide et en informe les commutateurs concernés : ajout d’une nouvelle règle dans les
tables d’acheminement
- Réduit la taille des tables mais surcoût additionnel
- La décision du chemin est prise flux par flux lors de la réception d’un message PACKET_IN venant d’un
commutateur

• Mode Pro-actif
- Le contrôleur préremplit les tables d’acheminement dans les commutateurs
- Suppose des règles agrégées pour traiter tous les cas possibles
- Mise à jour fréquente
- Le contrôleur peut anticiper et installer à l’avance les règles d’acheminement dans les
commutateurs

• Souvent les 2 modes cohabitent : ensemble de règles préétablies + exceptions 44

Traitement d’un paquet par le commutateur

45
Messages OpenFlow
Contrôleur → commutateur Commutateur → contrôleur
• Features • Packet-in
• Pour demander les capacités du commutateur
(e.g. taille du buffer, nombre de tables) • Flow-removed
• Configuration • Port-status
• Pour configurer les paramètres (e.g. taille • Error
maximale des messages à envoyer au
contrôleur)
Commutateur → contrôleur
• Packet-out
• Installer les règles de traitement d’un flux • Hello
• Flow-Mod • Echo
• Apporter les modifications à une table de flux

46
Etablissement de connexion OpenFlow

47
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

48
Contrôleurs SDN
▪ NOX
• [Link]
▪ POX
• [Link]
▪ ONOS
• [Link]
▪ Ryu
• [Link]
▪ OpenDayLight
• [Link]
▪ Floodlight
• [Link]

49
Contrôleur SDN : Performance
▪ Mesuré en nombre de requêtes/s
▪ Ou le temps nécessaire pour traiter une requête

50
 Contrôleurs SDN : clusters

▪ Plusieurs contrôleurs SDN peuvent collaborer

pour gérer un grand réseau (east/west interfaces)

• Mode back-up (pour la redondance)

• Mode balance (pour le partage de charge)

Hashemi Natanzi, Seyed bagher and Mohammad Reza Majma. “Secure distributed controllers in SDN based on ECC public key
infrastructure.” 2017 International Conference on Electrical and Computing Technologies and Applications (ICECTA) (2017): 1-5. 51
 Contrôleurs SDN : trafic inter-contrôleurs
▪ Les contrôleurs échangent des messages entre eux pour assurer la cohérence des
informations de contrôle (par exemple, la topologie)

52
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

53
OpenFlow Discovery Protocol (OFDP)
▪ Permettre à un contrôleur SDN de détecter la topologie du réseau
▪ Encapsuler les messages du protocole LLDP (Link Layer Discovery Protocol)
▪ OFDPv1
• Le contrôleur envoie un paquet LLDP à chaque port de chaque commutateur pour découvrir
la topologie
▪ OFDPv2
• Un seul paquet LLDP (message Packet-Out) est envoyé à chaque commutateur pour découvrir
la topologie

54
Détection des liens
▪ Le contrôleur envoie à chaque port d’un commutateur un paquet PACKET_OUT
encapsulant un paquet LLDP

▪ Le commutateur envoie le message LLDP à tous les ports de sortie

▪ Le commutateur recevant le message LLDP forme

un message PACKET_IN encapsulant le paquet
LLDP et l’envoie au contrôleur

55
 Link Layer Discovery Protocol (LLDP)
▪ Un protocole distribué permettant à un réseau classique de découvrir la topologie du réseau

▪ LLDP frame structure

▪ Type-Length-Value (TLV)
▪ Chassis ID TLV
▪ Port ID TLV
▪ TTL TLV
▪ End TLV
56
Performances OFDP
▪ Pour disposer d’une topologie du réseau mise à jour, le contrôleur doit envoyer
périodiquement les massages OFDP
• Exemple : 15 secondes pour FloodLight
▪ Dans chaque cycle de découverte de la topologie
• Nombre de messages de PACKET_IN

(L est le nombre de liens unidirectionnels entre les commutateurs)

• Nombre de messages de PACKET_OUT

(Pi est le nombre de ports de sortie du commutateur i​, N est le nombre de

commutateurs dans le réseau)
57
Amélioration de OFDP
▪ Plusieurs protocoles sont proposés pour améliorer le protocole
OFDP
▪ TEDP (Tree Exploration Discovery Protocol)
▪ SLDP (SDN Link Discovery Protocol)
▪ sOFTDP (Secure and Efficient Topology Discovery Protocol)
▪ eTDP (Enhanced Topology Discovery Protocol)

58
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

59
Cas d’usage : réseaux sans fil/Wifi (1)
▪ Gérer les points d’accès Wi-Fi
▪ La vue globale du contrôleur SDN est très bénéfique
▪ Gestion d’interférence
▪ Partage de charge
▪ Qualité de service
▪ Gestion de la fonctionnalité MLO (Multi-Link Operation)

60
 Cas d’usage : SD-WAN
▪ SD-WAN : Software-Defined Wide Area Networks
▪ Contrôle centralisé et optimisation du WAN
▪ Il est possible d’acheminer les flux d’un domaine Internet à un autre en
choisissant le chemin de-bout-en-bout le plus performant au lieu de passer par
un réseau MPLS
▪ Routage basé sur des politiques centralisées
▪ Sélection dynamique des liens et basculement
▪ Transfert orienté application

▪ Vise à optimise la connectivité entre sites distants

[Link] 61
Plan
• Evolution des réseaux
• Réseaux programmables ou Software Defined Networks (SDN)
• Architecture SDN​ et fonctionnement
• Protocoles SDN et standards (OpenFlow, P4, NETCONF, RESTCONF, OVSDB)
• Contrôleurs SDN
• Découverte de la topologie réseau
• Cas d’usage
• Exemple de mise en œuvre : Mininet

62
Mininet
▪ Mininet est un émulateur réseau qui émule
• Machine terminale (End-host)
• Commutateur
• Routeur
• Lien
▪ Dans un seul kernel Linux
▪ Mininet est largement utilisé dans la recherche pour émuler et tester les réseaux
SDN

63
 Emulation d’un contrôleur OpenFlow
▪ Les commutateurs dans Mininet supportent OpenFlow
▪ Un contrôleur OpenFlow interne est disponible dans
Mininet
▪ Le commutateur communique avec le contrôleur à
l’adresse IP locale ([Link]) via TCP (e.g. port 6633 ou
6653)
▪ L’accès à l’espace utilisateur d’un commutateur se fait via
l’adresse IP locale et le numéro de port qui suit le numéro
de port utilisé pour communiquer avec le contrôleur (dans
cet exemple: 6633 + 1 = 6634)

64
 Création d’une topologie réseau
▪ Il est facile de créer une topologie réseau avec Mininet en utilisant les lignes de commande
▪ Pour créer un réseau ayant un seul commutateur et 3 hôtes et tester la connectivité
$ sudo mn --test pingall --topo linear,3

▪ Pour créer un réseau en topologie linéaire de 4 commutateurs, chacun a un hôte connecté, et

tester la connectivité
$ sudo mn --test pingall --topo tree,depth=2,fanout=3

Depth: correspond à la hauteur

Fanout: correspond au nombre
de feuilles.
65
Création d’une topologie réseau personnalisée

▪ Il est possible de créer une topologie

personnalisée en utilisant un
programme écrit en Python

$ sudo mn custom
/chemin/vers/[Link] --topo
topotest

66
Utilisation de Mininet avec un contrôleur externe
▪ Il est possible d’utiliser Mininet avec un contrôleur externe (OpenDaylight, ONOS,
etc.)
$ sudo mn --controller=remote,ip=<controller_IP_address>

67
Mininet-Wifi
▪ Emulateur de réseau qui étend Mininet pour prendre en charge les
réseaux sans fil

▪ La topologie est composée de :

▪ Stations (STA) : clients sans fil mobiles (comme des smartphones ou des
ordinateurs portables)
▪ Points d’accès (AP) : bornes Wi-Fi (commutateurs de niveau 2 avec des
capacités sans fil)
▪ Commutateurs filaires (optionnels)
▪ Contrôleurs SDN : contrôleurs internes ou externes qui gèrent la logique de
transfert,
▪ Liens : peuvent être sans fil (entre STA et AP) ou filaires (par exemple, entre
un AP et un commutateur ou un contrôleur).

68
A retenir
▪ Les réseaux peuvent être programmables
• pas seulement configurables
• ou prédéfinis
▪ Il faut cependant penser différemment...
• changement de paradigme
▪ Primitives OpenFlow
• match flexible
• actions flexibles
• messages : packet-in/out, flow-mod, stats, status

69
Références
▪ SDN
"Software Defined Networks: A Comprehensive Approach" by Paul Goransson and
Chuck Black

▪ OpenFlow
[Link]

▪ Mininet
[Link]
[Link]

70
Questions

71
Questions (1)
1. C’est quoi le SDN ?
• Séparation du plan de contrôle et plan de données
• Utilisation d’un contrôleur centralisé pour la prise de
décision de forwarding

2. Rappelez les principaux caractéristiques du SDN.

• Centralisation, programmabilité, flexibilité et agilité,
abstraction au niveau de l’application et des utilisateurs
(pas besoin de connaître le fonctionnement sous-jacent)
72
Questions (2)
3. Quelle est la différence entre les réseaux
conventionnels(traditionnels) et les réseaux SDN ?
• Architecture : routage décentralisé vs. contrôle centralisé
• Flexibilité : difficiles à adapter vs. Programmable
• Gestion : coûteuse car chaque appareil est indépendant des autres vs.
Centralisée et simple

4. Donnez les différents composants de l’architecture SDN puis

citez 5 contrôleurs SDN.
• Plan d’application, plan de contrôle, plan de données, interface sud et interface
nord
• Pox, Nox, ODL, ONOS, Ryu, Floodlight

73
Questions (3)

5. Citez 4 protocoles de l’interface sud.

• OVSDB, OpenFlow, NetConf, P4

74
Questions (4)
6. Le SDN est caractérisé par la présence d’un contrôleur qui centralise toute
l’intelligence du réseau et qui est responsable notamment du plan de
contrôle. Quel problème de sécurité pose-t-il selon vous ?
• Single point of failure

7. Quelle solution proposez-vous pour faire face à ce problème notamment

pour des systèmes critiques demandant de la haute disponibilité ?
• Redondance et distribution du contrôleur (cluster de contrôleurs)
• Mécanisme de tolérance aux pannes avec des contrôleurs
secondaires

75
Préparation de l’environnement pour le TP
• Télécharger la machine virtuelle via le lien :
[Link]
(ubuntu: docker + mininet + onos)
• Installer et lancer Virtualbox (ou VMware)

• Importer le fichier .ova téléchargé à la première étape dans

Virtualbox. Pour tout utilisateur autre qu’Ubuntu, s’il y a une
notification concernant l’interface de l’adaptateur réseau, choisissez
‘Change network adapter’.

76