La méthode traditionnelle utilisée pour manipuler les réseaux consiste à se connecter manuellement avec un compte et un mot de passe sur les équipements et entrer des commandes ou copier/coller des commandes préparées dans un éditeur de texte. Certains constructeurs possèdent des processus plus ou moins évolués pour revenir en arrière en cas de problème, mais la moindre petite erreur peut engendrer un dysfonctionnement sur l’ensemble du réseau.
Améliorer les méthodologies a pour objectifs d’améliorer la disponibilité et la sécurité des réseaux, mais aussi de mieux répondre aux méthodes inspirées de l’approche Agile maintenant utilisées dans le monde des réseaux. Depuis le provisionnement ZTP (Zero Touch Provisioning) ou ZTD (Zero Touch Deployment) jusqu’à l’intégration continue, en passant par la collecte de données, la migration, la gestion de configuration, le test de conformité, le tableaux de bord et le diagnostic, l’automatisation apporte des solutions à chacune des étapes.
Il n’est pas question de créer une confusion entre les différentes composantes d’un équipement réseau. Le « Data Plane » a pour mission de gérer la « Forwarding Table » au plus prêt du matériel et de faire passer les trames d’un port d’entrée vers un port de sortie. Le « Control Plane » utilise sa mémoire et sa CPU pour faire tourner un système d’exploitation dont la mission est de découvrir le réseau, de gérer des protocoles d’états de niveau 2 ou de niveau 3 tels que STP (Spanning Tree Protocol), SPB (Shortest Path Bridging), OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), …, de prendre en charge les trames dont le destinataire n’est pas connu et plus généralement de mettre à jour la « Forwarding Table » du « Data Plane ». Le « Management Plane » s’occupe de la partie orchestration en offrant des protocoles de communication, tels que Telnet (Terminal Network), SNMP (Simple Network Management Protocol), SSH (Secure SHell), HTTPS (HyperText Transfer Protocol Secure)…, aux administrateurs afin d’interagir avec l’équipement.
Open SDN (Software-Defined Networking) et plus particulièrement le protocole OpenFlow, dont on a tant entendu parler, consiste à séparer physiquement le « Control Plane » du « Data Plane », avec pour objectif d’offrir un « Control Plane » commun ayant une vue centralisée du réseau et d’apporter une synchronisation adaptée. Ce n’est pas de ce débat dont il est question ici.
Le « Management Plane » tend à évoluer pour passer des accès SNMP et SSH/Telnet/CLI, au protocole NETCONF (Network Configuration Protocol), puis aux API REST (Application Programming Interfaces REpresentational State Transfer). Le format de transfert des données entre l’équipement et l’administrateur se structure également pour passer du mode texte pur au XML (YANG utilisé par NETCONF) ou au JSON (JavaScript Object Notation). Cependant, lors du salon INTEROP 2016 à Las Vegas, il a été mis en évidence que seuls 15% à 20% des équipements supportaient des APIs ou le protocole NETCONF. De ce fait, le protocole SSH est encore indispensable.
Il va sans dire que rien ne vaut Unix, voire Linux, pour héberger tous les outils nécessaires à l’automatisation. Une bonne connaissance système est indispensable pour effectuer les configurations nécessaires à la mise en place des moyens intégrés dans l’infrastructure réseau. L’appel au « NetWork Namespace », au conteneur de type Docker, à la virtualisation de type KVM (Kernel Virtual Machine) et au switch virtuel OVS (Open vSwitch) peut s’avérer un plus pour la mise en place des moyens opérationnels.
Ne posez pas la question « quelle technologie va l’emporter ? ». Toutes les personnes d’expérience savent parfaitement, que, chaque fois qu’une technologie voit le jour, elle est présentée comme « l’arme fatale » avant de trouver sa vraie place souvent constituée d’une niche. C’est un des principes de l’innovation disruptive.
Pour terminer cette préface, je souhaiterai attirer l’attention sur le fait que, si les scripts sont extrêmement rapides pour configurer entièrement un réseau en exploitation, ils peuvent devenir aussi très dangereux. Si aucun réseau d’administration « Out of Band » n’a été prévu dans la conception de l’architecture, et que la gestion s’effectue par une méthode « In Band », toute exécution partielle et interrompue des scripts pourrait laisser les équipements dans un état injoignable et rendrait laborieux la remise en état de fonctionnement optimal.
