On peut dire que depuis les années 2000 et l’avènement du MPLS, le WAN (Wide Area Network) n’a pas fortement évolué. Les innovations majeures dans le domaine se limitaient principalement à l’amélioration de fonctionnalités existantes ou à une baisse des coûts opérationnels facturés par les fournisseurs d’accès à leurs clients. Concrètement, le résultat de cette approche fut assez naturellement que les clients entreprise ont commencé à voir le WAN comme un simple produit de base sans valeur ajoutée.
Il y a eu un tournant voici deux ans après le lancement de notre architecture Cisco DNA et l’acquisition de la société Viptela par Cisco. Depuis lors, le WAN – et plus fortement le Software-Defined WAN (SD-WAN) – est plus que jamais au cœur des conversations avec nos clients.
Dans une série de blogs, je souhaite partager avec vous les dernières nouveautés sur le sujet. Dans cette première partie, nous allons vous expliquer comment le WAN est devenu « Software-Defined ».
Le WAN devient virtuel
Retournons d’abord au croisement des réseaux à grande distance avec la virtualisation. Suite à l’essor de l’elastic computing et son corollaire, l’avènement des serveurs à bas coût, l’idée d’un plan de contrôle centralisé, hébergé sur une architecture X86, capable de contrôler un réseau distribué a fait son chemin.
Cette approche a progressivement donné naissance à ce que l’on nomme aujourd’hui « SDN », qui en fait se décline en deux versions : software-defined et software-driven. L’approche « Defined » considère que toute l’intelligence est contenue dans un serveur central et qu’elle se suffit à elle-même pour apporter des fonctionnalités supplémentaires. Les équipements réseau n’ont donc pas besoin de composants particuliers puisque le contrôleur central les leur fourni sous forme de code. C’est traditionnellement dans ce contexte que l’on entend parler de « white box ».
L’approche « Driven » tiens plus d’un hybride de ce que certains peuvent qualifier de nouveau et d’ancien monde. En effet, si l’on prend l’exemple de Cisco, nos équipements réseau contiennent pour la plupart, des composants disposants d’avancées technologique majeures qui ont parfois nécessitées des années de cycles R&D comme par exemple les ASICs ou notre système d’exploitation IOS XE. Il serait irréaliste de ne pas utiliser ces composants tant les progrès techniques qu’ils représentent pour nos clients, sont importants.
De manière générale, le terme « Defined » qui est devenu l’expression par défaut, englobe les deux approches.
Appliquer SD au WAN
Comme souvent, l’impulsion d’origine était principalement d’ordre financier, puisque le concept du « Software Defined » était de pouvoir piloter des équipements réseau peu onéreux et relativement basiques (le plus souvent tournant sur une base Linux) en leur apportant des fonctions avancées depuis une “intelligence” centrale hébergée sur un serveur virtualisé pour de réducire les coûts C’est donc très logiquement que le SDN est venu s’intégrer au WAN.
En rationalisant la gestion du WAN, l’approche SDN accélère, concentre et simplifie la gestion d’environnements potentiellement très complexes et dispersés.
Le SD-WAN selon Cisco
L’architecture SD-WAN Cisco implique donc par essence une séparation du plan de contrôle (chemins pour aller du point A au point B) et du plan de commutation (sur quelle interface du router envoyer un paquet qui vient du point A et va au point B).
Le plan de contrôle (ou control plane) est donc « l’intelligence » centrale de l’architecture SD-WAN, il s’agit d’un système virtualisé tournant sur une architecture x86. Le plan de commutation (ou data plane) est constitué de l’ensemble des routeurs physiques ou virtuels gérés par l’intelligence centrale.
Maintenant que nous savons comment le software-driven WAN a vu le jour, examinons dans un post suivant l’architecture du SD-WAN Cisco.