Software Defined Networking : Comme un peu le « Cloud » qui était le mot à la mode il y a quelques années, chaque fournisseur de service, a une opinion différente sur ce qu’est exactement le « SDN » et sur les différents produits qu’il propose.

La mise en réseau traditionnelle utilise un modèle distribué pour le plan de contrôle.

Les protocoles comme ARP, STP, OSPF, EIGRP, et autres s’exécutent séparément sur chaque périphérique réseau.

Et ces périphériques réseau communiquent entre eux, mais aucun équipement central ne dispose d’une vue d’ensemble ou ne contrôle l’ensemble du réseau.

La seule exception est sur les réseaux sans fil, avec les contrôleurs WLAN. (WLC : Wireless LAN Controller).

Lorsqu’on configure un réseau sans fil, tout se passe sur le contrôleur WLAN, qui contrôle et configure les points d’accès.

Il n’est plus nécessaire de configurer chaque point d’accès séparément, tout est fait par le contrôleur WLAN.

Eh bien le principe est le même qu’avec le SDN : on utilise un contrôleur central pour le plan de contrôle.

Le contrôleur SDN peut être un équipement physique ou même une machine virtuelle.

Sur le schéma, on peut voir le contrôleur SDN qui est responsable du plan de contrôle.

Les commutateurs ne sont plus que des appareils, moins intelligents, qui n’ont qu’un plan de données, et aucun plan de contrôle.

C’est le contrôleur SDN qui est chargé d’alimenter le plan de données de ces commutateurs avec les données de son plan de contrôle.

Alors, il y a tout de même, certains avantages et inconvénients à avoir un plan de contrôle distribué par rapport à un plan de contrôle central.

L’un des avantages d’un contrôleur central est que l’on peut configurer l’ensemble du réseau à partir d’un seul appareil.

Le contrôleur central a un accès complet et un aperçu de tout ce qui se passe dans le réseau.

Voici un nouveau schéma avec plus de détail :

Ici, on voit que le contrôleur SDN utilise deux interfaces assez spéciales…

On a l’interface nord (NBI : NorthBound Interface) et l’interface Sud (SBI : SouthBound Interface).

C’est ce qu’on va détailler tout de suite.

Software Defined Networking : Interface vers le sud (SBI : SouthBound Interface)

On va commencer par l’interface qui mène vers le sud.

Le contrôleur SDN doit communiquer avec les périphériques réseau dans le but, de programmer le plan de données.

Cela se fait par l’interface sud.

Alors ce n’est pas une interface physique, mais une interface purement logicielle, qui est souvent une API (Application Programming Interface).

L’API est une interface logicielle qui permet à une application de donner accès à d’autres applications en utilisant des fonctions et des structures de données prédéfinies qu’on détaillera dans la suite du cours.

On va maintenant détailler les 3 types d’interfaces sud, les plus populaires :

• L’OpenFlow : est probablement le SBI (SouthBound Interface) le plus populaire en ce moment, c’est un protocole open source de l’ONF (Open Networking Foundation).
  L’OpenFlow est pris en charge par la plupart des périphériques réseau et des contrôleurs SDN.
• Ensuite, on a le Cisco OpFlex : qui est la réponse de Cisco à l’OpenFlow. C’est aussi un protocole open source qui a été soumis à l’IETF (Internet Engineering Task Force) pour le normaliser.
• Et on a la traditionnelle CLI (Command-Line Interface) : Cisco propose le contrôleur APIC-EM (Application Policy Infrastructure Controller Enterprise Module) qui est une solution SDN ou solution Software Defined Networking.
• pour les dernières générations de routeurs et de switch. Il utilise des protocoles déjà existants comme Telnet, SSH et SNMP.

Software Defined Networking : Interface vers le nord (NBI : NorthBound Interface)

Passons maintenant à l’interface vers le Nord.

L’interface « nord » est utilisée pour accéder au contrôleur SDN en lui-même.

Ce qui permet à l’admin réseau d’y accéder pour le configurer ou pour y récupérer des informations.

Alors même si ça peut être fait par une interface graphique (GUI), il y a aussi une API qui permet à d’autres applications d’accéder au contrôleur SDN.

On peut utiliser l’API pour écrire des scripts et automatiser l’administration du réseau.

Voici quelques exemples de script, qu’il est possible de lancer :

• On peut répertorier les informations de tous les équipements de son réseau.
• On peut afficher l’état de toutes les interfaces physiques du réseau.
• Ajoutez un nouveau VLAN sur tous les switchs.
• Affichez la topologie de l’ensemble du réseau.
• Et même, configurez automatiquement les adresses IP, le routage et les ACL lorsqu’une nouvelle machine virtuelle est créée.

Et voici un schéma qui montre les différentes possibilités d’accéder au contrôleur SDN :

Grâce à l’API, plusieurs applications peuvent accéder au contrôleur SDN ou Software Defined Networking:

• Un utilisateur peut utiliser une interface graphique pour récupérer des informations sur le réseau à partir du contrôleur SDN.
  En vrai l’interface graphique utilise l’API.
• Les scripts écrits en Java ou en Python peuvent aussi utiliser l’API pour récupérer des informations à partir du contrôleur SDN ou même pour configurer directement le réseau.
• Et d’autres applications peuvent aussi accéder au contrôleur SDN. Ça peut être, par exemple, une application qui configure automatiquement le réseau, dès qu’une nouvelle machine virtuelle est créée sur un serveur VMware ESXi.

API REST

Nous avons vu que les interfaces nord et sud utilisent des API (Application Programming Interface).
Nous allons maintenant examiner de plus près, ce qu’est une API.

Les contrôleurs SDN utilisent généralement une API REST (Application Programming Interface REpresentational State Transfer), qui permet d’utiliser des messages « http » pour envoyer et recevoir des informations entre le contrôleur SDN et une autre application.

Il s’agit des mêmes messages « http » que l’on utilise lorsque l’on parcourt une page Web sur Internet ou lorsqu’on saisit un formulaire de contact, par exemple :

• « HTTP GET » : est utilisé lorsque nous voulons récupérer des informations.
• Et « HTTP POST » ou « HTTP PUT » : est utilisé lorsque nous voulons télécharger ou mettre à jour des informations.

L’API REST fonctionne comme si on naviguait sur une page web, sauf qu’ici, on ne demande pas d’afficher une page ou une image, mais plutôt un objet particulier du contrôleur SDN.
Par exemple, ça peut être de lister tous les VLAN du réseau.

Lorsque le contrôleur SDN reçoit une « requête HTTP GET » (http GET request), il répond avec une « réponse HTTP GET » (http GET reply) contenant les informations demandées.

Et ces informations sont fournies dans un format de données spécifique.

Les deux formats de données les plus utilisés sont :

• Le JSON (JavaScript Object Notation)
• Et le XML (eXtensible Markup Language)

Voici un exemple qui permet de visualiser le processus.

Ici, nous avons un script python qui utilise « HTTP GET » pour récupérer une URL via l’API.

Cette URL permet de récupérer certaines variables, par exemple des informations sur les hôtes du réseau.

Et une fois que l’API a reçu cette demande, elle répondra avec une réponse « HTTP GET » :

Les variables demandées seront fournies au format « JSON ».

Même si on n’a jamais vu de JSON, on peut tout de même assez facilement, comprendre la sortie.

Par exemple, ici, le résultat nous retourne, 2 hôtes avec leurs adresses IP et leurs mac-adresse.

L’avenir du réseau traditionnel

Software Defined Networking : J’espère que ce cours vous a permis de mieux comprendre en quoi consiste le SDN et pourquoi le marché d’aujourd’hui lui est très favorable, par rapport au bénéfice qu’il peut donner.

Le temps nous dira à quoi ressemblera le réseau à l’avenir.

Il est fort probable que dans un futur proche, nous utiliserons plus souvent l’API que la CLI.

Alors est-ce que les admins réseau devraient s’inquiéter de l’arrivée de la programmation dans le réseau ?

Eh bien, je ne pense pas…

Car un programmeur peut être très fort dans les langages de programmation, comme C++, Java ou python, mais il aura forcément besoin de connaissance en réseau.

Par contre, les admins réseau devront apprendre à utiliser un langage de programmation, pour exécuter certains scripts de base, mais sans forcément apprendre à développer une application complète, en partant de zéro.

Ça, c’est plutôt le rôle du programmeur.

Il serait donc judicieux de passer quelque temps à apprendre un langage comme Python et à utiliser des API.

Pour le moment, nous ne savons pas à quel point, se développera le SDN ou Software Defined Networking, mais ce scénario me rappelle un peu ce qui est arrivé à la téléphonie analogique.

Il y a beaucoup de « vétérans de la téléphonie » qui ont refusé d’apprendre le fonctionnement de la VoIP, pensant qu’il était impossible de remplacer la téléphonie traditionnelle.

Aujourd’hui, ces « anciens de la téléphonie » sont devenus un peu dépassés, dans un monde dominé par la VOIP.

De mon côté, ancien téléphoniste, c’est grâce à l’arrivée de cette nouvelle technologie, qui m’a mis sur la voie de la certification Cisco, et m’a fait découvrir le merveilleux monde du réseau !

N’oubliez pas de vous abonner à la chaîne YouTube Formip.