Fonctionnalit\u00e9s \u2013 qu'est-ce qu'une technologie peut faire que l'autre ne peut pas ? Et est-ce si important ?<\/li>\n<\/ul>\n<\/p>\n
Quelles sont les diff\u00e9rences architecturales et sont-elles vraiment importantes ?<\/h3>\n \nChacune des technologies mentionn\u00e9es comprend de nombreuses \u00ab pi\u00e8ces mobiles \u00bb, dont le r\u00f4le et les principes d'interaction diff\u00e8rent. La mani\u00e8re dont ces principes sont con\u00e7us d\u00e9termine directement la scalabilit\u00e9, la r\u00e9silience et l'efficacit\u00e9 globale de la solution. <\/p>\n
Examinons plus en d\u00e9tail les diff\u00e9rents aspects de l'architecture :<\/p>\n
Data-plane<\/b> \u2013 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\u00e9n\u00e9ralement r\u00e9alis\u00e9 de la m\u00eame mani\u00e8re sur les routeurs \u00e0 base de tunnels GRE Multipoint. La diff\u00e9rence r\u00e9side dans ce qui constitue le jeu de param\u00e8tres n\u00e9cessaire pour ces tunnels :<\/p>\n\ndans DMVPN\/PfR<\/b> \u2013 il s'agit d'une hi\u00e9rarchie de n\u0153uds strictement \u00e0 deux niveaux avec une topologie de type \u00ab \u00e9toile \u00bb 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 \u00e9tablir la connectivit\u00e9 du data-plane. Par cons\u00e9quent, les modifications sur le Hub sont consid\u00e9rablement compliqu\u00e9es<\/b>, notamment en ce qui concerne les changements ou l'ajout de nouveaux canaux WAN ou la modification des param\u00e8tres existants.<\/li>\ndans SD-WAN<\/b> \u2013 c'est un mod\u00e8le de d\u00e9tection de param\u00e8tres des tunnels \u00e9tabli de mani\u00e8re enti\u00e8rement dynamique, reposant sur le control-plane (protocole OMP) et l'orchestration-plane (interaction avec le contr\u00f4leur vBond pour des t\u00e2ches telles que la d\u00e9couverte de contr\u00f4leurs et le travers\u00e9e NAT). Dans ce cadre, toutes les topologies peuvent \u00eatre appliqu\u00e9es, y compris hi\u00e9rarchiques. Au sein de la topologie des tunnels \u00e9tablie, une configuration flexible de la topologie logique est possible dans chaque VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 fonctions d'\u00e9change, de filtrage et de modification des informations de routage et d'autres informations entre les composants de la solution. <\/p>\n\ndans DMVPN\/PfR<\/b> \u2013 se fait uniquement entre les routeurs Hub et Spoke. L'\u00e9change direct d'informations de routage entre Spoke n'est pas possible. Par cons\u00e9quent, sans un Hub op\u00e9rationnel, le fonctionnement du control-plane et du data-plane est impossible.<\/b>, ce qui impose \u00e0 Hub des exigences suppl\u00e9mentaires en mati\u00e8re de haute disponibilit\u00e9, qui ne peuvent pas toujours \u00eatre respect\u00e9es.<\/li>\ndans SD-WAN<\/b> \u2013 la gestion du plan de contr\u00f4le ne s'effectue jamais directement entre les routeurs \u2013 l'interaction se fait sur la base du protocole OMP et s'op\u00e8re obligatoirement via un type de contr\u00f4leur vSmart sp\u00e9cialis\u00e9, ce qui permet l'\u00e9quilibrage, la g\u00e9o-redondance et la gestion centralis\u00e9e de la charge de signalisation. Une autre caract\u00e9ristique du protocole OMP est sa grande r\u00e9silience aux pertes et son ind\u00e9pendance vis-\u00e0-vis de la vitesse du canal de communication avec les contr\u00f4leurs (dans des limites raisonnables, bien s\u00fbr). Cela permet \u00e9galement de d\u00e9ployer les contr\u00f4leurs SD-WAN dans des nuages publics ou priv\u00e9s avec un acc\u00e8s via Internet.<\/li>\n<\/ul>\n Plan de politique<\/b> \u2013 partie de la solution responsable de la d\u00e9finition, de la diffusion et de l'application des politiques de gestion du trafic dans un r\u00e9seau distribu\u00e9.<\/p>\n\nDMVPN <\/b>\u2013 est en r\u00e9alit\u00e9 limit\u00e9 par des politiques de qualit\u00e9 de service (QoS), personnalis\u00e9es individuellement sur chaque routeur via CLI ou mod\u00e8les Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 les politiques PfR sont \u00e9labor\u00e9es sur le routeur central Master Controller (MC) via CLI et sont ensuite automatiquement diffus\u00e9es vers les MC de filiale. Les m\u00eames chemins de transmission que pour le plan de donn\u00e9es sont utilis\u00e9s pour diffuser les politiques. Il n'est pas possible de dissocier l'\u00e9change de politiques, d'informations de routage et de donn\u00e9es utilisateur. La diffusion des politiques n\u00e9cessite une connectivit\u00e9 IP entre Hub et Spoke. De plus, la fonction de MC peut, si n\u00e9cessaire, \u00eatre combin\u00e9e avec un routeur DMVPN. L'utilisation de mod\u00e8les Prime Infrastructure pour la cr\u00e9ation centralis\u00e9e des politiques est possible (mais pas obligatoire). Une caract\u00e9ristique importante est que la politique est \u00e9labor\u00e9e de mani\u00e8re globale sur tout le r\u00e9seau de mani\u00e8re uniforme \u2013 les politiques individuelles pour des segments sp\u00e9cifiques ne sont pas prises en charge.<\/b>.<\/li>\nSD-WAN<\/b> Les politiques de gestion du trafic et de qualit\u00e9 de service sont d\u00e9finies de mani\u00e8re centralis\u00e9e via l'interface graphique Cisco vManage, accessible notamment via Internet (si n\u00e9cessaire). Elles sont r\u00e9parties sur des canaux de signalisation directement ou indirectement via des contr\u00f4leurs vSmart (selon le type de politique). Elles ne d\u00e9pendent pas de la connectivit\u00e9 du data-plane entre les routeurs, car elles utilisent tous les chemins de transmission de trafic disponibles entre le contr\u00f4leur et le routeur.\n Pour diff\u00e9rents segments de r\u00e9seau, il est possible de cr\u00e9er de mani\u00e8re flexible diverses politiques \u2013 le domaine d'application de la politique est d\u00e9fini par de nombreux identifiants uniques pr\u00e9vus dans la solution \u2013 num\u00e9ro de succursale, type d'application, direction du trafic, etc.\n<\/li>\n<\/ul>\n
Plane d'orchestration<\/b> \u2013 des m\u00e9canismes permettant aux composants de se d\u00e9couvrir dynamiquement, de se configurer et de coordonner leur interaction ult\u00e9rieure.<\/p>\n\ndans DMVPN\/PfR<\/b> La d\u00e9couverte mutuelle entre les routeurs est bas\u00e9e sur la configuration statique des appareils Hub et le param\u00e9trage correspondant des appareils Spoke. La d\u00e9couverte dynamique se produit uniquement pour le Spoke, qui informe le dispositif Hub de ses param\u00e8tres de connexion, qui a \u00e9t\u00e9 pr\u00e9alablement inscrit dans la configuration du Spoke. Sans connectivit\u00e9 IP entre le Spoke et au moins un Hub, il est impossible de former ni le data-plane ni le control-plane.<\/b><\/li>\ndans SD-WAN<\/b> L'orchestration des composants de la solution se fait en utilisant le contr\u00f4leur vBond, avec lequel chaque composant (routeurs et contr\u00f4leurs vManage\/vSmart) doit pr\u00e9alablement \u00e9tablir une connectivit\u00e9 IP.\n \u00c0 l'origine, les composants ne connaissent pas les param\u00e8tres de connexion les uns des autres \u2013 pour cela, un interm\u00e9diaire d'orchestration vBond est n\u00e9cessaire. Le principe g\u00e9n\u00e9ral est le suivant : chaque composant apprend (automatiquement ou statiquement) uniquement les param\u00e8tres de connexion au vBond dans la phase initiale, puis le vBond informe le routeur des contr\u00f4leurs vManage et vSmart (pr\u00e9c\u00e9demment d\u00e9couverts), ce qui permet d'\u00e9tablir automatiquement toutes les liaisons de signalisation n\u00e9cessaires. <\/p>\n
\u00c0 l'\u00e9tape suivante, le nouveau routeur d\u00e9couvrira les autres routeurs du r\u00e9seau par le biais d'un \u00e9change OMP avec le contr\u00f4leur vSmart. Ainsi, le routeur, ne connaissant initialement aucune des param\u00e8tres du r\u00e9seau, sera capable de d\u00e9tecter et de se connecter compl\u00e8tement et automatiquement aux contr\u00f4leurs, et ensuite de d\u00e9couvrir et de cr\u00e9er une connectivit\u00e9 avec les autres routeurs de mani\u00e8re automatique. \u00c0 cela, les param\u00e8tres de connexion de tous les composants sont initialement inconnus et peuvent changer au cours de l'exploitation.\n<\/li>\n<\/ul>\n
Plan de gestion<\/b> \u2013 partie de la solution qui assure la gestion et la surveillance centralis\u00e9es.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 aucune solution d\u00e9di\u00e9e au plan de gestion n'est pr\u00e9vue. Pour l'automatisation de base et la surveillance, il est possible d'utiliser des produits tels que Cisco Prime Infrastructure. Chaque routeur peut \u00eatre g\u00e9r\u00e9 par la ligne de commande CLI. Les int\u00e9grations avec des syst\u00e8mes externes via API ne sont pas pr\u00e9vues.<\/b><\/li>\nSD-WAN<\/b> \u2013 toutes les interactions et la surveillance se font de mani\u00e8re centralis\u00e9e via l'interface graphique du contr\u00f4leur vManage. Toutes les fonctionnalit\u00e9s de la solution, sans exception, sont accessibles \u00e0 la configuration via vManage, ainsi que par le biais d'une biblioth\u00e8que d'API REST enti\u00e8rement document\u00e9e.\n Tous les param\u00e8tres du r\u00e9seau SD-WAN dans vManage se r\u00e9sument \u00e0 deux concepts principaux \u2013 la cr\u00e9ation de mod\u00e8les de p\u00e9riph\u00e9riques (Device Template) et la cr\u00e9ation de politiques qui d\u00e9finissent la logique de fonctionnement du r\u00e9seau et le traitement du trafic. Dans ce cadre, vManage, en traduisant la politique \u00e9labor\u00e9e par l'administrateur, s\u00e9lectionne automatiquement quels changements doivent \u00eatre effectu\u00e9s et sur quels dispositifs individuels ou contr\u00f4leurs, ce qui renforce consid\u00e9rablement l'efficacit\u00e9 et l'\u00e9volutivit\u00e9 de la solution.<\/p>\n
Via l'interface vManage, non seulement la configuration de la solution Cisco SD-WAN est accessible, mais \u00e9galement la surveillance compl\u00e8te de l'\u00e9tat de tous les composants de la solution, allant jusqu'\u00e0 l'\u00e9tat actuel des m\u00e9triques des tunnels individuels et des statistiques d'utilisation des diff\u00e9rentes applications sur la base de l'analyse DPI.<\/p>\n
Bien que l'interaction soit centralis\u00e9e, tous les composants (contr\u00f4leurs et routeurs) disposent \u00e9galement d'une interface en ligne de commande (CLI) enti\u00e8rement fonctionnelle, qui est n\u00e9cessaire lors de la mise en \u0153uvre 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 \u00e0 la fois la s\u00e9curit\u00e9 locale et la source unique de modifications dans un tel r\u00e9seau : vManage.<\/li>\n<\/ul>\n
\nS\u00e9curit\u00e9 int\u00e9gr\u00e9e<\/b> \u2013 ici, il ne s'agit pas seulement de prot\u00e9ger les donn\u00e9es des utilisateurs lors de leur transmission sur des canaux ouverts, mais aussi de la s\u00e9curit\u00e9 globale du r\u00e9seau WAN bas\u00e9 sur la technologie choisie.<\/p>\n\ndans DMVPN\/PfR<\/b> la possibilit\u00e9 de chiffrer les donn\u00e9es utilisateurs et les protocoles de signalisation est pr\u00e9vue. En utilisant certains mod\u00e8les de routeurs, des fonctions de pare-feu avec inspection du trafic, IPS\/IDS sont \u00e9galement disponibles. Il est possible de segmenter les r\u00e9seaux de succursales en utilisant VRF. Il existe \u00e9galement une possibilit\u00e9 d'authentification (\u00e0 un facteur) des protocoles de contr\u00f4le.\n Le routeur distant est par d\u00e9faut consid\u00e9r\u00e9 comme un \u00e9l\u00e9ment de confiance dans le r\u00e9seau \u2013 c'est-\u00e0-dire que les cas de compromission physique d'appareils individuels et la possibilit\u00e9 d'un acc\u00e8s non autoris\u00e9 ne sont pas envisag\u00e9s ou pris en compte, il n'y a pas d'authentification \u00e0 deux facteurs pour les composants de la solution, ce qui, dans un r\u00e9seau g\u00e9ographiquement distribu\u00e9, peut repr\u00e9senter des risques suppl\u00e9mentaires s\u00e9rieux.<\/b> <\/li>\ndans SD-WAN<\/b> comme avec DMVPN, il est pr\u00e9vu la possibilit\u00e9 de chiffrer les donn\u00e9es utilisateur, mais avec des fonctionnalit\u00e9s de s\u00e9curit\u00e9 r\u00e9seau et de segmentation L3\/VRF beaucoup plus \u00e9tendues (MSS, IPS\/IDS, filtrage URL, filtrage DNS, AMP\/TG, SASE, proxy TLS\/SSL, etc.). Dans ce cas, l'\u00e9change de cl\u00e9s de chiffrement est r\u00e9alis\u00e9 plus efficacement via les contr\u00f4leurs vSmart (et non directement), par des canaux de signalisation pr\u00e9\u00e9tablis, prot\u00e9g\u00e9s par un chiffrement DTLS\/TLS bas\u00e9 sur des certificats de s\u00e9curit\u00e9. Cela garantit la s\u00e9curit\u00e9 de cet \u00e9change et assure une meilleure \u00e9volutivit\u00e9 de la solution, jusqu'\u00e0 des dizaines de milliers d'appareils dans un seul r\u00e9seau.\n Toutes les connexions de signalisation (contr\u00f4leur \u00e0 contr\u00f4leur, contr\u00f4leur \u00e0 routeur) sont \u00e9galement s\u00e9curis\u00e9es sur la base de DTLS\/TLS. Les routeurs sont \u00e9quip\u00e9s de certificats de s\u00e9curit\u00e9 lors de leur fabrication, avec la possibilit\u00e9 de remplacement\/renouvellement. L'authentification \u00e0 deux facteurs est r\u00e9alis\u00e9e par l'ex\u00e9cution obligatoire et simultan\u00e9e de deux conditions pour le fonctionnement du routeur\/contr\u00f4leur dans le r\u00e9seau SD-WAN :<\/p>\n
\nCertificat de s\u00e9curit\u00e9 valide<\/li>\n Ajout explicite et conscient par l'administrateur de chaque composant \u00e0 la liste blanche des dispositifs autoris\u00e9s.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Diff\u00e9rences fonctionnelles entre SD-WAN et DMVPN\/PfR<\/h2>\n \nEn abordant la discussion sur les diff\u00e9rences fonctionnelles, il convient de noter que beaucoup d'entre elles sont une continuit\u00e9 des diff\u00e9rences architecturales \u2014 il n'est pas secret que lors de la conception de l'architecture de la solution, les d\u00e9veloppeurs s'appuient sur les possibilit\u00e9s qu'ils souhaitent obtenir \u00e0 la fin. Passons en revue les diff\u00e9rences les plus significatives entre les deux technologies.<\/p>\n
AppQ (Quality d'Application) \u2013 fonctions garantissant la qualit\u00e9 de transmission du trafic des applications professionnelles<\/h3>\n \nLes fonctionnalit\u00e9s cl\u00e9s des technologies examin\u00e9es visent \u00e0 am\u00e9liorer autant que possible l'exp\u00e9rience utilisateur lors de l'utilisation d'applications critiques pour les entreprises dans un r\u00e9seau distribu\u00e9. C'est particuli\u00e8rement important dans des conditions o\u00f9 une partie de l'infrastructure n'est pas contr\u00f4l\u00e9e par l'IT ou ne garantit m\u00eame pas une transmission r\u00e9ussie des donn\u00e9es.<\/p>\n
DMVPN ne fournit pas de tels m\u00e9canismes de mani\u00e8re autonome. La meilleure chose \u00e0 faire dans un r\u00e9seau 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\u00e9termin\u00e9 par sa disponibilit\u00e9 et le r\u00e9sultat des protocoles de routage. Dans ce cas, l'\u00e9tat de bout en bout du chemin\/tunnel et sa possible d\u00e9gradation partielle en termes de m\u00e9triques cl\u00e9s, significatives pour les applications r\u00e9seau \u2013 latence, variation de latence (jitter) et pertes (%) \u2013 ne sont pas pris en compte. En cons\u00e9quence, comparer directement le DMVPN classique au SD-WAN en mati\u00e8re de r\u00e9solution des t\u00e2ches d'AppQ n'a pas de sens \u2013 DMVPN ne peut pas r\u00e9soudre ce probl\u00e8me. 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. <\/p>\n
Avant de discuter des diff\u00e9rences, parlons bri\u00e8vement des similitudes entre les technologies. Ainsi, les deux technologies :<\/p>\n
\ndisposent d'un m\u00e9canisme permettant d'\u00e9valuer dynamiquement l'\u00e9tat de chaque tunnel \u00e9tabli \u00e0 travers des m\u00e9triques sp\u00e9cifiques - au minimum, la latence, la variation de latence et la perte de paquets (%)<\/li>\n utilisent un ensemble d'outils pour former, distribuer et appliquer des r\u00e8gles (politiques) de gestion du trafic en tenant compte des r\u00e9sultats de la mesure de l'\u00e9tat des principales m\u00e9triques des tunnels.<\/li>\n classifient le trafic des applications aux niveaux L3-L4 (DSCP) du mod\u00e8le OSI ou par les signatures L7 des applications gr\u00e2ce aux m\u00e9canismes DPI int\u00e9gr\u00e9s dans le routeur.<\/li>\n permettent de d\u00e9finir pour les applications significatives des valeurs seuil acceptables pour les m\u00e9triques, des r\u00e8gles de transmission de trafic par d\u00e9faut, ainsi que des r\u00e8gles de reroutage du trafic en cas de d\u00e9passement de ces seuils.<\/li>\n lors de l'encapsulation du trafic en GRE\/IPSec, utilisent un m\u00e9canisme bien \u00e9tabli dans l'industrie pour transf\u00e9rer le marquage DSCP interne vers l'en-t\u00eate externe du paquet GRE\/IPSec, ce qui permet de synchroniser les politiques QoS de l'organisation et de l'op\u00e9rateur de t\u00e9l\u00e9communications (sous r\u00e9serve d'un SLA appropri\u00e9).<\/li>\n<\/ul>\n\n
Comment les m\u00e9canismes d'\u00e9valuation des m\u00e9triques de bout en bout SD-WAN et DMVPN\/PfR diff\u00e8rent-ils ?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nPour \u00e9valuer les m\u00e9triques standards de l'\u00e9tat du tunnel, des capteurs logiciels (Probes) actifs et passifs sont utilis\u00e9s. Les actifs se basent sur le trafic utilisateur, tandis que les passifs \u00e9mulant ce trafic (en son absence). <\/li>\n L'ajustement fin des temporisateurs et des conditions de d\u00e9tection de d\u00e9gradation n'est pas disponible - l'algorithme est fixe.<\/li>\n Une mesure de la bande passante utilis\u00e9e dans le sens sortant est \u00e9galement disponible. Ce qui ajoute \u00e0 DMVPN\/PfR une flexibilit\u00e9 suppl\u00e9mentaire dans la gestion du trafic.<\/li>\n Dans ce cadre, certains m\u00e9canismes PfR en cas de d\u00e9passement des m\u00e9triques s'appuient sur un retour d'information sous forme de messages TCA (Threshold Crossing Alert) sp\u00e9ciaux, qui doivent provenir du r\u00e9cepteur de trafic vers la source, ce qui suppose que l'\u00e9tat des canaux mesur\u00e9s doit \u00eatre au minimum suffisant pour transmettre ces messages TCA, ce qui dans la plupart des cas n'est pas un probl\u00e8me, mais ne peut \u00e9videmment pas \u00eatre garanti. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nPour l'\u00e9valuation continue des m\u00e9triques standard de l'\u00e9tat du tunnel, le protocole BFD en mode echo est utilis\u00e9. Aucune r\u00e9troaction sp\u00e9ciale sous forme de TCA ou de messages similaires n'est requise \u2013 l'isolement des domaines de d\u00e9faillance est respect\u00e9. Il n'est \u00e9galement pas n\u00e9cessaire qu'un trafic utilisateur soit pr\u00e9sent pour \u00e9valuer l'\u00e9tat du tunnel.<\/li>\n Il est possible d'ajuster finement les minuteries BFD pour r\u00e9guler la vitesse de d\u00e9clenchement et la sensibilit\u00e9 de l'algorithme aux d\u00e9gradations du canal de communication, allant de quelques secondes \u00e0 quelques minutes.\n
Au moment de la r\u00e9daction de cet article, chaque tunnel ne pr\u00e9voit qu'une seule session BFD. Cela peut potentiellement limiter la granularit\u00e9 lors de l'analyse de l'\u00e9tat du tunnel. En r\u00e9alit\u00e9, cela peut devenir une contrainte uniquement dans le cas d'une connexion WAN bas\u00e9e sur MPLS L2\/L3 VPN avec un SLA QoS convenu \u2013 si le marquage DSCP du trafic BFD (apr\u00e8s encapsulation en IPSec\/GRE) co\u00efncide avec la file d'attente \u00e0 haute priorit\u00e9 dans le r\u00e9seau de l'op\u00e9rateur, cela pourrait affecter la pr\u00e9cision et la rapidit\u00e9 de d\u00e9tection de la d\u00e9gradation pour le trafic de faible priorit\u00e9. Toutefois, il est possible de modifier le marquage BFD par d\u00e9faut pour r\u00e9duire le risque de telles situations. Les prochaines versions du logiciel Cisco SD-WAN devraient inclure des r\u00e9glages BFD plus fins, ainsi que la possibilit\u00e9 de lancer plusieurs sessions BFD dans un m\u00eame tunnel avec des valeurs DSCP individuelles (pour diff\u00e9rentes applications).<\/li>\n Le BFD permet \u00e9galement d'\u00e9valuer la taille maximale des paquets pouvant \u00eatre transmis par un tunnel sans fragmentation. Cela permet \u00e0 SD-WAN d'ajuster dynamiquement des param\u00e8tres tels que MTU et TCP MSS Adjust, afin d'utiliser au mieux la bande passante disponible sur chaque canal.<\/li>\n Dans SD-WAN, il existe \u00e9galement une option de synchronisation QoS avec les op\u00e9rateurs de t\u00e9l\u00e9communications bas\u00e9e non seulement sur le champ L3 DSCP, mais aussi sur les valeurs L2 CoS qui peuvent \u00eatre automatiquement g\u00e9n\u00e9r\u00e9es dans le r\u00e9seau filial par des dispositifs sp\u00e9cialis\u00e9s, tels que les t\u00e9l\u00e9phones IP.<\/li>\n<\/ul>\n<\/p>\n
Quelles sont les diff\u00e9rences dans les capacit\u00e9s, les m\u00e9thodes de d\u00e9termination et d'application des politiques AppQ ?<\/h3>\n <\/p>\n
Politiques DMVPN\/PfR :<\/h4>\n <\/p>\n
\nElles sont d\u00e9finies sur le(s) routeur(s) du site central (SC) via l'interface de ligne de commande CLI ou des mod\u00e8les de configuration CLI. La cr\u00e9ation de mod\u00e8les CLI n\u00e9cessite une pr\u00e9paration et une connaissance de la syntaxe des politiques.\n
D\u00e9finis globalement sans possibilit\u00e9 de personnalisation ou de modification selon les besoins des segments de r\u00e9seau individuels.<\/b><\/li>\nLa cr\u00e9ation interactive de politiques via une interface graphique n'est pas pr\u00e9vue.<\/li>\n Le suivi des modifications, l'h\u00e9ritage et la cr\u00e9ation de plusieurs versions de politiques pour un changement rapide ne sont pas pr\u00e9vus.<\/li>\n Elles sont automatiquement diffus\u00e9es sur les routeurs des agences distantes. Pour cela, les m\u00eames canaux de communication que ceux utilis\u00e9s pour la transmission des donn\u00e9es des utilisateurs sont employ\u00e9s. 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.<\/li>\n S'appliquent sur chaque routeur et, si n\u00e9cessaire, modifient le r\u00e9sultat des protocoles de routage standard, ayant une priorit\u00e9 plus \u00e9lev\u00e9e. <\/li>\n Dans les cas o\u00f9 tous les canaux WAN de l'agence subissent des pertes de trafic significatives, aucun m\u00e9canisme de compensation n'est pr\u00e9vu<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Politiques SD-WAN :<\/h4>\n <\/p>\n
\nD\u00e9finies dans l'interface graphique vManage via un assistant de mod\u00e8les interactif.<\/li>\n Permettent la cr\u00e9ation de plusieurs politiques, la copie, l'h\u00e9ritage et le basculement entre les politiques en temps r\u00e9el.<\/li>\n Supportent la personnalisation des politiques pour diff\u00e9rents segments (agences) du r\u00e9seau<\/li>\n Se propagent en utilisant n'importe quel canal de signalisation disponible entre le contr\u00f4leur et le routeur et\/ou vSmart \u2013 ne d\u00e9pendent pas directement de la connectivit\u00e9 du plan de donn\u00e9es entre les routeurs. Il est cependant n\u00e9cessaire d'avoir une connectivit\u00e9 IP entre le routeur lui-m\u00eame et les contr\u00f4leurs.\n
Dans les cas o\u00f9 tous les canaux disponibles de l'agence subissent des pertes de donn\u00e9es significatives d\u00e9passant les seuils acceptables pour les applications critiques, il est possible d'utiliser des m\u00e9canismes suppl\u00e9mentaires pour am\u00e9liorer la fiabilit\u00e9 de la transmission :\n\nFEC (Correction d'Erreur Avanc\u00e9e)<\/b> \u2013 utilise un algorithme sp\u00e9cial de codage redondant. Lors de la transmission de trafic critique sur des canaux avec un pourcentage de pertes significatif, FEC peut \u00eatre activ\u00e9 automatiquement et permet de r\u00e9cup\u00e9rer les parties de donn\u00e9es perdues si n\u00e9cessaire. Cela augmente l\u00e9g\u00e8rement la bande passante utilis\u00e9e, mais am\u00e9liore consid\u00e9rablement la fiabilit\u00e9.\n
Duplication des flux de donn\u00e9es<\/b> En plus de la politique FEC, il peut \u00eatre pr\u00e9vu un doublage automatique du trafic des applications s\u00e9lectionn\u00e9es en cas de pertes encore plus graves qui ne peuvent \u00eatre compens\u00e9es par FEC. Dans ce cas, les donn\u00e9es choisies seront transmises sur tous les tunnels vers la filiale destinataire avec une d\u00e9sint\u00e9gration subs\u00e9quente (\u00e9limination des copies de paquets inutiles). Ce m\u00e9canisme augmente consid\u00e9rablement l'utilisation des canaux, mais am\u00e9liore \u00e9galement de mani\u00e8re significative la fiabilit\u00e9 de la transmission.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Les capacit\u00e9s de Cisco SD-WAN, sans \u00e9quivalence directe dans DMVPN\/PfR<\/h3>\n \nL'architecture de la solution Cisco SD-WAN permet dans certains cas d'obtenir des capacit\u00e9s dont la mise en \u0153uvre dans le cadre de DMVPN\/PfR est soit extr\u00eamement difficile, soit inappropri\u00e9e en raison des efforts n\u00e9cessaires, soit tout simplement impossible. Examinons les plus int\u00e9ressantes d'entre elles :<\/p>\n
Ing\u00e9nierie du trafic (TE)<\/h4>\n \nTE comprend des m\u00e9canismes qui permettent de d\u00e9vier le trafic du chemin standard form\u00e9 par les protocoles de routage. TE est souvent utilis\u00e9 pour assurer une haute disponibilit\u00e9 des services r\u00e9seau, gr\u00e2ce \u00e0 sa capacit\u00e9 \u00e0 transf\u00e9rer rapidement et\/ou \u00e0 l'avance un trafic important sur un chemin alternatif (non-intersectant), afin d'assurer une meilleure qualit\u00e9 de service ou une rapidit\u00e9 de r\u00e9cup\u00e9ration en cas de d\u00e9faillance sur le chemin principal. <\/p>\n
La complexit\u00e9 de la mise en \u0153uvre de TE r\u00e9side dans la n\u00e9cessit\u00e9 de calculer et de r\u00e9server \u00e0 l'avance (v\u00e9rifier) un itin\u00e9raire alternatif. Dans les r\u00e9seaux MPLS des op\u00e9rateurs de t\u00e9l\u00e9communications, cette t\u00e2che est r\u00e9alis\u00e9e 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\u00e9 ces derniers temps, \u00e9tant plus optimis\u00e9e pour la configuration et l'orchestration centralis\u00e9es. Dans les WAN classiques, ces technologies ne sont g\u00e9n\u00e9ralement pas pr\u00e9sentes ou sont r\u00e9duites \u00e0 l'utilisation de m\u00e9canismes hop-by-hop comme le Policy-Based Routing (PBR), qui peuvent d\u00e9tourner le trafic, mais le font sur chaque routeur s\u00e9par\u00e9ment \u2013 sans tenir compte de l'\u00e9tat global du r\u00e9seau ou des r\u00e9sultats du PBR aux \u00e9tapes pr\u00e9c\u00e9dentes ou suivantes. Le r\u00e9sultat de l'application de ces options de TE est peu prometteur \u2013 MPLS TE, en raison de la complexit\u00e9 de sa configuration et de son exploitation, est g\u00e9n\u00e9ralement utilis\u00e9 uniquement dans la partie la plus critique du r\u00e9seau (noyau), tandis que le PBR est utilis\u00e9 sur des routeurs individuels sans possibilit\u00e9 de former une politique PBR unique sur l'ensemble du r\u00e9seau. Cela s'applique \u00e9galement aux r\u00e9seaux bas\u00e9s sur DMVPN.<\/p>\n
Service-chaining <\/h4>\n \nLa formation de cha\u00eenes de services est une t\u00e2che encore plus laborieuse dans le routage classique que le m\u00e9canisme d'ing\u00e9nierie de trafic d\u00e9j\u00e0 d\u00e9crit. Dans ce cas, il est n\u00e9cessaire non seulement de cr\u00e9er un itin\u00e9raire sp\u00e9cifique pour une application r\u00e9seau particuli\u00e8re, mais aussi de garantir la possibilit\u00e9 de faire sortir le trafic du r\u00e9seau sur certains (ou tous) n\u0153uds de la r\u00e9seau SD-WAN afin qu'il soit trait\u00e9 par une application ou un service sp\u00e9cial (MSP, \u00c9quilibrage, Mise en cache, Inspection du trafic, etc.). Il est \u00e9galement n\u00e9cessaire de pouvoir contr\u00f4ler l'\u00e9tat de ces services externes, afin d'\u00e9viter des situations de black-holing, ainsi que d'avoir des m\u00e9canismes permettant de d\u00e9ployer ces services externes similaires dans diff\u00e9rentes g\u00e9o-localisations, avec la possibilit\u00e9 pour le r\u00e9seau de choisir automatiquement le n\u0153ud de service le plus optimal pour traiter le trafic d'une certaine filiale. Dans le cas de Cisco SD-WAN, cela peut \u00eatre facilement r\u00e9alis\u00e9 en cr\u00e9ant une politique centralis\u00e9e correspondante qui \u00ab colle \u00bb tous les aspects de la cha\u00eene de services cible en une seule entit\u00e9 et modifie automatiquement la logique du data-plane et du control-plane uniquement l\u00e0 o\u00f9 cela est n\u00e9cessaire.<\/p>\n
Quel est le r\u00e9sultat ?<\/h2>\n \nIl est \u00e9vident que DMVPN (avec ou sans Performance Routing) et Cisco SD-WAN r\u00e9solvent finalement des t\u00e2ches tr\u00e8s similaires<\/b> en ce qui concerne le r\u00e9seau WAN distribu\u00e9 de l'organisation. Les diff\u00e9rences architecturales et fonctionnelles significatives de la technologie Cisco SD-WAN \u00e9l\u00e8vent le processus de r\u00e9solution de ces t\u00e2ches \u00e0 un autre niveau qualitatif<\/b>. En r\u00e9sum\u00e9, on peut noter les diff\u00e9rences significatives entre les technologies SD-WAN et DMVPN\/PfR :<\/p>\n\nDMVPN\/PfR utilise des technologies \u00e9prouv\u00e9es pour la construction de r\u00e9seaux VPN superpos\u00e9s et, dans le domaine du data-plane, ressemble davantage \u00e0 la technologie SD-WAN plus moderne, bien qu'il existe certaines limitations en raison de la n\u00e9cessit\u00e9 d'une configuration statique des routeurs et d'un choix de topologies limit\u00e9 \u00e0 Hub-n-Spoke. D'autre part, DMVPN\/PfR poss\u00e8de certaines fonctionnalit\u00e9s qui ne sont pas encore disponibles dans le cadre de la SD-WAN (notamment le BFD par application).<\/li>\n En ce qui concerne la technologie du control-plane, elles diff\u00e8rent fondamentalement. Compte tenu du traitement centralis\u00e9 des protocoles de signalisation, la SD-WAN permet, entre autres, de r\u00e9duire consid\u00e9rablement les domaines de pannes et 'd\u00e9tache' le processus de transmission du trafic utilisateur de l'interaction de signalisation : l'indisponibilit\u00e9 temporaire des contr\u00f4leurs n'affecte pas la possibilit\u00e9 de transmettre le trafic utilisateur. En m\u00eame temps, l'indisponibilit\u00e9 temporaire de n'importe quelle succursale (y compris celle centrale) n'affecte en rien la capacit\u00e9 des autres succursales \u00e0 interagir entre elles et avec les contr\u00f4leurs.<\/li>\n L'architecture de d\u00e9finition et d'application des politiques de gestion du trafic dans le cas de la SD-WAN surpasse \u00e9galement celle de DMVPN\/PfR : la g\u00e9o-redondance est beaucoup mieux mise en \u0153uvre, il n'y a pas de d\u00e9pendance au Hub, et il y a plus d'options pour le r\u00e9glage fin des politiques. De plus, la liste des sc\u00e9narios de gestion du trafic mis en \u0153uvre est \u00e9galement consid\u00e9rablement plus grande.<\/li>\n Le processus d'orchestration de la solution diff\u00e8re \u00e9galement consid\u00e9rablement. DMVPN n\u00e9cessite des param\u00e8tres pr\u00e9alablement connus, qui doivent \u00eatre d'une mani\u00e8re ou d'une autre refl\u00e9t\u00e9s dans la configuration, ce qui limite quelque peu la flexibilit\u00e9 de la solution et la possibilit\u00e9 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\u00f4leurs, mais sait 'qui peut \u00eatre consult\u00e9' - cela suffit non seulement pour \u00e9tablir automatiquement la liaison avec les contr\u00f4leurs, mais aussi pour former automatiquement une topologie de data-plane enti\u00e8rement connect\u00e9e, qui peut ensuite \u00eatre ajust\u00e9e\/modifi\u00e9e de mani\u00e8re flexible \u00e0 l'aide de politiques.<\/li>\n Dans le domaine de la gestion centralis\u00e9e, de l'automatisation et de la surveillance, le SD-WAN surpassait sans surprise les capacit\u00e9s du DMVPN\/PfR, qui r\u00e9sultent de l'\u00e9volution des technologies classiques et reposent en grande partie sur la ligne de commande CLI et l'application de syst\u00e8mes NMS bas\u00e9s sur des mod\u00e8les. <\/li>\n En mati\u00e8re de s\u00e9curit\u00e9, le SD-WAN par rapport au DMVPN a atteint un tout nouveau niveau de qualit\u00e9. Les principes cl\u00e9s sont la confiance nulle, la scalabilit\u00e9 et l'authentification \u00e0 deux facteurs.<\/li>\n<\/ul>\n\nDe ces conclusions simples, on pourrait avoir l'impression erron\u00e9e que la cr\u00e9ation d'un r\u00e9seau bas\u00e9 sur DMVPN\/PfR a perdu toute pertinence aujourd'hui. Ce n'est \u00e9videmment pas tout \u00e0 fait vrai. Par exemple, dans les cas o\u00f9 un grand nombre d'\u00e9quipements obsol\u00e8tes sont utilis\u00e9s dans le r\u00e9seau et qu'il n'est pas possible de les remplacer, le DMVPN peut permettre de relier les \u00e9quipements \u00ab anciens \u00bb et \u00ab nouveaux \u00bb dans un r\u00e9seau g\u00e9o-distribu\u00e9 unique avec de nombreux avantages d\u00e9crits ci-dessus.<\/p>\n
D'un autre c\u00f4t\u00e9, il convient de rappeler que tous les routeurs d'entreprise Cisco actuels bas\u00e9s sur IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) prennent aujourd'hui en charge n'importe quel mode de fonctionnement \u2013 \u00e0 la fois la routage classique, DMVPN et SD-WAN. Le choix d\u00e9pend des besoins actuels et de la compr\u00e9hension qu'\u00e0 tout moment, sur le m\u00eame \u00e9quipement, il est possible de commencer \u00e0 \u00e9voluer vers des technologies plus avanc\u00e9es.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t