Et si vous laissiez tomber les protocoles de routage ? Pourquoi n’iriez-vous pas déployer un orchestrateur qui configurerait des routes statiques sur tous les équipements de votre réseau et qui s’assurerait de la logique globale. En cas de changement de poids sur un lien, de changement de routage… cet orchestrateur fournirait un workflow pour aller reconfigurer à la volée les équipements concernés, reproduisant plus ou moins ce que vous auriez via un protocole de routage.
VOUS FERIEZ CELA SUR VOTRE RESEAU ? NON EVIDEMMENT !
ALORS POURQUOI LE FERIEZ-VOUS EN SD-WAN ?
Un des objectifs techniques du SD-WAN est de router intelligemment selon des policies, c’est-à-dire des règles qui vont déterminer comment vous désirez acheminer les paquets sur votre réseau, bien au-delà de ce que va faire un protocole de routage. Par exemple :
- Accès direct à Internet pour application A, B et C à travers une plateforme SASE – au hasard Cisco Umbrella 🙂
- Accès direct à internet pour application trustée X et Y (sans passage par SASE)
- Routage des applications voix/vidéo sur des tunnels internes qui garantiront la performance attendue
- Activer le FEC et le packet duplication pour les flux des applications critiques
- Forcer les transferts de fichier sur le lien Internet (peu importe sa performance)
- Faire transiter tous les flux internes du VPN “confidentiel” à travers une appliance de sécurité spécifique déployée en central
- Blacklister un subnet, une application…
- Marquer les flux voix en DSCP46
- Hub&spoke régional pour un VPN “confidentiel, full-mesh pour VPN corporate
- …
Ce qui est important en SD-WAN n’est donc pas tant le routage, que les policies que vous souhaitez appliquer. Il vous faut donc avoir un maximum de flexibilité à ce niveau. Pensez-vous que le plus efficace soit de reconfigurer TOUS vos équipements à chaque fois que vous souhaitez modifier une policy ?
Si vous voulez un réseau qui évolue à la vitesse du business il faut une autre approche.
C’est tout l’objet de la solution Cisco SD-WAN dans laquelle les policies sont, tout comme les routes, échangées par un protocole de contrôle appelé OMP (Overlay Management Protocol), qui repose sur des contrôleurs distribués appelés vSmart. Les policies ne sont donc pas dans les configurations des équipements, qui restent allégées, mais sont apprises dynamiquement via le control-plane OMP. C’est cette architecture unique qui nous permet aujourd’hui de garantir un scale et une efficacité sans équivalent sur la gestion des policies.
Architecture des policies centralisées
Les avantages sont évidents :
Efficacité
Un changement de policy ne requiert AUCUNE reconfiguration des WAN Edges (routeurs SD-WAN). Quand vous modifiez une policy dans la GUI du vManage, cette dernière est poussée comme de la configuration uniquement sur les contrôleurs vSmarts, puis est descendue en OMP (control-plane, protocole dérivé/inspiré de BGP) sur les WAN Edges. Que vous ayez 20, 200 ou 2000 routeurs, l’application et le changement de policies est immédiat puisque seuls les quelques vSmarts que vous aurez déployés devront être reconfigurés !
Au lieu de configurer 2000 routeurs (je vous laisse imaginer le temps que ça peut prendre avec un peu de latence, typique sur un WAN international), on ne configure dans tous les cas que quelques vSmarts (qui peuvent gérer chacun jusqu’à 5400 connexions de WAN Edges !)
Je rappelle que cette architecture permet évidemment de conserver une flexibilité maximale avec des comportement distincts par site, par VPN, etc. Le vSmart ne va redescendre sur chaque WAN Edge que les policies qui le concernent.
Une architecture faite pour l’AIops
Un changement de policy est donc quasi immédiat grâce à cette architecture Cisco SD-WAN, exactement comme un changement de routage ! C’est extrêmement pratique quand vous pouvez être amenés à faire plusieurs changements de policy par jour pour répondre à des observations du support et s’adapter en continu aux évolutions du réseau. On comprend l’importance d’une telle architecture à l’heure de l’AIops dans laquelle la promesse est de pouvoir faire évoluer les policies en continu par des algorithmes de machine learning qui anticipent les évolutions attendues.
Sécurité
Quand on veut remédier à une attaque, il vaut mieux être rapide de nos jours. L’isolation d’un site, d’un VPN, ou bloquer un préfixe IP etc. est immédiat sur l’ensemble du réseau. Ce modèle permet également très rapidement d’insérer des services en redirigeant toute ou partie du trafic vers des solutions de sécurité ad-hoc (cloud, on-prem). Il est possible de réagir à une attaque en quelques secondes, et cela sans aucune reconfiguration du réseau ! On se contente d’appliquer une nouvelle policy qui fera les opérations de sécurité nécessaires, et qui sera appliquées en quelques secondes sur l’infrastructure. Vous pouvez imaginer cela comme du RTBH (Remote Triggered Black Hole – RFC5635) filtering sous stéroïdes !
Simplicité des configurations et compliance
Les configurations des équipements sont simplifiées et ne tiennent compte que des aspects “physiques” comme les configurations des interfaces, les aspects “tuyauterie” de bas niveau qui changent peu. Le design pour un nouveau type de site est ainsi simplifié. Les configurations étant allégées, elles restent plus simplement modélisées dans un nombre réduit de “templates” qui changeront peu. Il sera donc plus facile de garantir leur compliance et s’assurer qu’il n’y a pas de déviations incontrôlées dans le temps !
Peut-être souhaitez-vous en apprendre un peu plus sur ces policies, ce qu’elles permettent de faire, et la manière de les construire. Aussi je vous recommande l’excellent breakout Cisco Live BRKRST-2791, et évidemment de revoir ce webinar que j’avais délivré avec Michaël Erimo l’année dernière sur la chaîne Youtube du blog.
Authors
