annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 
cancel
Meddane
Rising star
Rising star

12.PNG

 

L’un des changements majeurs du domaine des Technologies WANs est l’apparition de la solution SD-WAN et son influence sur la gestion du trafic de l’entreprise, ce trafic qui migre progressivement vers le Cloud et qui force l’entreprise à s’appuyer sur des transports (MPLS, INTERNET etc..) communément appelé couche Underlay afin d’offir une meilleure rentabilité pour leurs employés et leurs partenaires. L’impact de la solution SD-WAN sur le Business, nous a ramené a se poser la question suivante: Techniquement quelle est cette valeur ajoutée par SD-WAN? pour répondre à cette question, il y’a pas mieux que de faire un pas en arrière dans le passé et analyser ce que nous utilisions comme technologie WAN, la plus répandue DMVPN, quelles sont les problématiques et les limites de ses technologies traditionnelles, et comment le SD-WAN comme remède palliatif est venu remédier à ses limites. A travers cet article on verra ce face à face DMVPN vs SD-WAN.

Avec Cisco SD-WAN, vous pouvez implémenter n’importe quelle topologie. Dans Cisco SD-WAN, on peut avoir une combinaison de topologie Hub-and-Spoke et Spoke-to-Spoke, ceci est possible grace au concept de VPN (VRF), avec SD-WAN, on peut avoir une VRF en Hub-and-Spoke et une autre VRF en Spoke-to-Spoke. Mettre en place ces topologies disparates avec le traditionnel DMVPN ce n’est pas aisé.

Le Hub joue un rôle central dans le Control Plane et le Data Plane. C’est pour cette raison qu’il est recommandé de déployer au moins deux Hubs. Maintenant le Hub comme point central pose-t-il vraiment un problème potentiel?, si le Hub est hors service, les tunnels seront down, et les spokes n’peuvent plus solliciter le NHS (Hub), ainsi en perdant la connectivité du Hub, le trafic entre les Spokes s’en trouve impacté aussi.

Dans Cisco SD-WAN, le Hub n’a pas de rôle spécial. En fait en séparant le Control Plane et le Data Plane et en délocalisant le Control Plane à un controleur appelé vSmart, le Hub vEdge dans le SD-WAN aura le meme role que les autre Spokes vEdge, c’est à dire s’occuper juste du Data Plane.

La perte de connectivité du Hub n’affectera nullement la connectivité entre Spokes. Ce qui permet d’implémenter un design résilient.

Dans un réseau DMVPN combiné avec IPsec, l’administrateur doit mettre en place l’authentification des Routeurs participants dans le DMVPN, elle peut se faire soit avec PSK (Pre-shared Key) ou bien des certificats (Rappelez vous de la commande « auth » dans la policy isakamp ainsi que la commande « crypto isakmp key address »).

la méthode d’authentification la plus utilisée est le PSK, car elle est simple a configurer, c’est juste un mot de passe secret entre les deux routeurs VPN mais ce n’est pas la plus sécurisé. Souvent dans une architecture avec une plusieurs Spokes, le meme PSK (le meme mot de passe) est utilisé dans tous les routeurs, pire encore, la clé n’est jamais modifiée.

La méthode la plus sécurisée est d’utiliser les certificats au détriment du Pre-Shared Key. Ce qui implique que l’entreprise doit posséder sa propre infrastructure PKI. Cette méthode est plus sécurisée certes mais elle pose une complexité dans la mise en oeuvre de cette PKI et la gestion des certificats, comment les distribuer à tous les routeurs?

L’IPsec aussi est composée de deux associations de sécurité SAs, appelées Phase 1 (Isakmp) et Phase 2 (IPsec). Le rôle de la Phase 1 est de protéger la négociation de la phase 2, tandis que la phase 2 a comme rôle la protection des données.

Mais qu’est ce qui est négocié dans la Phase 2, c’est tout simplement le protocole ESP (ou éventuellement AH), c’est à dire l’algorithme de cryptage des données et l’algorithme d’intégrité.

En vérité tous routeurs participants dans le DMVPN en Spoke-to-Spoke doivent négocier deux tunnels:

Tunnel ISAKMP (Phase 1), par exemple 3DES, PSK et sha.
Tunnel IPsec (Phase 2), par exemple AES, HMAC-SHA.

Pour chaque tunnel, des négociations de paramètres des deux phases, générer la clé de cryptage pour chaque tunnel, vérifier l’identité (PSK ou par certificat) de chaque spoke. Sur un ensemble d’un design complexe, les ressources des routeurs s’en trouveront impactés. Et la gestion de toutes ses implémentations devient complexe.

Avec Cisco SD-WAN, tous les routeurs vEdges sont déja authentifiés pour joindre le Overlay du SD-WAN. Pratiquement parlant, lors du déploiement initial, pour que les routeurs Edges puissent joindre le Overlay et s’enregistrent dans vManage, il faut qu’ils s’authentifient avec des certificats avec le vBond (l’Orchestrateur), le vSmart (le Contrôleur) et vManage (la console de management). Le vSmart le controleur possède une WhiteList contenant les numéros de séries de ses vEdges (les Hubs et les Spokes). Par conséquent tout routeur vEdge souhaitant joindre le Overlay, il doit présenter un certificat valide et un numéro de série présent dans la WhiteList.

Si l’équipement est volé pour une raison ou une autre, il suffit juste d’invalider le certificat ou tout simplement le supprimer de la WhiteList. C’est plus sécurisé que le PSK dans le DMVPN Traditionnel et nous avons une gestion simplifié des certificats.

Le deuxième point important est que les routeurs vEdges (Data Plane) une fois authentifiés, établiront automatiquement des tunnels DTLS avec le vSmart le controleur.

A partir de la, dans Cisco SD-WAN, nous avons des routeurs dont l’identité est vérifiée et des tunnels DTLS établis avec le vSmart.

Afin d’optimiser les négociations IPsec, la phase 1 qu’on connait traditionnellement et qu’on a décrit auparavant d’une manière succinte n’a pas lieu d’être entre les routeurs Edges pour générer les clés de cryptage (ses clés qui seront utilisées dans la phase 2 pour protéger les données). Mais plutôt entre les routeurs Edges et le controleur vSmart. Et plus judicieusement, les routeurs Edges et vSmart vont utiliser les tunnels DTLS déja en place pour négocier les clés de cryptage. SD-WAN n’a plus besoin de la fameuse Phase 1 ISAKMP. Ses clés seront negociées à travers les tunnels DTLS à l’aide du protocol OMP.

Qu’en est-il du routage?, les protocoles les plus utilisés dans DMVPN sont EIGRP et BGP basés sur les destinations, les deux ont fait leur preuves mais plus aujourd’hui où le besoin en terme de routage en se basant sur l'application sensible à la latence est devenu vital, le jitter et le packet loss est devenu vital, comment s’assurer que notre visioconference passe par un chemin dont la latence, le jitter et le packet loss sont assez acceptable pour une réunion virtuelle agréable? les protocoles IGP traditionnels n’ont pas cette intelligence. En d’autre termes un protocole IGP comme OSPF choisi toujours le meilleur chemin en se basant sur la bande passante, imaginons deux chemins A (Lien 1G) et B (Lien 10G) pour une destination 10.1.1.0/24. Il est clair pour OSPF le chemin B est meilleur. Et si le chemin B présente un pourcentage de packet loss supérieur à 1% et un jitter dépassant 30 ms. Ca sera dramatique pour notre visioconference.

Ajoutons à cela le control des mises à jour de routage, avec les protocoles IGP traditionnels, les route-map, les prefix-list et les access-list ont fait aussi leur preuve mais dans un réseau complexe avec énormément de routeurs, la gestion de la configuration devient fastidieuse car tout simplement ce n’est pas centralisé. Chaque routeur est responsable de son propre Control Plane.

Avec Cisco SD-WAN, l’introduction du routage par application appelé Application Aware Routing ou tout bonnement AAR permet justement à travers des policies qui ressemblent à des route map, de router le trafic voip par exemple ou les applications critiques si le lien présente des valeurs acceptable de la latence, le jitter et le packet loss. Si un dépassement d’un seuil prédéfini est détecté, l’application est rerouté via un autre chemin. Pour le filtrage du Controle Plane ou les policies, y’a plus de soucis à se faire, c’est implementé dans vManage, envoyé et appliqué dans vSmart, les mises à jour de routage (OMP) sont toujours envoyés par les routeurs vEdges (les spokes) au vSmart, on n’a plus besoin de policy de controle plane et filtrage de mise à jour dans les spokes, c’est le vSmart qui hérite ses policies du vManage et qui les applique dans l’overlay entre les spokes. Gérer et Contrôler les mises à jour de routage dans un point central vSmart est moins pénible.

Mise en Route
Bienvenue dans la Communauté !

La communauté est un hub pour vous connecter avec vos pairs et les spécialistes Cisco, pour demander de l'aide, partager votre expertise, développer votre réseau et évoluer professionnellement.
Vous êtes un nouvel arrivant ? Cliquez ici pour en savoir plus.

Nous voulons que votre navigation soit la meilleure, donc vous trouverez des liens pour vous aider à être rapidement familiarisé avec la Communauté Cisco :