SDN (Software-defined network / Réseau défini par logiciel)

Le SDN est une approche de l’architecture réseau qui permet de contrôler ou de programmer le
réseau de manière intelligente et centralisée à l’aide d’applications logicielles.

Architecture traditionnelle : repose sur l’utilisation des switchs, routeurs et firewalls utilisés pour des
tâches spécifiques, et configurés par CLI ou GUI.

Ex : Soit une architecture d’un Datacenter d’une entreprise (on voudrait installer une nouvelle VM)
sur le serveur ESXi qui accueille les VMs. On suppose que l’entreprise vaut installer une application
qui demande l’installation de 4 nouveaux VMs sur le serveur Vmware ESXi (pour des raisons de
sécurité, on applique à chaque VM des 4 un VLAN approprié). L’utilisateur PCA doit pouvoir accéder à
l’application qui se trouve sur ces 4 VM.

La solution traditionnelle exige de l’admin réseau d’exécuter toutes les étapes suivantes (qui
prennent bcp de temps) :

- 1 – Crée l’ensemble des VLANs sur tous les commutateurs.

- 2 – Configurer le root bridge pour les nouveaux VLANs.
 - 3 – attribuer 4 sous réseaux : 1 pour chacun des 4 VLANs.
- 4 – Créer des nouvelles sous-interfaces avec des adresses IP sur les commutateurs.
- 5 – Configurer la redondance pour les nouvelles VLANs : Par le protocole VRRP ou HSRP.
- 6 – Configurer les firewalls pour qu’on puisse accéder à l’application et aux différents sous-
réseaux.
- 7 – Annoncer les nouveaux sous-réseaux dans un protocole de routage sur les
commutateurs, routeurs et firewall.

Architecture avec SDN : Pour le plan de contrôle, on utilise un contrôle centralisé (comme c’est le cas
pour un réseau WLAN qui est géré par des WLC : il n’est pas nécessaire de configurer chaque point
d’accès séparément, les APs sont configurés par le WLC.

Dans l’architecture traditionnelle, il n y’a pas (dans un réseau LAN) un équipement qui peut
centraliser la gestion.

Dans un réseau SDN, on utilise un contrôleur SDN (qui peut être une appliance physique ou une
machine virtuelle).
C’est le contrôleur SDN qui charge les plans des données des équipements (switchs…) par le contenu
de son plan de contrôle. Le contrôleur SDN a un accès complet et un accès de tous ce qui passe sur le
réseau rendant les équipements réseaux moins intelligents.

Soit l’architecture suivante où le contrôleur SDN utilise deux interfaces, north (NBI) et south (SBI) :

L’interface sud (SouthBond) est purement logicielle (API) et pas physique.

Ex d’un spec sur CPS d’un switch bar-metal :

Figure :

Les 3 types de la SBI (SouthBond Interface) sont :

- L’OpenFlow (le protocole le plus répandu). Son architecture est (ci-dessous) :

- Cisco OpenFlex (réponse de Cisco à l’openflow) → A noter que Cisco propose pour le SDN le
module Apic-EM.
- CLI
L’interface nord (NorthBond Interface) permet à accéder au contrôleur SDN en lui-même. C’est par
lui que l’admin réseau accède → A noter qu’il y’a des API qui permettent à des applications à accéder
directement au contrôleur SDN. On peut utiliser l’API pour écrire des scripts et automatiser
l’administration du réseau.

Ces scripts peuvent permettre de : - Répertorier les informations de tous les équipements de son
réseau.

- Afficher l’état de tous les interfaces physiques du réseau.

- Ajouter un nouveau VLAN sur le switch.
- Afficher la topologie de l’ensemble des équipements du réseau.
- Configurer automatiquement les tables de routage, les ACL quand une nouvelle machine
virtuelle est créée.

-
Comme montré sur la figure. Grâce à l’API, plusieurs applications peuvent accéder au
contrôleur SDN, un utilisateur peut récupérer des donnés réseaux à travers le contrôleur.

Les contrôleurs SDN utilisent généralement des API REST

Figure : Requête d’un script (GET) de python à l’API

Figure : Réponse de l’API