Cisco 300-415: Architecture et plans de la fabric Cisco SD-WAN — 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 est une fabric basée sur l’intention, construite à partir de composants et de plans distincts qui séparent les fonctions de gestion, d’orchestration, de contrôle et de données. L’architecture s’adapte de quelques agences à des milliers, indépendamment du transport de sous-couche (underlay), tout en maintenant un contrôle et une sécurité déterministes. Cette section explique les rôles de vManage, vSmart, vBond et WAN Edge ; les plans et protocoles qui les interconnectent ; les choix de plateforme ; l’adressage et la segmentation ; les modèles de topologie de sur-couche (overlay) ; les concepts de multi-location (multitenancy) et de groupement ; ainsi que les principaux compromis de conception et modes de défaillance que vous devez prendre en compte.

Composants et Plans de la Fabric

• WAN Edge : Le routeur du plan de données situé en agence, sur le campus, en colocation ou en périphérie du cloud. Il établit des tunnels de données sécurisés, exécute les politiques, utilise BFD pour la détection de la vitalité des chemins, échange les routes OMP avec les contrôleurs et achemine le trafic des utilisateurs.
• Contrôleur vSmart : Le cerveau du plan de contrôle. Il construit et maintient la topologie de sur-couche, distribue les informations de routage et de politique via OMP, et orchestre la connectivité des WAN Edge ainsi que la distribution des clés de chiffrement pour permettre un peering IPsec sécurisé entre les équipements de périphérie.
• Orchestrateur vBond : Le premier point de contact pour les nouveaux équipements. Il authentifie l’identité des équipements, aide à la traversée NAT (NAT traversal) et coordonne la connexion de chaque WAN Edge à vSmart. Il maintient des connexions persistantes avec les contrôleurs vSmart et réside généralement dans un espace d’adresses IP publiques joignable pour un enregistrement (onboarding) universel.
• vManage : Le plan de gestion et d’orchestration (NMS). Il fournit la saisie des intentions, les modèles de configuration, la gestion des images, la télémétrie, l’automatisation Cloud OnRamp et les API. vManage ne participe pas au plan de contrôle de l’acheminement.

Plans et protocoles :

• Plan de gestion : vManage utilise des canaux sécurisés (NETCONF/gRPC sur TLS) pour superviser et configurer les équipements et les contrôleurs.
• Plan d’orchestration : vBond utilise DTLS/TLS pour authentifier les équipements, partager la joignabilité des contrôleurs et traverser les NAT (NAT punching). Avec les certificats de contrôleur et sans port alternatif configuré, vBond écoute sur les ports UDP/TCP 12346.
• Plan de contrôle : vSmart utilise OMP pour échanger les préfixes, les TLOCs et les politiques avec les équipements WAN Edge. Les connexions de contrôle utilisent DTLS par défaut ; TLS est également pris en charge et souvent requis par les pare-feux stricts ou les régimes de conformité.
• Plan de données : Les équipements WAN Edge construisent des tunnels IPsec (ou GRE le cas échéant) entre les TLOCs pour un transport chiffré, avec des sondes BFD par tunnel pour une détection de défaillance en moins d’une seconde et un routage sensible aux applications (application-aware routing).

Cycle de vie lors de la jonction :

1. Le WAN Edge contacte vBond, s’authentifie et reçoit les listes de contrôleurs.
2. Le WAN Edge établit des sessions de contrôle DTLS/TLS vers vSmart (et vers vManage pour la gestion).
3. vSmart distribue les informations de clés de chiffrement ; le WAN Edge forme alors des tunnels IPsec avec d’autres WAN Edges conformément à la politique et à la topologie.

Implications en matière de résilience :

• La perte de vManage n’affecte que la configuration et la visibilité ; l’acheminement des données continue.
• La perte de vBond affecte l’enregistrement (onboarding) des nouveaux équipements ; les équipements existants ne sont pas affectés.
• La perte de tous les contrôleurs vSmart isole le plan de contrôle ; les tunnels de données persistent mais les changements de route/politique s’arrêtent et un état de contrôle obsolète peut dégrader les opérations au fil du temps.
• Le basculement de chemin piloté par BFD et les TLOCs multiples assurent la continuité du plan de données pendant les pannes de la sous-couche (underlay) ou du transport.

Identité, Adressage et Segmentation

L’identité et l’adressage sont centrés sur la sur-couche (overlay) :

• Nom de l’organisation : Une chaîne de caractères à l’échelle de la fabric qui doit correspondre sur tous les équipements et contrôleurs ; une non-concordance empêche l’adjacence du plan de contrôle.
• System IP : Un identifiant unique de 32 bits par équipement, semblable à une boucle de rappel (loopback), utilisé dans les tuples TLOC et l’adressage du plan de contrôle. Il n’est lié à aucune interface physique.
• Site ID : Un identifiant numérique regroupant les équipements sur un même site. Par défaut, les équipements partageant un même Site ID ne forment pas de tunnels de données directs pour éviter les hairpins (allers-retours inutiles) et les boucles au sein d’un site.
• Certificats : Les équipements et les contrôleurs utilisent une identité X.509. Les WAN Edges matériels exploitent l’identité sécurisée de l’équipement (SUDI) pour le provisionnement sans intervention (zero-touch provisioning) ; tous les équipements doivent s’inscrire et être autorisés dans vManage avant de rejoindre la fabric.

VPNs clés :

• VPN 0 (Transport) : Transporte la connectivité de la sous-couche (underlay) et les interfaces TLOC vers MPLS, DIA, large bande (broadband) ou LTE. Les routes NAT, DHCP, PPPoE et statiques/par défaut se terminent ici. TLOC = {system IP, couleur, encapsulation} où la couleur caractérise le transport (par exemple, mpls, biz-internet, public-internet) et l’encapsulation est IPsec ou GRE.
• VPN 512 (Gestion) : Gestion hors bande (out-of-band) des équipements et joignabilité des contrôleurs. Sur IOS XE SD-WAN, cela correspond à un VRF de gestion ; sur vEdge, il s’agit explicitement du VPN 512. Les contrôleurs et les WAN Edges établissent des sessions de gestion en utilisant des protocoles sécurisés par TLS.
• VPNs de service (1–511 sauf 512) : Transportent les services utilisateur et peuvent exécuter OSPF, EIGRP, BGP, du routage statique ou du pontage (bridging). Les politiques (centralisées et localisées) dirigent les flux inter-VPN et intra-VPN, la QoS et la sécurité.

Éléments de configuration de base utiles :

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Modes de défaillance à surveiller :

• Des System IPs ou Site IDs en double créent des anomalies de contrôle ou une suppression non désirée des tunnels.
• Une non-concordance du nom de l’organisation empêche les adjacences OMP.
• L’expiration ou la révocation d’un certificat rompt la confiance du contrôleur ou de l’équipement.
• Une route par défaut de gestion mal placée dans le VPN 512 isole un équipement des contrôleurs ; une route par défaut de transport mal placée dans le VPN 0 isole les TLOCs.

Plateformes, modèles de déploiement et conception des contrôleurs

Plateformes WAN Edge :

• Cisco IOS XE SD-WAN : Pris en charge sur les plateformes ISR 4000 Series et ASR 1000 Series (et la famille Catalyst 8000). Préférez IOS XE SD-WAN pour une vélocité des fonctionnalités à long terme et des services de succursale unifiés.
• vEdge : Plateformes matérielles/virtuelles antérieures basées sur Viptela, toujours prises en charge dans de nombreux déploiements ; la planification de la migration doit tenir compte des écarts de fonctionnalités et des calendriers de cycle de vie.
• Virtual WAN Edge : S’exécute sur des hyperviseurs et des serveurs, y compris Cisco UCS et Cisco ENCS 5000 Series, et dans les clouds publics (AWS, Azure, GCP). Utilisez Cloud OnRamp pour automatiser les déploiements IaaS ; les prérequis incluent la souscription à l’image du marketplace cloud (par exemple, l’AMI AWS) et la préparation d’un modèle de périphérique dans vManage.

Indépendance de l’underlay et diversité des transports :

• Chaque TLOC est lié à un transport avec une couleur associée ; la politique peut préférer, équilibrer ou exclure des transports par application, SLA ou rôle de site.
• IPsec est la valeur par défaut sur les underlays non fiables ; GRE peut être utilisé sur un MPLS privé lorsque le chiffrement n’est pas nécessaire ou est limité.
• BFD fournit la détection de l’état de fonctionnement (liveliness) par tunnel et les métriques de SLA (perte, latence, gigue) pour piloter le routage applicatif (application-aware routing).

Clustering, scalabilité, haute disponibilité et placement des contrôleurs :

• vManage : Déployez en tant que cluster de trois nœuds ou plus pour la haute disponibilité (HA) et la résilience ; co-localisez avec un stockage à haut débit pour la télémétrie et le référentiel d’images. Sauvegardez fréquemment.
• vSmart : Déployez plusieurs contrôleurs sur différents domaines de panne et zones géographiques ; tous les WAN Edges établissent des sessions de contrôle avec plus d’un vSmart. Les instances vSmart scalent horizontalement ; prévoyez une capacité N+1 pour supporter la perte d’un contrôleur.
• vBond : Déployez au moins deux orchestrateurs dans l’espace d’adressage public (ou avec un NAT statique et un mappage de port cohérent). vBond maintient des sessions permanentes avec vSmart et des sessions transitoires avec les WAN Edges pendant l’intégration (onboarding).
• Placement : Les contrôleurs peuvent être hébergés dans vos datacenters ou dans le cloud public. Assurez une joignabilité entrante déterministe depuis Internet pour vBond et une sortie suffisante pour les WAN Edges. Si des équipements intermédiaires (middleboxes) imposent des exceptions à l’inspection TLS, préférez les sessions de contrôle TLS à DTLS.

Notes opérationnelles :

• Le transport par défaut du plan de contrôle est DTLS ; passez à TLS lors de la traversée de pare-feux stricts ou de domaines de conformité qui n’autorisent que le contrôle chiffré basé sur TCP. Assurez-vous que les ports appropriés sont autorisés de bout en bout.
• Lorsqu’un WAN Edge rejoint le réseau, il établit des sessions DTLS/TLS avec vSmart et des tunnels IPsec avec les routeurs d’extrémité pairs (peer edges) en fonction de la joignabilité OMP et de la politique. Assurez les mécanismes de keepalive NAT et les pinholes UDP sur les circuits à large bande pour éviter les coupures de tunnel silencieuses.

Topologies en superposition, multilocation et compromis de conception

Les modèles de topologie sont mis en œuvre via des politiques de contrôle centralisées (annonces de routes et de TLOC) et des politiques de données localisées :

• Maillage complet (Full mesh) : Latence la plus faible entre tous les sites ; excellente résilience ; charge la plus élevée sur les plans de contrôle et de données en raison du grand nombre de sessions IPsec/BFD.
• Hub-and-spoke (en étoile) : Mise à l’échelle simple avec moins de tunnels ; le hub devient un point de congestion pour la bande passante et la résilience sans une conception à double hub ; latence de chemin plus élevée pour les communications de spoke à spoke.
• Hub régional : Équilibre la latence et la mise à l’échelle en limitant les maillages complets aux régions et en utilisant les hubs pour le trafic inter-régional ; nécessite une politique rigoureuse pour éviter l’effet trombone (tromboning).
• Double hub (actif/actif ou actif/standby) : Améliore la résilience et peut répartir la charge ; augmente la complexité du contrôle (ECMP, départage, prévention des boucles) et consomme plus de ressources sur les hubs.

Multilocation et groupement :

• Véritable multilocation : Les fournisseurs de services peuvent activer le mode multi-locataire sur les contrôleurs pour héberger plusieurs organisations logiques avec des plans de contrôle, des administrateurs et des politiques isolés sur le même cluster de contrôleurs.
• Segmentation par locataire ou unité commerciale : Utiliser des VPN de service pour imposer la séparation du trafic, la fuite de routes (route-leaking) si nécessaire, et des politiques/QoS par VPN.
• Groupement d’équipements : Utiliser les groupes d’équipements vManage, les listes de sites, les listes de VPN, les listes de préfixes/TLOC pour cibler les politiques, les mises à niveau et les modèles par fonction, région ou rôle.

Compromis de conception :

• Latence vs contrôle des politiques : Le maillage complet minimise la latence mais complique l’application et l’observation des politiques ; le modèle hub-and-spoke simplifie le contrôle mais ajoute de la latence pour les flux est-ouest.
• Résilience vs passage à l’échelle opérationnelle : Plus de TLOC, de transports et de hubs augmentent la disponibilité et le choix des chemins, mais multiplient les sessions IPsec/BFD et la charge sur le plan de contrôle. Utiliser la régionalisation et la sumarisation pour maîtriser la taille des tables OMP et FIB.
• Diversité de l’underlay vs coût : L’ajout de connexions haut débit (broadband) et LTE améliore la joignabilité et la résistance aux baisses de performance (brownouts) ; le coût, le comportement du NAT et une gigue variable peuvent compliquer les SLA. Utiliser des classes de SLA dérivées de BFD et le routage basé sur les applications (app-aware routing) pour contraindre le trafic sensible.
• Richesse des politiques centralisées vs opacité du dépannage : Des chaînes de correspondance/action complexes offrent un contrôle granulaire mais peuvent obscurcir la logique de transfert. Maintenir des politiques modulaires, versionnées et bien documentées ; tester dans une fabric de pré-production.
• Sécurité vs performance : L’IPsec obligatoire sur tous les transports renforce la confidentialité mais introduit une surcharge CPU et des considérations de MTU/fragmentation. Préférer l’accélération cryptographique matérielle et un réglage cohérent du MSS/PMTUD.

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

• Politique asymétrique empêchant la formation de tunnels : Valider symétriquement les politiques de TLOC et de contrôle ; confirmer les routes TLOC dans OMP.
• Expirations des trous NAT (pinholes) sur UDP : Préférer le contrôle TLS ou configurer des keepalives NAT ; envisager un NAT statique pour les contrôleurs.
• Mauvaise utilisation des ID de site entraînant l’effondrement des tunnels intra-site : Assurer des ID de site uniques par emplacement physique ; utiliser des politiques de restriction par couleur BFD pour l’intention intra-campus au lieu de forcer la fusion de sites.
• Hubs surchargés par les spokes : Surveiller le CPU/crypto des hubs et le nombre de sessions BFD ; augmenter le nombre de hubs (scale out) ou introduire des hubs régionaux ; utiliser la QoS et les policers pour protéger le trafic de contrôle.

Scénario de problème pratique

Apex Manufacturing étend ses activités sur AWS tout en exploitant 600 agences mondiales sur deux transports (MPLS et DIA). Ils doivent étendre le SD-WAN à AWS avec une latence minimale vers les applications régionales, maintenir la conformité en utilisant TLS pour le contrôle, et assurer la haute disponibilité des contrôleurs.

1. Placer deux orchestrateurs vBond dans l’espace d’adressage IP public et trois contrôleurs vSmart répartis sur deux clouds.

• Justification : vBond doit être joignable publiquement pour faciliter la traversée NAT ; plusieurs instances vSmart assurent la haute disponibilité du plan de contrôle et la proximité géographique. vBond maintient des sessions permanentes avec vSmart et des sessions transitoires avec les WAN Edges, accélérant l’intégration et le rattachement.

2. Convertir toutes les connexions de contrôle en TLS et autoriser le port TCP 12346 à travers les pare-feux de l’entreprise.

• Justification : Le protocole DTLS par défaut peut être bloqué par des équipements intermédiaires (middleboxes) stricts. TLS garantit la joignabilité du plan de contrôle à travers les proxys TCP et les domaines d’inspection sans sacrifier le chiffrement ou l’intégrité.

3. Déployer vManage en tant que cluster à trois nœuds dans une région cloud centrale avec des sauvegardes quotidiennes.

• Justification : Le plan de gestion doit rester disponible pour les opérations de politique, d’image et de télémétrie. Le clustering préserve l’état et met à l’échelle l’accès API/GUI ; les sauvegardes protègent contre la perte de données opérationnelles.

4. Utiliser Cloud OnRamp for IaaS pour instancier des routeurs WAN Edge virtuels dans AWS, un par VPC, dans des sous-réseaux attachés à un transit gateway.

• Justification : Cloud OnRamp automatise la souscription à l’AMI, le déploiement et l’enrôlement des certificats. Les équipements WAN Edge terminent les TLOC SD-WAN et annoncent les routes des VPC via OMP, intégrant les charges de travail cloud dans la fabric avec le même ensemble de politiques.

5. Attribuer des adresses IP système à partir d’un bloc de superposition réservé et des ID de site uniques par région cloud (par ex., 9001–9010), et définir un nom d’organisation cohérent sur toute la fabric.

• Justification : Des adresses IP système et des ID de site uniques empêchent la suppression de tunnels et l’ambiguïté du plan de contrôle. L’uniformité du nom d’organisation est obligatoire pour les adjacences OMP et la confiance des certificats.

6. Configurer le VPN 0 pour les doubles transports dans les edges AWS (internet public et, si disponible, Direct Connect via une couleur privée) et activer BFD avec des classes de SLA pour le routage basé sur les applications (app-aware routing).

• Justification : La diversité des transports améliore la joignabilité et la résistance aux baisses de performance. BFD fournit des métriques de perte/latence/gigue pour orienter le trafic applicatif vers le TLOC le plus performant selon le SLA.

7. Exposer le VPN 512 uniquement aux sous-réseaux de gestion et restreindre le routage vers les contrôleurs via des routes statiques explicites et des ACL.

• Justification : Minimise la surface d’attaque sur le plan de gestion et évite les fuites de routes qui pourraient isoler des équipements ou surexposer les services des contrôleurs.

8. Mettre en œuvre une topologie de hub régional en utilisant les edges AWS comme hubs pour leurs régions respectives, avec deux hubs on-premise par continent pour le basculement, et activer les chemins directs internet de spoke à spoke pour le trafic sensible à la latence.

• Justification : Les hubs régionaux localisent les flux pour réduire la latence et contenir la charge du plan de contrôle ; les doubles hubs assurent la redondance. Les tunnels directs contrôlés de spoke à spoke préservent une faible latence pour les applications en temps réel sans surcharger les hubs.

9. Appliquer des politiques de contrôle centralisées pour sumariser les routes des agences au niveau des hubs régionaux, restreindre les annonces de TLOC aux régions prévues, et imposer la segmentation avec des VPN de service pour le trafic de production, OT et invité.

• Justification : La sumarisation réduit la volatilité des routes OMP (churn) et l’utilisation de la mémoire. Les annonces de TLOC ciblées empêchent la formation de tunnels inter-régionaux non intentionnels. La segmentation basée sur les VPN maintient les frontières de conformité avec des fuites de routes explicites uniquement là où c’est nécessaire.

10. Surveiller la santé de BFD et du plan de contrôle ; configurer des alertes pour la perte d’un vSmart ou d’un vBond et pré-provisionner une capacité N+1.

• Justification : La détection précoce de la dégradation du contrôle prévient une instabilité généralisée. Le N+1 garantit que la fabric peut supporter la défaillance d’un contrôleur sans saturation des sessions, protégeant à la fois la convergence du plan de contrôle et la résilience du plan de données.

Tous les domaines · Intégration des contrôleurs →

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