Dans notre article précédent, nous avons eu un bon aperçu du SDN en tant que technologie, pourquoi il est nécessaire et comment l'industrie informatique l'adopte. Maintenant, allons plus loin et comprenons l'architecture du SDN et le rôle du protocole Openflow dans la mise en œuvre de la technologie.
Le SDN se compose en gros de trois couches :
- Couche d'application
- Couche de contrôle
- Couche d'infrastructure
Essayons de comprendre ces couches dans une approche ascendante.
Couche d'infrastructure est composé de divers équipements de mise en réseau qui forment un réseau sous-jacent pour transférer le trafic réseau. Il peut s'agir d'un ensemble de commutateurs et de routeurs réseau dans le centre de données. Cette couche serait la couche physique sur laquelle la virtualisation du réseau serait établie via la couche de contrôle (où les contrôleurs SDN seraient assis et géreraient le réseau physique sous-jacent).
Couche de contrôle est le pays du plan de contrôle où résiderait la logique intelligente des contrôleurs SDN pour contrôler l'infrastructure du réseau. C'est le domaine dans lequel chaque fournisseur de réseau travaille pour proposer ses propres produits pour le contrôleur et le framework SDN. Ici, dans cette couche, une grande partie de la logique métier est écrite dans le contrôleur pour récupérer et maintenir différents types d'informations sur le réseau, les détails de l'état, les détails de la topologie, les détails des statistiques, etc.
Étant donné que le contrôleur SDN est destiné à la gestion des réseaux, il doit donc avoir une logique de contrôle pour les cas d'utilisation réels du réseau comme la commutation, le routage, le VPN L2, le VPN L3, les règles de sécurité du pare-feu, le DNS, le DHCP et le clustering. Plusieurs fournisseurs de réseaux et même des communautés open source travaillent sur la mise en œuvre de ces cas d'utilisation dans leurs contrôleurs SDN. Une fois mis en œuvre, ces services exposent leurs API (généralement basées sur REST) à la couche supérieure (couche application), ce qui facilite la vie des administrateurs réseau qui utilisent ensuite des applications au-dessus des contrôleurs SDN pour configurer, gérer et surveiller le réseau sous-jacent. La couche de contrôle se situe au milieu et expose deux types d'interfaces :vers le nord et vers le sud.
- Interface en direction du nord :est destiné à la communication avec la couche application supérieure et serait en général réalisé via les API REST des contrôleurs SDN. S interface sortante :est destiné à la communication avec la couche d'infrastructure inférieure des éléments de réseau et serait en général réalisé via des protocoles vers le sud - Openflow, Netconf, Ovsdb, etc.
Couche d'application est un espace ouvert pour développer autant d'applications innovantes que possible en exploitant toutes les informations du réseau sur la topologie du réseau, l'état du réseau, les statistiques du réseau, etc. Il peut y avoir plusieurs types d'applications qui peuvent être développées comme celles liées à l'automatisation du réseau, la configuration du réseau et gestion, surveillance du réseau, dépannage du réseau, politiques et sécurité du réseau. Ces applications SDN peuvent fournir diverses solutions de bout en bout pour les réseaux d'entreprise et de centres de données du monde réel. Les fournisseurs de réseau proposent leur ensemble d'applications SDN. Par exemple, Brocade a les applications très utiles suivantes :
- Optimiseur de flux Brocade
- Routeur virtuel Brocade
- Conseiller du réseau Brocade
HPE est également un fournisseur proposant une boutique d'applications SDN, qui contient également de nombreuses applications SDN de différentes sociétés. Par exemple :
- Optimiseur de réseau HPE
- Protecteur de réseau HPE
- Visualiseur de réseau HPE
- NEC UNC pour HP SDN VAN Controller
- Équilibreur de charge SDN d'Aricent
- Direction intelligente du flux TechM
- Équilibreur de charge du serveur TechM
Comme nous avons brièvement abordé Openflow dans l'article précédent, nous couvrons maintenant les détails de la communication vers le sud de la couche de contrôle à la couche d'infrastructure (commutateurs réseau) via le protocole Openflow.
Openflow a joué un rôle déterminant dans la révolution du SDN en ce sens qu'il a été la clé de la séparation du plan de contrôle du plan de données. Openflow est la spécification standard fournie par l'Open Networking Foundation (ONF) et évolue au fil du temps avec la prise en charge de diverses exigences des réseaux mondiaux actuels. La version actuelle du protocole Openflow est 1.5.1.
Openflow est un protocole qui fournit des spécifications standard pour la communication entre le contrôleur SDN et l'équipement réseau (généralement des commutateurs). Il permet aux contrôleurs SDN de prendre des décisions de routage et de laisser les règles de transfert, les règles de sécurité étant poussées sur les commutateurs du réseau sous-jacent.
Le contrôleur et les commutateurs SDN doivent mettre en œuvre les spécifications Openflow afin qu'ils puissent comprendre le langage commun des messages Openflow. Pour contrôler les commutateurs réseau, le contrôleur SDN applique des règles aux commutateurs afin qu'ils puissent prendre des décisions lorsque le trafic réseau les atteint. Les commutateurs doivent conserver ces règles dans le tableau Openflow. Selon Openflow, ces règles sont appelées "flux" et elles sont stockées dans des "tables de flux".
En gros, les flux transportent trois types d'informations :
- Champs de correspondance :ils définiront des critères pour faire correspondre les paquets en fonction de leurs champs d'en-tête – L2 (adresses Ethernet de destination source, ID VLAN, priorité VLAN, etc.), L3 (IPv4/ Adresse de destination source IPv6, type de protocole, DSCP, etc.), champs L4 (port de destination source TCP/UDP/SCTP), champs ARP, champs ICMP, champs MPLS, etc.
- Actions :elles définiront ce qu'il faut faire avec un paquet s'il correspond aux critères. Les actions seraient comme abandonner, transférer sur un port de commutateur, modifier le paquet (ID VLAN push/pop, étiquette MPLS push/pop, incrémenter/décrémenter IP TTL), transférer vers une file d'attente spécifique du port, etc.
- Compteurs :pour suivre le nombre de paquets correspondant au flux
Pour être précis, les flux contiennent des informations supplémentaires qui peuvent être vérifiées plus en détail dans les spécifications Openflow.
Le canal ou la connexion Openflow est une configuration entre le commutateur et le contrôleur afin que le contrôleur puisse communiquer avec le commutateur pour le configurer, le gérer et le surveiller. Conformément aux spécifications d'Openflow, Openflow s'exécute sur une connexion TCP ou TLS et le contrôleur écoute la connexion sur le port 6653. Le commutateur est censé initier la connexion et doit envoyer la demande de connexion au contrôleur.
En option, la connexion peut également être initiée du côté du contrôleur, et dans ce cas, le commutateur sera en mode passif pour écouter la connexion. Que ce soit de n'importe quel côté, il s'agirait d'une configuration de connexion TCP ou TLS normale, une fois établie, les messages Openflow sont échangés via une connexion TCP ou TLS. Par exemple, vous trouverez ci-dessous la commande du commutateur virtuel open source Openflow (OpenVswitch) pour initier une connexion TCP avec le contrôleur :
ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653
Ici, 192.168.56.101 est l'IP du contrôleur et 6653 est le port du contrôleur sur lequel il écouterait la connexion.
Openflow définit divers messages pour permettre la communication entre le commutateur et le contrôleur, y compris les messages de configuration de la connexion, les messages de configuration, les messages d'obtention des statistiques du commutateur, les messages d'entretien, les messages d'événements asynchrones, les messages d'erreur, les messages de l'expérimentateur, etc.
Comprenons brièvement les messages Openflow :
- Une fois la connexion TCP établie, le message Openflow HELLO est échangé entre les deux entités pour négocier la version Openflow sur laquelle la communication ultérieure aura lieu. Il est nécessaire car il est possible que le commutateur et le contrôleur fonctionnent sur une version différente d'Openflow. Les deux s'accorderont sur la version la plus élevée prise en charge.
- Une fois la négociation de version terminée, le contrôleur envoie d'abord un message de demande de fonctionnalité Openflow pour principalement obtenir l'ID de chemin de données du commutateur dans le message de réponse et pour déterminer les fonctionnalités prises en charge par le commutateur.
- Pour configurer le commutateur pour gérer le trafic réseau, les messages Openflow comme les entrées de flux peuvent être envoyés à partir du contrôleur. Ceux-ci sont conservés dans des tables de flux à l'intérieur des commutateurs.
- Pour regrouper les entrées de flux, les groupes peuvent être configurés par le contrôleur via des messages de groupe qui peuvent être stockés dans des tables de groupe à l'intérieur des commutateurs.
- Pour obtenir des détails sur les statistiques du commutateur, les messages Openflow tels que les statistiques de flux, les statistiques de port, les statistiques de file d'attente, les statistiques de groupe, les statistiques de table, etc. peuvent être envoyés depuis le contrôleur.
- Pour vérifier l'activité de la connexion, les messages de requête et de réponse d'écho Openflow peuvent être envoyés depuis le contrôleur ou le commutateur.
- Les messages Openflow asynchrones tels que la suppression de la règle de flux du commutateur, l'erreur d'échec de l'application de la configuration du commutateur, l'état du port activé/désactivé du commutateur, etc. peuvent être envoyés du commutateur au contrôleur de mise à jour.
Jusqu'à présent, nous avons parcouru l'architecture SDN, ses couches et le rôle d'Openflow pour réaliser le principe de base du SDN afin de séparer le plan de contrôle du plan de données. Nous devons maintenant voir comment le contrôleur pourrait utiliser Openflow pour configurer et gérer le réseau sous-jacent.
Fondamentalement, le contrôleur devrait implémenter un code de plug-in d'Openflow par lequel il peut envoyer, recevoir et comprendre des messages Openflow vers et depuis des commutateurs Openflow dans le réseau sous-jacent.
Pour configurer les commutateurs Openflow , le contrôleur doit insérer des règles de flux dans les tables Openflow de commutateurs en fonction desquelles ces derniers peuvent gérer le trafic réseau qui les atteint. Le message Openflow pour les entrées de flux comporte un grand nombre de champs de tuple pour les critères de correspondance (champs L2, L3, L4, etc.) des paquets provenant du réseau, ce qui aiderait à configurer les règles ACL, les règles de politique de sécurité, les règles de bande passante limitant le débit QoS, règles de routage, règles de mise en miroir des ports et règles de modification des paquets.
Pour surveiller les commutateurs Openflow, Openflow fournit divers messages de demande et de réponse pour récupérer des informations sur les statistiques du commutateur et du réseau et des messages d'événements pour mettre à jour le contrôleur sur les modifications manuelles ou les échecs survenus côté commutateur, y compris l'événement de suppression de flux, les changements d'état du port UP/DOWN, et plus encore.
Pour effectuer certaines tâches spécifiques au fournisseur sur les commutateurs Openflow, Openflow fournit des messages expérimentaux dans lesquels les fournisseurs ont la liberté de définir le corps du message et d'échanger des informations personnalisées entre le contrôleur et les commutateurs. C'est ainsi qu'Openflow est utilisé par de nombreuses applications SDN pour fournir des solutions facilitant le contrôle et la gestion du réseau.
This article is co-authored by Tarun Thakur.
Références :
- https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
- https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
- http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/