Cisco 300-415: Intégration Cloud, SaaS et multi-cloud — Guide d'étude

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Fait partie du Cisco SD-WAN 300-415 ENSDWI — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Cisco, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

Cisco SD-WAN étend une connectivité sécurisée et basée sur des politiques dans le cloud public et le SaaS en s’appuyant sur Cloud OnRamp for IaaS et Cloud OnRamp for SaaS. La solution utilise le même plan de contrôle SD-WAN dans le cloud que sur site : les périphériques WAN Edge établissent des connexions de contrôle DTLS ou TLS avec les contrôleurs vSmart et construisent des tunnels de plan de données IPsec vers d’autres routeurs WAN Edge, tandis que vSmart distribue les routes et les politiques en utilisant OMP et gère la distribution des clés de chiffrement. L’orchestrateur vBond amorce l’adjacence initiale du plan de contrôle, et vManage fournit une automatisation, une visualisation et des opérations de cycle de vie centralisées. Cette section détaille les modèles de conception multi-cloud, les prérequis de déploiement, les constructions de sécurité et de routage, l’optimisation SaaS et les considérations opérationnelles, en mettant l’accent sur les modes de défaillance et les compromis.

Cloud OnRamp for IaaS et déploiement de WAN Edge virtuel

Cloud OnRamp for IaaS automatise le provisionnement des routeurs WAN Edge virtuels dans AWS, Microsoft Azure et Google Cloud. vManage s’appuie sur les API du fournisseur de cloud pour instancier les objets de calcul, de réseau et de sécurité, puis attache les modèles de périphériques SD-WAN et intègre les edges virtuels dans l’overlay.

Éléments clés et prérequis :

• Plateformes WAN Edge virtuelles : Cisco CSR 1000v (cEdge) et vEdge Cloud. Celles-ci peuvent également être hébergées sur des hyperviseurs fonctionnant sur Cisco UCS ou Cisco ENCS 5000 Series pour le cloud privé.
• Images des contrôleurs : vManage, vSmart et vBond prennent en charge le déploiement sur site ou IaaS avec des formats d’image standard tels que .ova et .qcow2, permettant d’avoir des contrôleurs basés dans le cloud lorsque souhaité pour l’élasticité et des SLA gérés.
• Marketplace et images : Avant le déploiement, souscrivez/acceptez les conditions pour les images des routeurs dans la marketplace de chaque cloud (par exemple, AMI dans AWS, plan Azure Marketplace, image GCP). Le fait de ne pas accepter les conditions entraîne des erreurs d’API ou des échecs de provisionnement silencieux.
• Modèles de périphériques : Attachez un modèle de périphérique spécifique au site dans vManage avant de lancer le déploiement dans le cloud pour garantir que la joignabilité du plan de contrôle VPN0, les paramètres système/OMP, la segmentation et l’adressage IP/interface sont appliqués automatiquement.
• Amorçage/contrôle : Les edges cloud nouvellement déployés doivent pouvoir atteindre les contrôleurs SD-WAN via le VPN0. Si les contrôleurs sont publics, assurez la connectivité sortante vers les FQDN et les ports de vBond/vSmart/vManage (HTTPS/TLS/DTLS). S’ils sont privés, fournissez un transport privé via Direct Connect/ExpressRoute/Interconnect ou un VPN site à site.

Groupes de sécurité, tables de routage et considérations NAT :

• Autoriser le plan de contrôle et de données : Autorisez le trafic sortant vers vBond et vSmart en utilisant TLS/DTLS et vers les edges pairs en utilisant IPsec. Si du NAT est présent, assurez-vous que le NAT-T (UDP 4500) est autorisé. Des règles de groupe de sécurité asymétriques ou des autorisations de ports éphémères manquantes peuvent provoquer un DCONFAIL (échec de connexion DTLS) ou des tunnels de plan de données instables.
• Tables de routage/UDR : Associez les sous-réseaux VPC/VNet appropriés aux tables de routage qui envoient le trafic vers les interfaces internes du WAN Edge pour les VM spoke et vers la passerelle cloud (IGW/NAT/edge) pour Internet. Des tables de routage mal associées ou des routes par défaut peuvent créer un trou noir (blackhole) pour le trafic de branche ou de retour.
• MTU/fragmentation : L’encapsulation IPsec réduit le MTU effectif. Envisagez le MSS clamping sur l’interface ou l’ajustement du MTU pour éviter la fragmentation à travers les fabrics cloud et les NIC virtuelles.

Modes de défaillance et mesures d’atténuation :

• Privilèges IAM/RBAC insuffisants : vManage ne peut pas créer d’instances, de NIC ou attacher de groupes de sécurité. Validez les rôles IAM, les attributions de rôle Azure ou les portées de compte de service GCP.
• Abonnement à l’image non accepté : Le déploiement échoue lors de la création de l’instance. Acceptez au préalable les conditions de la marketplace et épinglez la version souhaitée.
• Certificat et horloge : Les instances cloud avec une heure désynchronisée ne peuvent pas valider les certificats des contrôleurs. Vérifiez avec

undefined

et la synchronisation NTP.

• Mauvaise configuration du modèle : Une passerelle/DNS incorrecte pour le VPN0 empêche la résolution des contrôleurs ; utilisez le test de joignabilité depuis la console de l’instance et les outils de connectivité de vManage.

Modèles de connectivité et intégration de transit pour AWS, Azure et Google Cloud

AWS

• Modèles : VPC de transit utilisant des WAN Edges en tant que NVAs ; ou AWS Transit Gateway (TGW) natif avec des WAN Edges terminant des tunnels IPsec/BGP dans des VPCs attachés au TGW. Cloud OnRamp for IaaS peut déployer un VPC hub par région avec des paires d’edges pour la haute disponibilité (HA).
• Routage : Utiliser les tables de routage VPC pour diriger les préfixes des sous-réseaux spoke vers les ENIs des WAN Edge. Lors de l’utilisation de TGW, propager les routes des spokes vers les domaines de routage du TGW et annoncer les préfixes des succursales depuis le WAN Edge via BGP. Éviter le chevauchement de CIDR entre les VPCs/succursales pour prévenir les trous noirs.
• Groupes de sécurité et NACLs : Autoriser VXLAN n’est pas requis pour le SD-WAN, mais autoriser les ports IPsec et du plan de contrôle. Les règles sans état des NACL doivent correspondre dans les deux sens.

Azure

• Modèles : VNets en étoile (hub-and-spoke) avec des WAN Edges dans le VNet hub ; Azure Route Server ou peering BGP avec une NVA pour le routage dynamique ; ou intégration Azure Virtual WAN avec des connexions IPsec depuis les hubs SD-WAN vers les hubs VWAN.
• Routage : Les routes définies par l’utilisateur (UDRs) sur les sous-réseaux spoke pointent vers les NICs des WAN Edge comme saut suivant (next hop). Pour Virtual WAN, préférer BGP pour l’échange de routes dynamique et la segmentation en utilisant plusieurs connexions.
• Network Security Groups : Refléter l’intention des groupes de sécurité AWS ; assurer la présence de sondes de santé et de règles de LB si vous utilisez Azure Load Balancer pour la HA des edges.

Google Cloud

• Modèles : NVAs WAN Edge dans un projet hôte Shared VPC ou un déploiement par projet ; utiliser HA VPN ou Cloud Router pour BGP avec Cloud Interconnect ou sur site ; diriger le trafic spoke via des routes personnalisées vers les NICs des WAN Edge.
• Routage : Les VPCs sont globaux ; utiliser des routes statiques personnalisées avec une instance de saut suivant ou une passerelle de saut suivant. Pour le routage dynamique, utiliser Cloud Router avec BGP vers le WAN Edge là où c’est supporté. S’assurer que les règles de pare-feu autorisent l’IPsec/le plan de contrôle.

Compromis de l’intégration de transit et hybride :

• Le transit natif (TGW/VWAN) simplifie la mise à l’échelle et le routage est-ouest mais peut introduire des coûts supplémentaires par Go et par attachement ; le transit basé sur des NVAs fournit des fonctionnalités SD-WAN avancées et un contrôle des politiques au détriment des limitations de débit et de la mise à l’échelle des appliances.
• Les hubs multi-régions centralisés réduisent la latence vers les services cloud et SaaS, mais la duplication des hubs par région augmente la charge de gestion. Utiliser l’automatisation Cloud OnRamp pour des déploiements cohérents.

Cloud OnRamp for SaaS, Stratégie de sortie (Egress) et Connectivité Hybride

Cloud OnRamp for SaaS optimise les chemins applicatifs vers les fournisseurs SaaS en mesurant continuellement la performance depuis les succursales et les hubs régionaux/cloud vers les points d’entrée SaaS, puis en appliquant le chemin offrant la meilleure expérience via le routage App-Aware.

• Mesure et prise de décision : La fonctionnalité sonde plusieurs sorties (DIA locale, hub régional, hub cloud) pour la perte, la latence et la gigue, sélectionnant le chemin préférentiel par application (par exemple, Microsoft 365, WebEx, Salesforce). Les politiques sont distribuées par vSmart.
• DNS et sortie locale (breakout) : Aligner la résolution DNS avec la politique de sortie locale. Si les domaines SAS se résolvent différemment par région, un DNS incohérent peut annuler la sélection du chemin. Envisager un DNS local au point de sortie choisi pour assurer un mappage anycast optimal.
• Chaînage de services de sécurité : Combiner la sortie locale avec une sécurité intégrée (umbrella, pare-feu cloud ou chaînage de services en colocation) lorsque la conformité exige une inspection. Compromis entre la latence et la profondeur de l’inspection.

Options de sortie (egress) vers l’Internet public :

• DIA locale au niveau des edges de succursale pour la plus faible latence vers le SaaS ; nécessite une posture de sécurité locale.
• Sortie par un hub régional ou cloud lorsque les succursales ont des circuits limités ou des impératifs de sécurité centralisée ; se prémunir contre le retour asymétrique en utilisant une politique SD-WAN et un NAT symétrique si nécessaire.

Connectivité privée vers le cloud :

• AWS Direct Connect, Azure ExpressRoute et Google Cloud Interconnect offrent une bande passante déterministe et une gigue plus faible pour les charges de travail IaaS privées. Intégrer avec les WAN Edges en utilisant le peering privé et BGP, puis redistribuer dans OMP. Notez que la plupart des applications SaaS préfèrent toujours les chemins de l’Internet public ; la connectivité privée est adaptée aux services privés, pas aux flux SaaS génériques.
• Compromis hybrides : Les liaisons privées ajoutent du coût et de la complexité mais améliorent la performance vers les backends stateful ou les zones de gravité des données. Maintenir des conceptions à double chemin (privé + Internet) avec un basculement basé sur la performance.

Hubs cloud régionaux et topologie cloud-vers-succursale :

• Placer des paires de hubs SD-WAN dans les régions cloud les plus proches des utilisateurs et des points d’entrée SaaS critiques. Les superpositions IPsec de succursale à hub cloud réduisent l’effet trombone via le siège social (HQ) et permettent un basculement multi-régions rapide.
• Conception tenant compte des segments : Utiliser des VRFs à travers OMP pour segmenter le trafic des utilisateurs, PCI et invités ; appliquer des politiques de sortie distinctes par segment.

Identité cloud, automatisation, visibilité et cycle de vie

Prérequis pour l’IAM cloud et le provisionnement :

• AWS : Fournissez à vManage un rôle IAM ou des clés d’accès autorisés pour EC2, VPC, IAM PassRole, CloudFormation et l’étiquetage (tagging). Appliquez le principe du moindre privilège par ressource et par région. Les actions refusées provoquent des piles partielles et des objets orphelins.
• Azure : Créez un principal de service avec le rôle Contributeur sur l’abonnement/groupe de ressources cible et le rôle Contributeur de réseau nécessaire sur les VNet. Acceptez les conditions de la marketplace pour les images via la CLI ou le portail avant l’automatisation.
• GCP : Utilisez un compte de service avec des rôles tels que compute.admin, compute.networkAdmin et iam.serviceAccountUser. Activez les API requises. Des portées insuffisantes bloquent la création de cartes réseau (NIC) ou de routes.

Visibilité opérationnelle :

• Les tableaux de bord de vManage affichent les connexions de contrôle, la convergence des routes OMP, les performances des applications et les scores Cloud OnRamp for SaaS. Utilisez des superpositions de couleurs pour comparer les options de sortie (egress) et valider les résultats des politiques.
• Journalisation et dépannage : sur le WAN Edge, vérifiez les certificats et le contrôle avec :

show control local-properties
show control connections
show omp peers

DCONFAIL indique des problèmes de transport ou de groupe de sécurité/ACL ; les captures de paquets sur les vNIC et les journaux de flux cloud (flow logs) aident à identifier les ports bloqués ou les chemins asymétriques.

Cycle de vie et mise à l’échelle :

• Mettez à l’échelle les contrôleurs en clusterisant vManage et en déployant plusieurs instances vSmart et vBond sur différents domaines de panne/régions. Les contrôleurs basés sur le cloud bénéficient de l’élasticité IaaS et de la haute disponibilité (HA) gérée.
• Gestion des images et des modèles : préparez les mises à niveau logicielles dans vManage, effectuez des vérifications préalables, puis déployez-les sur les clusters en utilisant des fenêtres de maintenance. Pour les routeurs Edge dans le cloud, utilisez des mises à jour progressives d’instances (rolling updates) avec des vérifications de santé (health checks) et des politiques de drainage (drain policies). Étiquetez (tag) les ressources pour les associer aux sites et aux modèles.
• Sauvegarde et reprise après sinistre (DR) : exportez régulièrement la configuration, les modèles et les listes d’appareils de vManage. Pour les déploiements cloud, faites des snapshots ou utilisez des images de référence (golden images) ; assurez-vous que les données utilisateur (certificats, clés) sont préservées ou peuvent être ré-enregistrées.

Scénario de problème pratique

Acme BioPharma migre ses applications de R&D vers AWS et Azure tout en rencontrant de faibles performances de Microsoft 365 depuis ses succursales en Amérique du Nord. Ils ont besoin d’une conception de hubs SD-WAN double-cloud avec une optimisation SaaS, une sécurité centralisée au niveau des hubs cloud et un accès privé déterministe aux charges de travail de laboratoire.

1. Définir des hubs cloud régionaux dans us-east-1 (AWS) et East US (Azure).

• Justification : Positionne les hubs à proximité de la majorité des utilisateurs et des points d’entrée SaaS, réduisant la latence et offrant une redondance géographique.

2. Préparer les prérequis pour l’automatisation cloud.

• Justification : Dans AWS, s’abonner à l’AMI du CSR 1000v et créer un rôle IAM avec les permissions EC2, VPC et CloudFormation, y compris iam:PassRole. Dans Azure, accepter le plan de la marketplace et créer un principal de service avec le rôle Contributeur sur le groupe de ressources du hub. Sans cela, Cloud OnRamp ne peut pas instancier les VNet/VPC et les VM de routeur.

3. Déployer des paires de hubs Cloud OnRamp for IaaS avec des modèles vManage.

• Justification : Utiliser vManage pour automatiser deux instances WAN Edge par région sur des AZ/domaines de panne distincts. Attacher des modèles d’appareils qui configurent le VPN0, les ID système, OMP, le routage basé sur les applications (app-aware routing) et BGP pour le transit cloud. L’automatisation garantit des constructions cohérentes et évite les pannes dues à une mauvaise configuration.

4. Intégrer avec le transit cloud (AWS TGW et VNet hub Azure).

• Justification : Attacher les réseaux spoke à AWS TGW et configurer les tables de routage TGW pour propager les sous-réseaux spoke vers le VPC du hub SD-WAN, tout en annonçant les préfixes des succursales depuis les WAN Edges vers TGW via BGP. Dans Azure, appliquer des UDR sur les spokes pour pointer le préfixe par défaut ou des préfixes spécifiques vers les NIC des WAN Edge. Cela fournit une connectivité évolutive de spoke à succursale et de spoke à spoke.

5. Établir une connectivité privée pour la R&D vers les hubs.

• Justification : Activer Direct Connect vers us-east-1 et ExpressRoute vers East US avec un peering privé, se terminant sur les hubs WAN Edge avec BGP. Les liaisons privées offrent une gigue plus faible et un déterminisme plus élevé pour les charges de travail de laboratoire ; OMP redistribue les routes apprises à l’échelle de la fabric.

6. Activer Cloud OnRamp for SaaS pour Microsoft 365 et les applications de collaboration.

• Justification : Activer les sondes de performance depuis les succursales et les deux hubs ; appliquer une politique de sélection de chemin sur vSmart pour préférer la sortie la plus performante (DIA local si supérieur, sinon le hub performant le plus proche). Cela optimise dynamiquement l’expérience utilisateur en fonction des fluctuations des conditions Internet.

7. Mettre en œuvre la sécurité et la segmentation.

• Justification : Créer des VRF pour la R&D, l’entreprise (corporate) et les invités (guest). Chaîner le trafic à destination d’Internet à travers des pare-feu cloud colocalisés dans les hubs pour l’entreprise et la R&D, tout en autorisant un accès Internet direct pour les invités avec Umbrella DNS. Les groupes de sécurité dans AWS/Azure autorisent le plan de contrôle DTLS/TLS et le plan de données IPsec tout en restreignant la gestion aux adresses IP de l’entreprise.

8. Valider et opérationnaliser.

• Justification : Utiliser vManage pour confirmer la stabilité des connexions de contrôle, des routes OMP et des scores de chemin SaaS. Exécuter show control local-properties sur chaque routeur Edge de hub pour vérifier la validité du certificat et la synchronisation de l’heure. Activer les journaux de flux cloud pour détecter les refus inattendus. Mettre en œuvre des mises à niveau progressives via vManage et faire des snapshots des instances cloud pour maintenir une hygiène de cycle de vie cohérente.

Cette approche aboutit à des hubs multi-cloud résilients, un accès SaaS optimisé et une connectivité privée contrôlée vers les charges de travail sensibles, tout en tirant parti de la politique centralisée et de l’observabilité de Cisco SD-WAN pour réduire le risque opérationnel.

← Qualité de service et services de multidiffusion · Tous les domaines · Opérations →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →