6.1.2 – SDN (Software Defined Networking)

6.1.2 – SDN (Software Defined Networking)

Le SDN (Software-Defined Networking) est une approche révolutionnaire dans le domaine du réseau qui transforme la façon dont les réseaux sont conçus, gérés et opérés. Sa caractéristique la plus notable est sa capacité à centraliser la gestion du Control Plane, ou plan de contrôle, des réseaux. Voici une présentation plus détaillée de cette capacité et de ses implications :

Centralisation du Control Plane

  1. Décentralisation dans les Réseaux Traditionnels : Dans un réseau traditionnel, chaque dispositif réseau (comme un routeur ou un commutateur) a son propre Control Plane. Cela signifie que chaque dispositif prend des décisions indépendantes sur la manière de gérer et de diriger le trafic réseau, en utilisant des protocoles comme ARP, OSPF, ou BGP.
  2. Rôle du Control Plane Centralisé dans le SDN : Le SDN modifie cette approche en centralisant le Control Plane au sein d’un contrôleur SDN. Ce contrôleur agit comme le cerveau du réseau, prenant toutes les décisions importantes concernant le routage et la gestion du trafic pour l’ensemble du réseau. Cette centralisation permet une vue globale du réseau, facilitant la prise de décisions optimisées et cohérentes pour le routage et la gestion du trafic.

Avantages de la Centralisation

  1. Gestion et Configuration Simplifiées : Avec un Control Plane centralisé, les administrateurs réseau peuvent gérer l’ensemble du réseau à partir d’un seul point, plutôt que de configurer chaque dispositif séparément. Cela simplifie considérablement la gestion du réseau.
  2. Réactivité et Flexibilité Accrues : Le SDN permet de répondre rapidement aux changements dans les besoins du réseau. Les politiques et configurations peuvent être mises à jour rapidement et de manière cohérente à travers tout le réseau.
  3. Automatisation et Programmabilité : La centralisation ouvre la voie à une plus grande automatisation. Les administrateurs peuvent programmer le contrôleur SDN pour qu’il réagisse automatiquement à certaines conditions ou événements du réseau.
  4. Optimisation du Trafic : Avec une vue d’ensemble du réseau, le SDN peut optimiser les chemins de trafic, améliorant ainsi l’efficacité et la performance du réseau.
  5. Intégration avec les Technologies Émergentes : Le SDN facilite l’intégration avec des technologies telles que le cloud computing et les services virtualisés, offrant une gestion plus dynamique des ressources réseau.

Conclusion

En résumé, le SDN transforme la gestion des réseaux en centralisant le Control Plane, offrant ainsi une gestion simplifiée, une plus grande agilité, une automatisation accrue, et une optimisation du trafic. Cette approche moderne ouvre la voie à des réseaux plus intelligents, plus efficaces et mieux adaptés aux défis technologiques actuels et futurs.

Southbound Interface

Le contrôleur SDN doit communiquer avec nos dispositifs réseau pour programmer le plan de données. Ceci est réalisé via l’interface sud (southbound interface). Il ne s’agit pas d’une interface physique, mais plutôt d’une interface logicielle, souvent une API (Application Programming Interface).

Une 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. Je vais expliquer cela plus en détail dans un instant.

Quelques interfaces sud populaires sont :

  • OpenFlow : c’est probablement l’interface SBI la plus populaire actuellement, c’est un protocole open source de l’Open Networking Foundation. De nombreux dispositifs réseau et contrôleurs SDN prennent en charge OpenFlow.
  • Cisco OpFlex : c’est la réponse de Cisco à OpenFlow. C’est aussi un protocole open source qui a été soumis à l’IETF pour normalisation.
  • CLI : Cisco propose APIC-EM, une solution SDN pour la génération actuelle de routeurs et de commutateurs. Elle utilise des protocoles disponibles sur le matériel de génération actuelle comme telnet, SSH et SNMP.

Northbound Interface

L’interface nord (northbound interface) est utilisée pour accéder au contrôleur SDN lui-même. Cela permet à un administrateur réseau d’accéder au SDN pour le configurer ou pour récupérer des informations. Cela pourrait être fait via une GUI, mais elle offre également une API qui permet à d’autres applications d’accéder au contrôleur SDN. Vous pouvez l’utiliser pour écrire des scripts et automatiser votre administration réseau. Voici quelques exemples :

  • Lister les informations de tous les dispositifs réseau de votre réseau.
  • Afficher le statut de toutes les interfaces physiques dans le réseau.
  • Ajouter un nouveau VLAN sur tous vos commutateurs.
  • Montrer la topologie de l’ensemble de votre réseau.
  • Configurer automatiquement les adresses IP, le routage et les listes d’accès lorsqu’une nouvelle machine virtuelle est créée.

Voici une illustration pour vous aider à visualiser cela :

Via l’API, plusieurs applications sont capables d’accéder au contrôleur SDN :

  • Un utilisateur utilisant une GUI pour récupérer des informations sur le réseau depuis le contrôleur SDN. En coulisse, la GUI utilise l’API.
  • Des scripts écrits en Java ou Python peuvent utiliser l’API pour récupérer des informations du contrôleur SDN ou configurer le réseau.
  • D’autres applications peuvent accéder au contrôleur SDN. Peut-être une application qui configure automatiquement le réseau une fois qu’une nouvelle machine virtuelle est créée sur un serveur VMware ESXi.

REST API

J’ai mentionné à plusieurs reprises que les interfaces nord (northbound) et sud (southbound) utilisent des APIs. Examinons de plus près ce qu’est une API. Les contrôleurs SDN utilisent généralement une API REST (Representational State Transfer).

L’API REST utilise des messages HTTP pour envoyer et recevoir des informations entre le contrôleur SDN et une autre application. Elle utilise les mêmes messages HTTP que ceux utilisés lorsque vous naviguez sur une page web sur Internet ou lorsque vous remplissez un formulaire de contact en ligne :

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

Cela ressemble à la navigation sur une page web, mais cette fois, vous ne demandez pas une page web ou une image mais un objet particulier du contrôleur SDN, par exemple, une liste de tous les VLANs dans le réseau.

Lorsque le contrôleur SDN reçoit la requête HTTP GET, il répondra avec une réponse HTTP GET contenant les informations demandées. Ces informations sont livrées dans un format de données commun. Les deux formats de données les plus utilisés sont :

  • JSON (JavaScript Object Notation)
  • XML (eXtensible Markup Language)

Voici un exemple pour vous aider à visualiser cela :

sdn controller northbound http get

Ci-dessus, nous avons un script python qui utilise HTTP GET pour récupérer l’URL suivante via l’API :

https://192.168.1.1:8443/sdn/v2.0/net/nodes

Cette URL va récupérer certaines des variables disponibles, par exemple, des informations sur tous les nœuds (hôtes) du réseau.

Une fois que l’API reçoit cela, elle répondra avec un message de réponse HTTP GET :

Les variables demandées seront fournies au format JSON. Voici à quoi cela ressemble :

{
	"nodes": [
		{
		"ip": "172.16.1.1",
		"mac": "fa16.3e5d.f1f4",
		"vid": 0,
		"dpid": "00:00:00:00:00:00:00:03",
		"port": 1
	}, {
		"ip": "172.16.1.2",
		"mac": "fa16.3e5d.f1f5",
		"vid": 0,
		"dpid": "00:00:00:00:00:00:00:03",
		"port": 2
	}
]
}

Même si vous n’avez jamais vu du JSON auparavant, la sortie ci-dessus est facile à lire. Elle nous indique que nous avons deux nœuds sur le réseau, leurs adresses IP et MAC.

REST API

La leçon que nous avons abordée devrait vous donner une compréhension générale du concept de SDN (Software-Defined Networking) et pourquoi il est de plus en plus recherché dans le secteur. Dans des leçons futures, j’aborderai des exemples concrets de configurations pour des solutions SDN telles qu’Open SDN, Openflow, OpenDayLight, Cisco ACI et Cisco APIC-EM.

Quant à l’avenir des réseaux, il est probable qu’à l’avenir, l’utilisation des API devienne plus courante que celle de la ligne de commande (CLI). Est-ce un changement problématique ? À mon avis, non. Un programmeur spécialisé en C/C++, Java ou Python doit aussi comprendre les réseaux. Savoir exécuter des scripts simples avec un langage de programmation est un atout ; il n’est pas nécessaire de développer une application complète, cela relève de la compétence d’un programmeur.

Il est cependant conseillé d’apprendre un langage de programmation comme Python et de se familiariser avec les API. Bien que l’avenir exact du SDN soit encore incertain, nous pourrions assister à un changement similaire à celui qu’a connu la téléphonie analogique. De nombreux experts en téléphonie traditionnelle qui ont choisi de ne pas se mettre à jour avec la VoIP se sont retrouvés dépassés dans un monde désormais dominé par cette technologie.