Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Depuis août 2017, lorsque la société Cisco a acquis Viptela, la technologie principale proposée pour la mise en place de réseaux d'entreprise distribués est devenue Cisco SD-WAN. Au cours des 3 dernières années, la technologie SD-WAN a subi de nombreux changements, tant qualitatifs que quantitatifs. Les capacités fonctionnelles se sont considérablement élargies et le soutien a été ajouté pour les routeurs classiques des séries Cisco ISR 1000, ISR 4000, ASR 1000 et le CSR 1000v virtuel. Dans le même temps, de nombreux clients et partenaires de Cisco continuent de se demander - quelles sont les différences entre Cisco SD-WAN et les approches déjà familières basées sur des technologies telles que Cisco DMVPN et Cisco Performance Routing et dans quelle mesure ces différences sont importantes ?

Il convient ici de préciser qu'avant l'apparition de SD-WAN dans le portefeuille Cisco, DMVPN, associé à PfR, constituait une partie clé de l'architecture Cisco IWAN (Intelligent WAN), qui était à son tour l'ancêtre de la pleine technologie SD-WAN. Malgré les similitudes générales tant sur les tâches à résoudre que sur les méthodes pour les résoudre, IWAN n'a jamais atteint le niveau d'automatisation, de flexibilité et d'évolutivité nécessaire à SD-WAN, et avec le temps, le développement d'IWAN a considérablement diminué. Cependant, les technologies qui composent IWAN n'ont pas disparu et de nombreux clients continuent de les utiliser avec succès, y compris sur un matériel moderne. En fin de compte, une situation intéressante s'est développée : le même équipement Cisco permet de choisir la technologie de construction WAN la plus appropriée (classique, DMVPN+PfR ou SD-WAN) en fonction des exigences et des attentes des clients.

Cet article ne vise pas à examiner en détail toutes les spécificités des technologies Cisco SD-WAN et DMVPN (ensemble ou sans Performance Routing) - il existe une immense quantité de documents et de matériaux disponibles à cet effet. L'objectif principal est d'essayer d'évaluer les principales différences entre ces technologies. Mais avant de passer à la discussion de ces différences, rappelons brièvement les technologies elles-mêmes.

Qu'est-ce que Cisco DMVPN et à quoi ça sert ?

Cisco DMVPN permet de résoudre le problème de la connexion dynamique (c'est-à-dire évolutive) d'un réseau de succursale distante au réseau du bureau central de l'entreprise en utilisant tout type de canaux de communication, y compris Internet (avec cryptage du canal de communication). Techniquement, cela se réalise par la création d'un réseau superposé virtualisé de classe L3. VPN en mode point à multipoint avec une topologie logique de type « Étoile » (Hub-n-Spoke). Pour cela, DMVPN utilise une combinaison des technologies suivantes :

  • Routage IP
  • Tunnels GRE multipoints (mGRE)
  • Protocole de résolution du prochain saut (NHRP)
  • Profils cryptographiques IPSec

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Quels sont les principaux avantages de Cisco DMVPN par rapport au routage classique utilisant des canaux VPN MPLS ?

  • Pour créer un réseau intersites, il est possible d'utiliser n'importe quel canal de communication – tout ce qui peut fournir une connectivité IP entre les succursales convient, tout en assurant que le trafic soit chiffré (là où nécessaire) et équilibré (là où possible).
  • Une topologie pleinement connectée est automatiquement formée entre les succursales. Il existe des tunnels statiques entre le site central et les succursales éloignées, tandis que les tunnels entre les succursales éloignées sont dynamiques à la demande (lorsqu'il y a du trafic).
  • Sur les routeurs du site central et de la succursale éloignée, une configuration uniforme est utilisée à l'exception des adresses IP interfaces. Grâce à l'utilisation de mGRE, il n'est pas nécessaire de configurer individuellement des dizaines, des centaines ou même des milliers de tunnels. En conséquence, une évolutivité satisfaisante avec un bon design.

Qu'est-ce que le Cisco Performance Routing et à quoi sert-il ?

Lors de l'utilisation de DMVPN sur le réseau intersites, une question fondamentale reste sans réponse – comment évaluer dynamiquement l'état de chacun des tunnels DMVPN par rapport aux exigences du trafic critique pour notre organisation et, encore une fois, sur la base de cette évaluation, prendre des décisions dynamiques concernant le reroutage ? En effet, DMVPN, à cet égard, ne diffère guère du routage classique – le meilleur que l'on puisse faire est de configurer des mécanismes QoS, qui permettront de prioriser le trafic en direction sortante, mais ne peuvent en aucun cas tenir compte de l'état de l'ensemble du chemin à un moment donné.

Que faire si le canal se dégrade partiellement et non complètement – comment l'identifier et l'évaluer ? DMVPN à lui seul n'y parvient pas. Étant donné que les canaux reliant les succursales peuvent passer par différents opérateurs de télécommunications en utilisant des technologies complètement différentes, cette tâche devient fort complexe. C'est ici que la technologie Cisco Performance Routing entre en jeu, ayant déjà traversé plusieurs phases de développement à ce moment-là.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

La tâche de Cisco Performance Routing (ci-après PfR) consiste à mesurer l'état des chemins (tunnels) par lesquels passe le trafic sur la base de métriques clés, essentielles pour les applications réseau – latence, variation de la latence (jitter) et perte de paquets (en pourcentage). En outre, la bande passante utilisée peut également être mesurée. Ces mesures se font aussi proches que possible du temps réel (dans la mesure du possible et justifié) et le résultat de ces mesures permet au routeur utilisant PfR de prendre des décisions dynamiques sur la nécessité de modifier la routage d'un certain type de trafic.

Ainsi, la tâche de combiner DMVPN/PfR peut être brièvement caractérisée comme suit :

  • Permettre au client d'utiliser n'importe quel canal de communication sur le réseau WAN
  • Assurer la meilleure qualité possible pour les applications critiques sur ces canaux

Qu'est-ce que Cisco SD-WAN ?

Cisco SD-WAN est une technologie qui utilise l'approche SDN pour créer et exploiter le réseau WAN d'une organisation. Cela signifie notamment l'utilisation de ce que l'on appelle des contrôleurs (éléments logiciels), qui fournissent une orchestration centralisée et une configuration automatisée de tous les composants de la solution. Contrairement à SDN classique (de type Clean Slate), Cisco SD-WAN utilise plusieurs types de contrôleurs, chacun ayant un rôle spécifique – cela est fait intentionnellement afin d'assurer une meilleure évolutivité et une redondance géographique.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Dans le cas de SD-WAN, la nécessité d'utiliser tout type de canal et d'assurer le fonctionnement des applications commerciales demeure, mais les exigences en matière d'automatisation, d'évolutivité, de sécurité et de flexibilité de ce réseau sont également élargies.

Discussion des différences

Si l'on commence maintenant à analyser les différences entre ces technologies, elles seront classées dans l'une des catégories :

  • Différences architecturales – comment les fonctions sont réparties entre les différents composants de la solution, comment l'interaction entre ces composants est organisée et comment cela influence les capacités et la flexibilité de la technologie ?
  • Fonctionnalités – qu'est-ce qu'une technologie peut faire que l'autre ne peut pas ? Et est-ce si important ?

Quelles sont les différences architecturales et sont-elles vraiment importantes ?

Chacune des technologies mentionnées comprend de nombreuses « pièces mobiles », dont le rôle et les principes d'interaction diffèrent. La manière dont ces principes sont conçus détermine directement la scalabilité, la résilience et l'efficacité globale de la solution.

Examinons plus en détail les différents aspects de l'architecture :

Data-plane – la partie de la solution responsable de la transmission du trafic utilisateur entre la source et le destinataire. Dans DMVPN et SD-WAN, cela est généralement réalisé de la même manière sur les routeurs à base de tunnels GRE Multipoint. La différence réside dans ce qui constitue le jeu de paramètres nécessaire pour ces tunnels :

  • dans DMVPN/PfR – il s'agit d'une hiérarchie de nœuds strictement à deux niveaux avec une topologie de type « étoile » ou Hub-n-Spoke. La configuration statique du Hub et le lien statique du Spoke au Hub sont obligatoires, ainsi que l'interaction via le protocole NHRP pour établir la connectivité du data-plane. Par conséquent, les modifications sur le Hub sont considérablement compliquées, notamment en ce qui concerne les changements ou l'ajout de nouveaux canaux WAN ou la modification des paramètres existants.
  • dans SD-WAN – c'est un modèle de détection de paramètres des tunnels établi de manière entièrement dynamique, reposant sur le control-plane (protocole OMP) et l'orchestration-plane (interaction avec le contrôleur vBond pour des tâches telles que la découverte de contrôleurs et le traversée NAT). Dans ce cadre, toutes les topologies peuvent être appliquées, y compris hiérarchiques. Au sein de la topologie des tunnels établie, une configuration flexible de la topologie logique est possible dans chaque VPN (VRF).

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Control-plane – fonctions d'échange, de filtrage et de modification des informations de routage et d'autres informations entre les composants de la solution.

  • dans DMVPN/PfR – se fait uniquement entre les routeurs Hub et Spoke. L'échange direct d'informations de routage entre Spoke n'est pas possible. Par conséquent, sans un Hub opérationnel, le fonctionnement du control-plane et du data-plane est impossible., ce qui impose à Hub des exigences supplémentaires en matière de haute disponibilité, qui ne peuvent pas toujours être respectées.
  • dans SD-WAN – la gestion du plan de contrôle ne s'effectue jamais directement entre les routeurs – l'interaction se fait sur la base du protocole OMP et s'opère obligatoirement via un type de contrôleur vSmart spécialisé, ce qui permet l'équilibrage, la géo-redondance et la gestion centralisée de la charge de signalisation. Une autre caractéristique du protocole OMP est sa grande résilience aux pertes et son indépendance vis-à-vis de la vitesse du canal de communication avec les contrôleurs (dans des limites raisonnables, bien sûr). Cela permet également de déployer les contrôleurs SD-WAN dans des nuages publics ou privés avec un accès via Internet.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Plan de politique – partie de la solution responsable de la définition, de la diffusion et de l'application des politiques de gestion du trafic dans un réseau distribué.

  • DMVPN – est en réalité limité par des politiques de qualité de service (QoS), personnalisées individuellement sur chaque routeur via CLI ou modèles Prime Infrastructure.
  • DMVPN/PfR – les politiques PfR sont élaborées sur le routeur central Master Controller (MC) via CLI et sont ensuite automatiquement diffusées vers les MC de filiale. Les mêmes chemins de transmission que pour le plan de données sont utilisés pour diffuser les politiques. Il n'est pas possible de dissocier l'échange de politiques, d'informations de routage et de données utilisateur. La diffusion des politiques nécessite une connectivité IP entre Hub et Spoke. De plus, la fonction de MC peut, si nécessaire, être combinée avec un routeur DMVPN. L'utilisation de modèles Prime Infrastructure pour la création centralisée des politiques est possible (mais pas obligatoire). Une caractéristique importante est que la politique est élaborée de manière globale sur tout le réseau de manière uniforme – les politiques individuelles pour des segments spécifiques ne sont pas prises en charge..
  • SD-WAN Les politiques de gestion du trafic et de qualité de service sont définies de manière centralisée via l'interface graphique Cisco vManage, accessible notamment via Internet (si nécessaire). Elles sont réparties sur des canaux de signalisation directement ou indirectement via des contrôleurs vSmart (selon le type de politique). Elles ne dépendent pas de la connectivité du data-plane entre les routeurs, car elles utilisent tous les chemins de transmission de trafic disponibles entre le contrôleur et le routeur.

    Pour différents segments de réseau, il est possible de créer de manière flexible diverses politiques – le domaine d'application de la politique est défini par de nombreux identifiants uniques prévus dans la solution – numéro de succursale, type d'application, direction du trafic, etc.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Plane d'orchestration – des mécanismes permettant aux composants de se découvrir dynamiquement, de se configurer et de coordonner leur interaction ultérieure.

  • dans DMVPN/PfR La découverte mutuelle entre les routeurs est basée sur la configuration statique des appareils Hub et le paramétrage correspondant des appareils Spoke. La découverte dynamique se produit uniquement pour le Spoke, qui informe le dispositif Hub de ses paramètres de connexion, qui a été préalablement inscrit dans la configuration du Spoke. Sans connectivité IP entre le Spoke et au moins un Hub, il est impossible de former ni le data-plane ni le control-plane.
  • dans SD-WAN L'orchestration des composants de la solution se fait en utilisant le contrôleur vBond, avec lequel chaque composant (routeurs et contrôleurs vManage/vSmart) doit préalablement établir une connectivité IP.

    À l'origine, les composants ne connaissent pas les paramètres de connexion les uns des autres – pour cela, un intermédiaire d'orchestration vBond est nécessaire. Le principe général est le suivant : chaque composant apprend (automatiquement ou statiquement) uniquement les paramètres de connexion au vBond dans la phase initiale, puis le vBond informe le routeur des contrôleurs vManage et vSmart (précédemment découverts), ce qui permet d'établir automatiquement toutes les liaisons de signalisation nécessaires.

    À l'étape suivante, le nouveau routeur découvrira les autres routeurs du réseau par le biais d'un échange OMP avec le contrôleur vSmart. Ainsi, le routeur, ne connaissant initialement aucune des paramètres du réseau, sera capable de détecter et de se connecter complètement et automatiquement aux contrôleurs, et ensuite de découvrir et de créer une connectivité avec les autres routeurs de manière automatique. À cela, les paramètres de connexion de tous les composants sont initialement inconnus et peuvent changer au cours de l'exploitation.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Plan de gestion – partie de la solution qui assure la gestion et la surveillance centralisées.

  • DMVPN/PfR – aucune solution dédiée au plan de gestion n'est prévue. Pour l'automatisation de base et la surveillance, il est possible d'utiliser des produits tels que Cisco Prime Infrastructure. Chaque routeur peut être géré par la ligne de commande CLI. Les intégrations avec des systèmes externes via API ne sont pas prévues.
  • SD-WAN – toutes les interactions et la surveillance se font de manière centralisée via l'interface graphique du contrôleur vManage. Toutes les fonctionnalités de la solution, sans exception, sont accessibles à la configuration via vManage, ainsi que par le biais d'une bibliothèque d'API REST entièrement documentée.

    Tous les paramètres du réseau SD-WAN dans vManage se résument à deux concepts principaux – la création de modèles de périphériques (Device Template) et la création de politiques qui définissent la logique de fonctionnement du réseau et le traitement du trafic. Dans ce cadre, vManage, en traduisant la politique élaborée par l'administrateur, sélectionne automatiquement quels changements doivent être effectués et sur quels dispositifs individuels ou contrôleurs, ce qui renforce considérablement l'efficacité et l'évolutivité de la solution.

    Via l'interface vManage, non seulement la configuration de la solution Cisco SD-WAN est accessible, mais également la surveillance complète de l'état de tous les composants de la solution, allant jusqu'à l'état actuel des métriques des tunnels individuels et des statistiques d'utilisation des différentes applications sur la base de l'analyse DPI.

    Bien que l'interaction soit centralisée, tous les composants (contrôleurs et routeurs) disposent également d'une interface en ligne de commande (CLI) entièrement fonctionnelle, qui est nécessaire lors de la mise en œuvre ou en cas de situation d'urgence pour le diagnostic local. En mode normal (lorsqu'il existe un canal de signalisation entre les composants), l'interface en ligne de commande est accessible uniquement pour le diagnostic et n'est pas disponible pour apportez des modifications locales, ce qui garantit à la fois la sécurité locale et la source unique de modifications dans un tel réseau : vManage.

Sécurité intégrée – ici, il ne s'agit pas seulement de protéger les données des utilisateurs lors de leur transmission sur des canaux ouverts, mais aussi de la sécurité globale du réseau WAN basé sur la technologie choisie.

  • dans DMVPN/PfR la possibilité de chiffrer les données utilisateurs et les protocoles de signalisation est prévue. En utilisant certains modèles de routeurs, des fonctions de pare-feu avec inspection du trafic, IPS/IDS sont également disponibles. Il est possible de segmenter les réseaux de succursales en utilisant VRF. Il existe également une possibilité d'authentification (à un facteur) des protocoles de contrôle.

    Le routeur distant est par défaut considéré comme un élément de confiance dans le réseau – c'est-à-dire que les cas de compromission physique d'appareils individuels et la possibilité d'un accès non autorisé ne sont pas envisagés ou pris en compte, il n'y a pas d'authentification à deux facteurs pour les composants de la solution, ce qui, dans un réseau géographiquement distribué, peut représenter des risques supplémentaires sérieux.

  • dans SD-WAN comme avec DMVPN, il est prévu la possibilité de chiffrer les données utilisateur, mais avec des fonctionnalités de sécurité réseau et de segmentation L3/VRF beaucoup plus étendues (MSS, IPS/IDS, filtrage URL, filtrage DNS, AMP/TG, SASE, proxy TLS/SSL, etc.). Dans ce cas, l'échange de clés de chiffrement est réalisé plus efficacement via les contrôleurs vSmart (et non directement), par des canaux de signalisation préétablis, protégés par un chiffrement DTLS/TLS basé sur des certificats de sécurité. Cela garantit la sécurité de cet échange et assure une meilleure évolutivité de la solution, jusqu'à des dizaines de milliers d'appareils dans un seul réseau.

    Toutes les connexions de signalisation (contrôleur à contrôleur, contrôleur à routeur) sont également sécurisées sur la base de DTLS/TLS. Les routeurs sont équipés de certificats de sécurité lors de leur fabrication, avec la possibilité de remplacement/renouvellement. L'authentification à deux facteurs est réalisée par l'exécution obligatoire et simultanée de deux conditions pour le fonctionnement du routeur/contrôleur dans le réseau SD-WAN :

    • Certificat de sécurité valide
    • Ajout explicite et conscient par l'administrateur de chaque composant à la liste blanche des dispositifs autorisés.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Différences fonctionnelles entre SD-WAN et DMVPN/PfR

En abordant la discussion sur les différences fonctionnelles, il convient de noter que beaucoup d'entre elles sont une continuité des différences architecturales — il n'est pas secret que lors de la conception de l'architecture de la solution, les développeurs s'appuient sur les possibilités qu'ils souhaitent obtenir à la fin. Passons en revue les différences les plus significatives entre les deux technologies.

AppQ (Quality d'Application) – fonctions garantissant la qualité de transmission du trafic des applications professionnelles

Les fonctionnalités clés des technologies examinées visent à améliorer autant que possible l'expérience utilisateur lors de l'utilisation d'applications critiques pour les entreprises dans un réseau distribué. C'est particulièrement important dans des conditions où une partie de l'infrastructure n'est pas contrôlée par l'IT ou ne garantit même pas une transmission réussie des données.

DMVPN ne fournit pas de tels mécanismes de manière autonome. La meilleure chose à faire dans un réseau DMVPN classique est de classer le trafic sortant par applications et de le prioriser lors de sa transmission vers le canal WAN. Le choix du tunnel DMVPN est alors uniquement déterminé par sa disponibilité et le résultat des protocoles de routage. Dans ce cas, l'état de bout en bout du chemin/tunnel et sa possible dégradation partielle en termes de métriques clés, significatives pour les applications réseau – latence, variation de latence (jitter) et pertes (%) – ne sont pas pris en compte. En conséquence, comparer directement le DMVPN classique au SD-WAN en matière de résolution des tâches d'AppQ n'a pas de sens – DMVPN ne peut pas résoudre ce problème. L'ajout dans ce contexte de la technologie Cisco Performance Routing (PfR) modifie la situation et rend la comparaison avec Cisco SD-WAN plus pertinente.

Avant de discuter des différences, parlons brièvement des similitudes entre les technologies. Ainsi, les deux technologies :

  • disposent d'un mécanisme permettant d'évaluer dynamiquement l'état de chaque tunnel établi à travers des métriques spécifiques - au minimum, la latence, la variation de latence et la perte de paquets (%)
  • utilisent un ensemble d'outils pour former, distribuer et appliquer des règles (politiques) de gestion du trafic en tenant compte des résultats de la mesure de l'état des principales métriques des tunnels.
  • classifient le trafic des applications aux niveaux L3-L4 (DSCP) du modèle OSI ou par les signatures L7 des applications grâce aux mécanismes DPI intégrés dans le routeur.
  • permettent de définir pour les applications significatives des valeurs seuil acceptables pour les métriques, des règles de transmission de trafic par défaut, ainsi que des règles de reroutage du trafic en cas de dépassement de ces seuils.
  • lors de l'encapsulation du trafic en GRE/IPSec, utilisent un mécanisme bien établi dans l'industrie pour transférer le marquage DSCP interne vers l'en-tête externe du paquet GRE/IPSec, ce qui permet de synchroniser les politiques QoS de l'organisation et de l'opérateur de télécommunications (sous réserve d'un SLA approprié).

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

Comment les mécanismes d'évaluation des métriques de bout en bout SD-WAN et DMVPN/PfR diffèrent-ils ?

DMVPN/PfR

  • Pour évaluer les métriques standards de l'état du tunnel, des capteurs logiciels (Probes) actifs et passifs sont utilisés. Les actifs se basent sur le trafic utilisateur, tandis que les passifs émulant ce trafic (en son absence).
  • L'ajustement fin des temporisateurs et des conditions de détection de dégradation n'est pas disponible - l'algorithme est fixe.
  • Une mesure de la bande passante utilisée dans le sens sortant est également disponible. Ce qui ajoute à DMVPN/PfR une flexibilité supplémentaire dans la gestion du trafic.
  • Dans ce cadre, certains mécanismes PfR en cas de dépassement des métriques s'appuient sur un retour d'information sous forme de messages TCA (Threshold Crossing Alert) spéciaux, qui doivent provenir du récepteur de trafic vers la source, ce qui suppose que l'état des canaux mesurés doit être au minimum suffisant pour transmettre ces messages TCA, ce qui dans la plupart des cas n'est pas un problème, mais ne peut évidemment pas être garanti.

SD-WAN

  • Pour l'évaluation continue des métriques standard de l'état du tunnel, le protocole BFD en mode echo est utilisé. Aucune rétroaction spéciale sous forme de TCA ou de messages similaires n'est requise – l'isolement des domaines de défaillance est respecté. Il n'est également pas nécessaire qu'un trafic utilisateur soit présent pour évaluer l'état du tunnel.
  • Il est possible d'ajuster finement les minuteries BFD pour réguler la vitesse de déclenchement et la sensibilité de l'algorithme aux dégradations du canal de communication, allant de quelques secondes à quelques minutes.

    Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

  • Au moment de la rédaction de cet article, chaque tunnel ne prévoit qu'une seule session BFD. Cela peut potentiellement limiter la granularité lors de l'analyse de l'état du tunnel. En réalité, cela peut devenir une contrainte uniquement dans le cas d'une connexion WAN basée sur MPLS L2/L3 VPN avec un SLA QoS convenu – si le marquage DSCP du trafic BFD (après encapsulation en IPSec/GRE) coïncide avec la file d'attente à haute priorité dans le réseau de l'opérateur, cela pourrait affecter la précision et la rapidité de détection de la dégradation pour le trafic de faible priorité. Toutefois, il est possible de modifier le marquage BFD par défaut pour réduire le risque de telles situations. Les prochaines versions du logiciel Cisco SD-WAN devraient inclure des réglages BFD plus fins, ainsi que la possibilité de lancer plusieurs sessions BFD dans un même tunnel avec des valeurs DSCP individuelles (pour différentes applications).
  • Le BFD permet également d'évaluer la taille maximale des paquets pouvant être transmis par un tunnel sans fragmentation. Cela permet à SD-WAN d'ajuster dynamiquement des paramètres tels que MTU et TCP MSS Adjust, afin d'utiliser au mieux la bande passante disponible sur chaque canal.
  • Dans SD-WAN, il existe également une option de synchronisation QoS avec les opérateurs de télécommunications basée non seulement sur le champ L3 DSCP, mais aussi sur les valeurs L2 CoS qui peuvent être automatiquement générées dans le réseau filial par des dispositifs spécialisés, tels que les téléphones IP.

Quelles sont les différences dans les capacités, les méthodes de détermination et d'application des politiques AppQ ?

Politiques DMVPN/PfR :

  • Elles sont définies sur le(s) routeur(s) du site central (SC) via l'interface de ligne de commande CLI ou des modèles de configuration CLI. La création de modèles CLI nécessite une préparation et une connaissance de la syntaxe des politiques.

    Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

  • Définis globalement sans possibilité de personnalisation ou de modification selon les besoins des segments de réseau individuels.
  • La création interactive de politiques via une interface graphique n'est pas prévue.
  • Le suivi des modifications, l'héritage et la création de plusieurs versions de politiques pour un changement rapide ne sont pas prévus.
  • Elles sont automatiquement diffusées sur les routeurs des agences distantes. Pour cela, les mêmes canaux de communication que ceux utilisés pour la transmission des données des utilisateurs sont employés. En l'absence de canal de communication entre le site central et l'agence distante, il est impossible de diffuser ou de modifier les politiques.
  • S'appliquent sur chaque routeur et, si nécessaire, modifient le résultat des protocoles de routage standard, ayant une priorité plus élevée.
  • Dans les cas où tous les canaux WAN de l'agence subissent des pertes de trafic significatives, aucun mécanisme de compensation n'est prévu.

Politiques SD-WAN :

  • Définies dans l'interface graphique vManage via un assistant de modèles interactif.
  • Permettent la création de plusieurs politiques, la copie, l'héritage et le basculement entre les politiques en temps réel.
  • Supportent la personnalisation des politiques pour différents segments (agences) du réseau
  • Se propagent en utilisant n'importe quel canal de signalisation disponible entre le contrôleur et le routeur et/ou vSmart – ne dépendent pas directement de la connectivité du plan de données entre les routeurs. Il est cependant nécessaire d'avoir une connectivité IP entre le routeur lui-même et les contrôleurs.

    Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

  • Dans les cas où tous les canaux disponibles de l'agence subissent des pertes de données significatives dépassant les seuils acceptables pour les applications critiques, il est possible d'utiliser des mécanismes supplémentaires pour améliorer la fiabilité de la transmission :
    • FEC (Correction d'Erreur Avancée) – utilise un algorithme spécial de codage redondant. Lors de la transmission de trafic critique sur des canaux avec un pourcentage de pertes significatif, FEC peut être activé automatiquement et permet de récupérer les parties de données perdues si nécessaire. Cela augmente légèrement la bande passante utilisée, mais améliore considérablement la fiabilité.

      Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

    • Duplication des flux de données En plus de la politique FEC, il peut être prévu un doublage automatique du trafic des applications sélectionnées en cas de pertes encore plus graves qui ne peuvent être compensées par FEC. Dans ce cas, les données choisies seront transmises sur tous les tunnels vers la filiale destinataire avec une désintégration subséquente (élimination des copies de paquets inutiles). Ce mécanisme augmente considérablement l'utilisation des canaux, mais améliore également de manière significative la fiabilité de la transmission.

Les capacités de Cisco SD-WAN, sans équivalence directe dans DMVPN/PfR

L'architecture de la solution Cisco SD-WAN permet dans certains cas d'obtenir des capacités dont la mise en œuvre dans le cadre de DMVPN/PfR est soit extrêmement difficile, soit inappropriée en raison des efforts nécessaires, soit tout simplement impossible. Examinons les plus intéressantes d'entre elles :

Ingénierie du trafic (TE)

TE comprend des mécanismes qui permettent de dévier le trafic du chemin standard formé par les protocoles de routage. TE est souvent utilisé pour assurer une haute disponibilité des services réseau, grâce à sa capacité à transférer rapidement et/ou à l'avance un trafic important sur un chemin alternatif (non-intersectant), afin d'assurer une meilleure qualité de service ou une rapidité de récupération en cas de défaillance sur le chemin principal.

La complexité de la mise en œuvre de TE réside dans la nécessité de calculer et de réserver à l'avance (vérifier) un itinéraire alternatif. Dans les réseaux MPLS des opérateurs de télécommunications, cette tâche est réalisée en utilisant des technologies telles que MPLS Traffic Engineering avec des extensions de protocoles IGP et du protocole RSVP. De plus, la technologie de Segment Routing gagne en popularité ces derniers temps, étant plus optimisée pour la configuration et l'orchestration centralisées. Dans les WAN classiques, ces technologies ne sont généralement pas présentes ou sont réduites à l'utilisation de mécanismes hop-by-hop comme le Policy-Based Routing (PBR), qui peuvent détourner le trafic, mais le font sur chaque routeur séparément – sans tenir compte de l'état global du réseau ou des résultats du PBR aux étapes précédentes ou suivantes. Le résultat de l'application de ces options de TE est peu prometteur – MPLS TE, en raison de la complexité de sa configuration et de son exploitation, est généralement utilisé uniquement dans la partie la plus critique du réseau (noyau), tandis que le PBR est utilisé sur des routeurs individuels sans possibilité de former une politique PBR unique sur l'ensemble du réseau. Cela s'applique également aux réseaux basés sur DMVPN.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

SD-WAN offre à cet égard une solution beaucoup plus élégante, qui est non seulement facile à configurer, mais qui évolue également de manière significative. Cela résulte des architectures utilisées pour le control-plane et le policy-plane. La mise en œuvre du policy-plane dans SD-WAN permet de définir de manière centralisée la politique de TE – quel trafic est concerné ? pour quels VPN ? à travers quels nœuds/tunnels est-il nécessaire ou interdit de former un itinéraire alternatif ? En retour, la centralisation de la gestion du control-plane basée sur des contrôleurs vSmart permet de modifier les résultats de routage sans recourir aux configurations des appareils individuels – les routeurs ne voient déjà que le résultat de la logique qui a été formée dans l'interface vManage et transmise pour application sur vSmart.

Service-chaining

La formation de chaînes de services est une tâche encore plus laborieuse dans le routage classique que le mécanisme d'ingénierie de trafic déjà décrit. Dans ce cas, il est nécessaire non seulement de créer un itinéraire spécifique pour une application réseau particulière, mais aussi de garantir la possibilité de faire sortir le trafic du réseau sur certains (ou tous) nœuds de la réseau SD-WAN afin qu'il soit traité par une application ou un service spécial (MSP, Équilibrage, Mise en cache, Inspection du trafic, etc.). Il est également nécessaire de pouvoir contrôler l'état de ces services externes, afin d'éviter des situations de black-holing, ainsi que d'avoir des mécanismes permettant de déployer ces services externes similaires dans différentes géo-localisations, avec la possibilité pour le réseau de choisir automatiquement le nœud de service le plus optimal pour traiter le trafic d'une certaine filiale. Dans le cas de Cisco SD-WAN, cela peut être facilement réalisé en créant une politique centralisée correspondante qui « colle » tous les aspects de la chaîne de services cible en une seule entité et modifie automatiquement la logique du data-plane et du control-plane uniquement là où cela est nécessaire.

Cisco SD-WAN va-t-il couper la branche sur laquelle DMVPN est assis ?

La capacité de former un traitement géo-distribué du trafic des types d'applications sélectionnés dans un ordre spécifique sur un matériel spécialisé (mais sans lien avec le réseau SD-WAN lui-même) est sans doute la démonstration la plus convaincante des avantages de Cisco SD-WAN par rapport aux technologies classiques et même à certaines solutions alternatives SD-WAN d'autres fabricants.

Quel est le résultat ?

Il est évident que DMVPN (avec ou sans Performance Routing) et Cisco SD-WAN résolvent finalement des tâches très similaires en ce qui concerne le réseau WAN distribué de l'organisation. Les différences architecturales et fonctionnelles significatives de la technologie Cisco SD-WAN élèvent le processus de résolution de ces tâches à un autre niveau qualitatif. En résumé, on peut noter les différences significatives entre les technologies SD-WAN et DMVPN/PfR :

  • DMVPN/PfR utilise des technologies éprouvées pour la construction de réseaux VPN superposés et, dans le domaine du data-plane, ressemble davantage à la technologie SD-WAN plus moderne, bien qu'il existe certaines limitations en raison de la nécessité d'une configuration statique des routeurs et d'un choix de topologies limité à Hub-n-Spoke. D'autre part, DMVPN/PfR possède certaines fonctionnalités qui ne sont pas encore disponibles dans le cadre de la SD-WAN (notamment le BFD par application).
  • En ce qui concerne la technologie du control-plane, elles diffèrent fondamentalement. Compte tenu du traitement centralisé des protocoles de signalisation, la SD-WAN permet, entre autres, de réduire considérablement les domaines de pannes et 'détache' le processus de transmission du trafic utilisateur de l'interaction de signalisation : l'indisponibilité temporaire des contrôleurs n'affecte pas la possibilité de transmettre le trafic utilisateur. En même temps, l'indisponibilité temporaire de n'importe quelle succursale (y compris celle centrale) n'affecte en rien la capacité des autres succursales à interagir entre elles et avec les contrôleurs.
  • L'architecture de définition et d'application des politiques de gestion du trafic dans le cas de la SD-WAN surpasse également celle de DMVPN/PfR : la géo-redondance est beaucoup mieux mise en œuvre, il n'y a pas de dépendance au Hub, et il y a plus d'options pour le réglage fin des politiques. De plus, la liste des scénarios de gestion du trafic mis en œuvre est également considérablement plus grande.
  • Le processus d'orchestration de la solution diffère également considérablement. DMVPN nécessite des paramètres préalablement connus, qui doivent être d'une manière ou d'une autre reflétés dans la configuration, ce qui limite quelque peu la flexibilité de la solution et la possibilité de changements dynamiques. En revanche, la SD-WAN repose sur la paradigme selon laquelle, au moment initial de la connexion, le routeur 'ne sait rien' de ses contrôleurs, mais sait 'qui peut être consulté' - cela suffit non seulement pour établir automatiquement la liaison avec les contrôleurs, mais aussi pour former automatiquement une topologie de data-plane entièrement connectée, qui peut ensuite être ajustée/modifiée de manière flexible à l'aide de politiques.
  • Dans le domaine de la gestion centralisée, de l'automatisation et de la surveillance, le SD-WAN surpassait sans surprise les capacités du DMVPN/PfR, qui résultent de l'évolution des technologies classiques et reposent en grande partie sur la ligne de commande CLI et l'application de systèmes NMS basés sur des modèles.
  • En matière de sécurité, le SD-WAN par rapport au DMVPN a atteint un tout nouveau niveau de qualité. Les principes clés sont la confiance nulle, la scalabilité et l'authentification à deux facteurs.

De ces conclusions simples, on pourrait avoir l'impression erronée que la création d'un réseau basé sur DMVPN/PfR a perdu toute pertinence aujourd'hui. Ce n'est évidemment pas tout à fait vrai. Par exemple, dans les cas où un grand nombre d'équipements obsolètes sont utilisés dans le réseau et qu'il n'est pas possible de les remplacer, le DMVPN peut permettre de relier les équipements « anciens » et « nouveaux » dans un réseau géo-distribué unique avec de nombreux avantages décrits ci-dessus.

D'un autre côté, il convient de rappeler que tous les routeurs d'entreprise Cisco actuels basés sur IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) prennent aujourd'hui en charge n'importe quel mode de fonctionnement – à la fois la routage classique, DMVPN et SD-WAN. Le choix dépend des besoins actuels et de la compréhension qu'à tout moment, sur le même équipement, il est possible de commencer à évoluer vers des technologies plus avancées.

Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster