le - dernière modification le par
Jimena Saez
Ci-dessous vous retrouverez les questions recueillies durant le webcast.
SD-WAN : Viptela OS avec vEdge et vManage
Notre expert : Alain Faure (présentateur)
Pour plus d'informations, visitez la section de Routage et Commutation.
Cliquez sur les boutons pour accéder aux contenus proposés
Sujets abordés lors de la présentation : Système Cisco / Viptela OS SD-WAN, Overlay Management Protocol (OMP), le Transport LOCator (TLOC), vManage, vEdge, vBond Orchestrator et vSmart Controller.
SD-WAN : Viptela OS avec vEdge et vManage
Questions Q&A
Q : Cela signifie qu'il faut un équipement supplémentaire vEdge en complément des routeurs physiques déjà présents sur chaque site...? - Christophe
R : A.F. - On se situe dans le cas d’une mise à jour.
Généralement le vEdge va faire le lien entre plusieurs domaines de routages séparés -Ex : quelques entreprises différentes dans la même tour, des immeubles proches dans le même quartier-. Dans ce cas, oui il faudra un équipement physique supplémentaire. Parce qu’il remplace un routeur d’accès coté « opérateur ».
En revanche si le réseau des clients (chaque VPN) est simple l’équipement sur lequel est le vEdge peut être suffisant.
Q : Le routeur que l'opérateur met chez le client doit avoir obligatoirement le VRF ? - Guy
R : A.F. - La segmentation de réseau virtuel (VPN) est la base du SDWAN. Pour chaque VPN il y a une table de routage indépendante (principe du VRF).
Donc le mécanisme de VRF (et les tables de routage séparées) se trouvent sur l’équipement qui gère la redistribution du routage entre le domaine de routage client (pour chaque VPN) et le protocole OMP qui va récupérer les annonces des routes pour les diffuser.
Le VRF est un mécanisme inhérent au SDWAN.
Q : Bonjour, pour des questions de cloisonnement (sécurité), comment sont séparés les flux des deux VPN's entre les vEdges ? - Diego
R : A.F. - Chaque liaison entre vEdge a son propre tunnel Ipsec. Tous les VPN entre les même vEdge ont le même tunnel IPSEC puisqu’il s‘agit d’un lien entre équipements. Le VPN posséde son propre mécanisme de séparation des flux entre VPN. Une clé par TLOC.
Quand le trafic passe à travers un tunnel Ipsec, un label est inséré après l’entête ESP pour identifier le VPN auquel il appartient :
Schéma d’un paquet dans le tunnel : [IP / UDP / ESP / Label / Paquet utilisateur]
Q : Bonjour, dans le cas d'un overlapping subents over vpn entre les sites A et sites B , est ce que le SDWAN supporte cette feature? Merci - Hassan
R : A.F. - Si on retrouve le même subnet disons 10.0.0.0 sur A et sur B, on est dans le même VPN donc il y aura conflit. Il faut utiliser classiquement de la NAT :
10.0.1.0/24(site A-VPN 10) --/NAT/---10.0.1.0/24 (site B-VPN 10) Cependant si on retrouve le même subnet disons 10.0.0.0 sur A et sur B et que l’on est dans des VPN différents, cela ne pose pas de problème car étant isolés, il n’y a pas risque de conflit :
10.0.1.0/24(site A-VPN 10) --//---10.0.2.0/24 (site B-VPN 10) 10.0.1.0/24(site A-VPN 20) --//---10.0.2.0/24 (site B-VPN 20).
Q : Les adjacences IP SEC entre 2 sites utilisent une clé unique qui n'est pas partagée avec les autres adjacences. ? En gros un tunnel ptp une clé? - Roland
R : A.F. - Oui c’est exact. Une clé dans un sens et une autre clé dans l’autre.
Une clé par TLOC.
Q : 512 VPN ce n’est pas beaucoup pour un opérateur... - Marie Laure
R : A.F. - Oui, mais il ne faut pas oublier le travail que l’équipement doit supporter : pour chaque VPN il doit recalculer la table de routage etc. Il y a une vraie charge supplémentaire. D’ailleurs vous devez vous poser la question est-ce que le mode SDWAN est nécessaire pour moi, si mon périmètre est trop petit. S’il est grand il faut bien planifier les VPNs, c’est un peu comme avec les VLANS.
Q : Pour compléter ma précédente question. Peut-on coupler la gestion des clés avec un serveur client de distribution de clés, si oui avec quel item vBond ? - Roland
R : A.F. - Il n’y a pas besoin de coupler la gestion des clés avec un server de distribution de clés. Parce que les clés sont gérée en locale par les vEdge et échangées par les vSmart à travers un plan de contrôle sécurisé. De plus elles sont régénérées et échangées par défaut toutes les 24heures.
Q : Est ce qu'il y a des routeur spécifique qui peuvent servir de vEdge ? - Guy
R : A.F. - Oui pour cela le site de Cisco donne ces informations, je vous donne le lien :
Q : Y a t-il des contraintes de sécurité sur le ZTP ? - Brice
R : A.F. - Le ZTP fait appel à Cisco, vous devez en tenir compte pour bien configurer vos firewalls.
Q : Est ce que c'est supporté les VM vSmart, vBond, vManager dans un cloud de type Azure et AWS? Ou il faut un Cloud full Cisco ou private cloud ? - Hassan
R : A.F. - Tout cela est possible.
Mais mon opinion personnelle (pas nécessairement celle de Cisco : Je ne suis pas salarié/consultant pour Cisco) est que vous devez avoir sous votre contrôle tous ces équipements qui constituent le cœur de votre production. Et avoir un PCA (Plan de Continuation d’Activité) en cas de sinistre ou de crise.
Q : Le CCNP SP inclut le SDWAN ? - Clément
R : A.F. - Pour l’instant ce n’est pas le cas. Voir le site de Cisco :
https://learningnetwork.cisco.com/s/ccnp-service-provider
Q : Quand on configure la redistribution entre OMP et le domaine de routage local, est-ce que l’on a des filtres possibles ? - Jérémy
R : A.F. - Oui, vous pouvez décider de filtrer les routes venant d’OSPF (external) et iBGP /eBGP. Ce doit être bien planifié