Dans ce blog, nous discuterons du SD-WAN pour essayer de comprendre son enjeu et avantage pour l’entreprise. Nous commençons par explorer l’offre du marché, définir la technologie et son principe de base, du besoin de son usage et scénarios, avant de discuter de son architecture, implémentation et troubleshooting de son opération.
Marché (offres du)
Incontestablement (jusqu’à nouvel ordre) Cisco se positionne en leader du marché avec leur produit le Catalyst 8k opérant avec le Cisco IOS XE SD-WAN Software système. Dans ce blog nous référons souvent la version: Cisco IOS XE Catalyst SD-WAN Release 17.2.1r and Later, disponible sous le lien constructeur: https://www.cisco.com/c/en/us/support/routers/sd-wan/products-user-guide-list.html.
Une des alternatives que je me propose d’étudier est le produit de Fortinet: Fortinet Secure SD-WAN. Je continue de chercher la perle rare: une offre de challenger…
Définition et principe de base
SD-WAN est un acronyme pour « Software-Defined Wide Area Network ». Il s’agit bel et bien d’un WAN et le fait qu’il soit Software-Defined envisage un certain niveau d’intégration de l’applicatif: dans le routage, dans la connexion aux plateformes, et même dans le modèle (de développement, intégration, exploitation, etc.). Le fait de cet effort d’intégration à l’applicatif suppose aussi, une certaine abstraction du réseau en faveur des déploiement applicatif: la complexité du réseau doit disparaitre en faveur d’une facilité de déploiement applicatif et de services…
Cela nous conduit au principe de base de son fonctionnement et opération: il s’agit d’un Overlay (SD-WAN fabrique, structure, plateforme ou écosystème) qui repose sur un Underlay pour connecter tous les composants de l’architecture applicative. En soit la technologie n’est pas nouvelle… s’agissant de VPN, tunnels, Virtualisation, Agrégation, etc. mais elle revient à la mode plus mature et répondant aux défis de sécurité, QoS, etc.
Besoin (et avantages)
La technologie permet aux entreprises de remplacer, partiellement ou totalement, les technologies en connectivité WAN privées plus chères, à l’instar de la technologie MPLS ou 4,5G/LTE : critère économique.
La simplicité et la rapidité du déploiement d’un SD-WAN sont d’autres facteurs extrêmement importants dans l’étude des solutions de cette technologie : suppose une infrastructure physique déjà surdimensionnée, etc.
De par la nature hétérogène des réseaux d’entreprise et des réseaux WAN, les solutions SD-WAN se doivent de pouvoir être mises en place avec une variété d’options pour la compatibilité entre hardware et software afin de permettre une transition vers le cloud sans problème.
Les différents liens de connectique étant également hétérogènes (Ethernet, LTE et autres), il est important que ceux-ci soient intégrés dans le déploiement de manière fluide et efficace.
Scénarios d’usage
C’est dans un contexte de transition vers le Cloud que le SD-WAN pourrait trouver complètement son intérêt. La sécurité que garantit les déploiement aujourd’hui et l’automatisation, permettraient une transition transparente vers de nouvelles plateformes (SASE, Secure Access Service Edge par exemple).
L’accès WAN des branches est aussi sécurisé par le déploiement d’environnements SaaS multi-cloud: si un accès est compromis l’accès WAN est automatiquement assuré (dans le même standard de sécurité) par une alternative.
Les applications de ce fait de disponibilité, redondance ou encore résilience de l’accès sont protégés mais aussi augmentées en performance: les accès aux ressources réseau, sécurité, systèmes, etc. tiennent compte de la spécificité de chaque application dans le temps: une gestion dynamique des ressources pour augmenter la performance des applications.
Architecture
Nous nous mettons dans le cas le plus basique pour commencer notre discussion, et le complexifions au et à mesure. Nous considérons le cas d’une entreprise qui a plusieurs réseaux, offices, branches, etc. à connecter: étendue géographiquement et qui un vrai besoin d’interconnexion WAN (au niveau d’un pays ou à l’international).
Topologie fonctionnelle
L’élément central de cette architecture est en quelque sorte un équipement CPE (Customer Premises Equipment) virtualisé ou physique positionné à chaque bout (ou edge) de notre réseau SD-WAN et la fonction principale est de “cacher” la complexité du WAN pour connecter toutes les branches, datacenter, sièges, campus, etc.; plus le réseau est étendu plus le nombre des boîtiers est important et le besoin de synchroniser ces boîtiers est nécessaire… un contrôleur trouve naturellement sa place pour cet effet! une analogie frappante peut-être faite avec une architecture Wifi unifiée (ou WLC-based) dans laquelle les bornes d’accès ou points d’accès s’attachent à un contrôleur pour leur configuration et opération.
La figure montre un exemple d’architecture Wifi centralisé et unifiée pour faire l’analogie avec un déploiement SD-WAN.
Nous ne perdrons pas de vue que le SD-WAN est avant tout une technologie de transport de paquets IP (v4 ou V6) qui la capacité de gérer les éléments suivants :
- utiliser un ensemble de liens (physiques ou logiques) hétérogènes
- disposer d’une classification de flux applicatifs (non seulement sur la base de l’information de routage, de transport, ou session, etc.)
- router les flux par application (et non seulement par adresses destination ou source, etc.)
- intégrer (nativement) l’interconnexion avec les environnements Cloud
- permet (par définition) un contrôle et un déploiement centralisé
- gérer intelligemment les flux appartenant à des zones de sécurité différents (internet, intranet, etc.)
Exemple d’une architecture logique
L’exemple de Cisco définit quatre rôles des composantes d’une architecture logique SD-WAN: un manager, contrôleur, validateur et équipement de périphérie (ou edge). Les équipements de périphérie se situent au plus proche des sites distants, à connecter; il s’agit d’un équipement physique ou virtualisé et par la même occasion embarque aussi le bout de “système” qui est le validateur. Le processus validateur sur tous les edges, gère la connexion des edge aux contrôleurs (gestion du NAT, DTLS, etc.). Le contrôleur gère tous les edges; c’est en quelque sorte “la tête pensante”, une intelligence centralisée qui associent par les tunnels DTLS tous les edges et gère leur opération. Le manager permet de visualiser tout ça du point de vue du contrôleur (et donne accès aux API pour les besoins de développement)…
Dans la suite nous présentons 3 déploiement possibles du SD-WAN: physique, could SD-WAN ou tout simplement cloud. Cela n’exclut pas qu’une solution puisse comprendre toutes ces variantes, on dirait alors que le déploiement est hybride
SD-WAN physique
Dans ce type d’architecture, l’entreprise dispose de l’infrastructure nécessaire à tourner le SD-WAN; elle a total contrôle. L’entreprise “achète” le produit chez l’éditeur (quelques éditeurs du marché: Ekinops, Sayse, Palo-Alto Cloud Genix, Vmware VeloCloud, Riverbed, Cisco Viptela, Fortinet, Versa-Networks, NacXwan, etc.) et c’est elle qui se charge de l’intégrer et l’opérer.
Cloud SD-WAN
Dans ce type c’est un externe qui fournit l’infrastructure SD-WAN et l’entreprise déploient ses applications et services là-dessus. quelques exemples de fournisseurs de ce type de SD-WAN: Google et Microsoft.
Clouds
Dans les Clouds nous n’avons pas besoin d’un WAN ni de déployer de nouvelles applications: nous intégrons l’offre en plateforme (de services ou d’applications disponibles à l’usage). les fournisseurs tels que : Amazon (AWS) et Microsoft (Azure), fournissent ces environnements Clouds.
Normalisation (standards)
Au jour d’aujourd’hui, il n’existe pas de standard qui rallie tous les acteurs du marché.
Ce qui semble présenter un problème de compatibilité s’estompe si nous considérons qu’à la base, la technologie a pour enjeu d’uniformiser la gestion du réseau lorsque l’Underlay est hétérogène (Cisco, Juniper, Extreme Networks, etc.) et la rendre facile grâce à l’Overlay. Devant la diversité des applications, le routage par application ou applicatifs est par design difficile à standardiser… en gros techniquement ça reviendrait à programmer uniquement avec un seul langage!
Routage
Le routage est divisé en deux routages: un pur routage en Overlay, et un routage de transport en underground oh! pardon Underlay. Le routage Overlay est copie collée du BGP sous le nom d’OMP qui opère dans les tunnels DTLS précédemment établis entre les edges et le (ou les) contrôleur; c’est du BGP en mode “route reflector”. Le routage de transport permet de partager l’information de routage du réseau réel (Underlay); nous retrouvons le routage classique ou “historique” du réseau…
Gestion et Sécurité
Le panel des services de sécurité est large et peut comprendre les éléments suivants : les services classiques de pares feux (Network, Proxy ou WAF), de la segmentation réseau, des VPN et ACL, et d’autres plus poussés : NFV (virtualisation des fonctionnalités réseaux), DLP (Data Loss Prevention), SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), etc.
Configuration & troubleshooting
Nous travaillons sur l’exemple de l’implémentation du Cisco. Le troubleshooting peut être envisagé dans deux plans : de contrôle et de données. Pour ce qui est de la configuration, elle met en œuvre particulièrement les éléments suivants : les modèles, les stratégies (ou Policies), un routage ou routing par les données ou applications, les VPN, etc.
La compréhension du step-by-step dans la mise en œuvre de tels réseau est aussi important pour repérer rapidement l’élément défaillant. Cela passe aussi par la maîtrise des différents outils de démonstration (show commandes), de debug, d’analyse de trafic, etc. à ces différent nœuds de fonctionnement. La bonne nouvelle c’est que la logique et les principes de base restent presque les mêmes que ceux déjà utilisés dans les réseaux d’entreprise classique (avec étendue géographique).
En conclusion
Ce poste a présenté un overview de la technologie SD-WAN. Il a montré le besoin (métier, financier, technique et commercial) qui motive l’augmentation de sa demande aujourd’hui. Le travail sur les aspects plus technologiques a permis de faire le rapprochement avec l’existant (en architecture réseau et services) et de constater une logique qui n’est pas nouvelle certes, mais de plus en plus mature en se référent à l’historique de conception de telles solutions.