Cisco 300-415: Intégration des contrôleurs, certificats et connectivité de contrôle sécurisée — 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 utilise un plan de contrôle basé sur des certificats pour intégrer de manière sécurisée les contrôleurs et les périphériques WAN Edge, traverser les frontières NAT et maintenir des connexions de contrôle chiffrées. Une conception correcte du rôle de l’orchestrateur vBond, du cycle de vie des certificats, de l’inventaire des périphériques et de la stratégie NAT garantit une intégration prévisible et un contrôle résilient. Les équipes opérationnelles doivent reconnaître les états et les alarmes des connexions de contrôle et disposer d’un plan de reprise en cas de défaillance des certificats ou de la connectivité.

Orchestration et connectivité de contrôle sécurisée

L’orchestrateur vBond est le premier point de contact du plan de contrôle pour chaque WAN Edge. Il remplit trois fonctions essentielles :

• Contrôle d’admission et d’identité : valide l’identité du périphérique (numéro de série/châssis par rapport à la liste autorisée) et impose la correspondance du nom d’organisation.
• Découverte NAT et rendez-vous : apprend le tuple adresse-port public/privé et le type de NAT de chaque pair, puis informe les deux parties afin qu’elles puissent former des connexions de contrôle directes.
• Échange de connectivité initiale : fournit au WAN Edge les adresses joignables des contrôleurs vSmart et vManage afin qu’il puisse établir des canaux de contrôle persistants.

Propriétés et comportements clés :

• Joignabilité par IP publique : vBond doit résider sur une IP publique (de préférence) ou derrière un NAT statique 1:1 avec des mappages entrants cohérents. Cela garantit qu’il peut être atteint par des périphériques dans des environnements NAT inconnus ou restrictifs.
• Appairage persistant avec les contrôleurs : vBond maintient des connexions permanentes avec les contrôleurs vSmart afin de toujours disposer d’informations de rendez-vous à jour.
• Hors du chemin de données : Après avoir facilité l’échange initial, vBond quitte le flux ; le contrôle continu s’effectue directement entre les WAN Edges et vSmart/vManage.

Transport DTLS/TLS et ports :

• Le protocole par défaut pour les connexions du plan de contrôle est DTLS sur UDP 12346. TLS sur TCP 23456 est disponible et souvent préféré dans les centres de données où l’inspection/proxy TCP est standard.
• vBond utilise le port 12346 par défaut lorsque les certificats de contrôleur sont utilisés et qu’aucun autre port n’est configuré.
• Autoriser le trafic sortant et de retour pour :
  • UDP 12346 (plan de contrôle DTLS)
  • TCP 23456 (plan de contrôle TLS)
• Le NAT-T IPsec du plan de données utilise UDP 4500 et est indépendant des choix du plan de contrôle.

Considérations sur le NAT :

• Les NAT de type full-cone et restricted fonctionnent généralement avec le DTLS hole punching ; le NAT symétrique est le plus problématique. Si les deux extrémités sont derrière un NAT symétrique, utilisez TLS (TCP 23456), modifiez la politique de sortie pour préserver les mappages de ports, ou assurez-vous qu’un côté dispose d’un NAT public/restricted.
• Un vBond derrière un NAT nécessite un mappage statique 1:1 pour le port 12346/UDP (et 23456/TCP si TLS est utilisé). Le PAT dynamique sur vBond n’est pas pris en charge.
• Des liaisons NAT obsolètes peuvent interrompre les tunnels de contrôle. Ajustez les keepalives et assurez la cohérence des interfaces de sortie dans le VPN 0.

Conseils de conception :

• Placer au moins deux instances vBond dans des régions publiques distinctes pour la résilience.
• Préférer TLS dans les environnements avec des contrôles de sortie stricts ou une limitation généralisée de l’UDP ; assurer une posture cohérente entre les contrôleurs et les WAN Edges.

Identité, certificats et validation de l’organisation

Tous les contrôleurs et périphériques WAN Edge doivent présenter des certificats chaînés à la même racine de confiance, et le nom d’organisation (organization-name) doit correspondre sur l’ensemble de l’overlay.

Rôles et sources des certificats :

• Contrôleurs (vManage, vSmart, vBond) : Demandent et installent des certificats de contrôleur signés par la racine choisie (CA d’entreprise ou CA publique). vManage orchestre leur cycle de vie.
• Identité du WAN Edge :
  • Matériel vEdge : livré avec un certificat installé en usine.
  • IOS XE SD-WAN (cEdge) : utilise Cisco SUDI pour l’identité PnP ; obtient ensuite un certificat de contrôleur signé par la même racine que celle utilisée par les contrôleurs.
• Contrôleurs hébergés dans le cloud : Livrés avec des certificats signés par le fournisseur et une chaîne de confiance connue. Les WAN Edges doivent faire confiance à cette chaîne ; des ancres de confiance non concordantes nécessitent la réémission des certificats de contrôle des périphériques pour s’aligner sur la CA du cloud.

Phases du cycle de vie :

• Enrôlement : Les CSR des contrôleurs sont générés dans vManage et signés par la CA sélectionnée ; les WAN Edges s’enrôlent automatiquement pendant le ZTP/PnP ou via un bootstrap manuel.
• Validation : Pendant le handshake, les pairs valident la chaîne de certificats, la date d’expiration, l’état de révocation (si configuré) et le nom d’organisation (organization-name).
• Renouvellement et révocation : vManage surveille l’expiration et peut renouveler. Les certificats des périphériques compromis ou retirés doivent être révoqués ; retirez-les de la liste des numéros de série autorisés pour empêcher toute nouvelle jonction.

Échecs de validation courants :

• Non-concordance du nom d’organisation : Les connexions de contrôle échouent ; l’état indique une non-concordance de l’organisation ou un certificat non vérifié.
• Chaînes de confiance mixtes : Les contrôleurs et les edges signés par des racines différentes ne peuvent pas former de sessions de contrôle.
• Désynchronisation temporelle : Les certificats apparaissent comme non encore valides ou expirés ; NTP dans le VPN 0 est obligatoire.
• Problèmes de FQDN/SAN (TLS) : Si TLS est appliqué et que la validation du FQDN est activée, les non-concordances de SAN/CN entraîneront l’échec de la connexion.

Intégration des appareils, PnP/ZTP et contrôles d’inventaire

L’intégration est la combinaison de la validation de l’identité de l’appareil, du provisioning sans intervention (zero-touch provisioning) et de la connectivité de contrôle automatique basée sur des certificats.

Inventaire et autorisation :

• Liste des numéros de série autorisés : vManage stocke la liste des appareils WAN Edge autorisés. Remplissez-la via la synchronisation du Smart Account ou en téléversant manuellement le fichier des numéros de série autorisés dans vManage lorsque la synchronisation du Smart Account n’est pas utilisée.
• Numéro de série vs. numéro de châssis : Les deux sont utilisés pour identifier de manière unique et empêcher l’usurpation (spoofing). Des jetons (tokens) pour vEdge peuvent être requis lors de l’intégration manuelle.

Flux zero-touch :

• ZTP vEdge : L’appareil utilise un profil d’usine pour atteindre le service ZTP, découvre l’orchestrateur vBond et initie une connexion DTLS/TLS vers vBond pour la vérification d’identité et le rendez-vous. Il établit ensuite des connexions de contrôle compatibles OMP avec vSmart et une connectivité de gestion vers vManage.
• PnP pour IOS XE SD-WAN (cEdge) : L’appareil utilise SUDI pour s’authentifier auprès de Cisco Plug and Play via HTTPS, qui renvoie les informations d’accessibilité du contrôleur. Alternativement, le PnP sur site (on-prem) via l’option DHCP 43/DNS ou un bootstrap USB de jour zéro (day-0) peut être utilisé. Après l’admission par vBond, l’appareil est redirigé vers vManage pour l’attachement du modèle (template).
• Une fois les connexions de contrôle établies, vManage pousse les modèles (templates), et vSmart commence le peering OMP pour distribuer les routes, les politiques et les clés de chiffrement.

Points de contrôle opérationnels :

• Assurez-vous que le organization-name dans la configuration système correspond exactement à celui de l’overlay.
• Vérifiez le routage IP du VPN 0, le DNS (si des FQDN sont utilisés) et le NTP.
• Ouvrez les ports requis vers vBond/vSmart/vManage et autorisez les flux de retour.

Une désignation vBond minimale sur l’orchestrateur :

system
 vbond 203.0.113.10 local
 organization MyCompany

Opérations : États, Alarmes, Vérification et Récupération

Contrôler les états de connexion et les alarmes :

• États typiques : down, connecting/handshake, authenticated, up. Les échecs peuvent indiquer une erreur de certificat, une non-concordance d’organisation, une absence de réponse ou un échec NAT.
• Les alarmes vManage courantes incluent : Control Connection Down, OMP Peer Down, Certificate Expiring/Expired, Device Not in Authorized List et Organization Mismatch.

Commandes de vérification (IOS XE SD-WAN) :

show sdwan control connections
show sdwan control local-properties
show sdwan omp peers
show sdwan certificate status
show sdwan software

Commandes de vérification (vEdge) :

show control connections
show control local-properties
show omp peers
show certificate installed

Flux de travail de dépannage et de récupération :

• Identité et nom d’organisation (org-name) :
  • Confirmer que l’équipement apparaît dans l’inventaire vManage avec le bon numéro de série/châssis.
  • Vérifier le system organization-name sur tous les nœuds.
• Heure et confiance :
  • Assurer la joignabilité NTP dans le VPN 0 ; revérifier les dates de validité des certificats.
  • Valider la chaîne de certificats sur les contrôleurs et les équipements Edge ; réémettre si les racines diffèrent.
• Connectivité et NAT :
  • Confirmer la joignabilité du vBond sur les ports UDP 12346 et TCP 23456 depuis la sortie (egress) du WAN Edge.
  • Si un NAT symétrique empêche le DTLS, forcer le TLS ou ajuster la politique de sortie pour épingler les mappages sortants.
• Ré-enrôlement et renouvellement :
  • Si le certificat d’un équipement est corrompu/expiré, le révoquer dans vManage, le retirer de la liste autorisée, le rajouter et déclencher un ré-enrôlement (PnP/ZTP ou installation manuelle).
  • Pour les migrations hébergées dans le cloud, aligner les ancres de confiance (trust anchors) en réémettant les certificats des contrôleurs et des WAN Edge auprès de l’AC cloud, puis redémarrer les connexions de contrôle.
• Hygiène opérationnelle :
  • Maintenir les clusters de contrôleurs en bonne santé (par ex., cluster vManage pour la mise à l’échelle).
  • Maintenir un DNS cohérent pour l’adressage des contrôleurs basé sur les FQDN ; mettre à jour les SAN lors du renommage ou du changement d’IP des contrôleurs.

Compromis liés au NAT et aux ports :

• Le DTLS (UDP) offre une surcharge plus faible et souvent de meilleures performances, mais il est sensible à la limitation de débit UDP et au NAT symétrique. Le TLS (TCP) facilite la traversée des pare-feux stricts au détriment d’un potentiel blocage en tête de ligne (head-of-line blocking).
• Le vBond doit rester hautement joignable ; compromettre sa joignabilité publique ou ses mappages entrants est une cause fréquente des échecs d’intégration (onboarding).

Scénario de Problème Pratique

Acme Retail Corp. intègre 600 agences, dont beaucoup se trouvent derrière des NAT symétriques gérés par des FAI, à une nouvelle fabric Cisco SD-WAN. Les premiers pilotes montrent un établissement intermittent du plan de contrôle et des échecs DTLS fréquents.

Approche :

1. Déployer des orchestrateurs vBond publics redondants

   • Justification : Placer deux instances vBond sur des adresses IP publiques distinctes (régions/FAI séparés) maximise la joignabilité initiale et accélère la découverte du NAT. L’adressage public évite l’ambiguïté introduite par les NAT des fournisseurs et prend en charge un trafic de retour prévisible.

2. Forcer le TLS pour le plan de contrôle dans les régions à forte présence de NAT

   • Justification : Les agences avec des NAT symétriques ont des difficultés avec le « UDP hole punching ». Le TLS sur TCP 23456 assure une traversée stable à travers les pare-feux stateful et les CGN des FAI, réduisant les instabilités (flaps) liées au DTLS sans impacter l’OMP ou la distribution des clés.

3. Standardiser le nom d’organisation (organization-name) et les ancres de confiance des contrôleurs

   • Justification : Aligner tous les contrôleurs et les WAN Edges sur la même AC racine (PKI d’entreprise choisie par Acme). Configurer le system organization-name de manière identique sur vManage, vSmart, vBond et tous les modèles d’équipement pour éviter les rejets pour non-concordance d’organisation.

4. Précharger la liste des numéros de série autorisés dans vManage et automatiser le PnP/ZTP

   • Justification : Importer l’inventaire complet des équipements via la synchronisation du Smart Account pour s’assurer que chaque équipement passe les contrôles d’identité au niveau du vBond. Pour les cEdge, utiliser Cisco PnP avec SUDI ; pour le matériel vEdge, s’assurer que les jetons (tokens) et les numéros de série sont présents. Cela élimine les erreurs manuelles et accélère la mise en service.

5. Renforcer la joignabilité et la synchronisation horaire du VPN 0

   • Justification : Définir des routes par défaut/DNS cohérents dans le VPN 0 et pointer le NTP vers des serveurs publics ou d’entreprise joignables depuis chaque agence. Une heure correcte empêche les erreurs de certificat « pas encore valide/expiré » qui bloquent les handshakes TLS.

6. Normaliser les règles de pare-feu et le comportement du NAT

   • Justification : Publier une politique de sortie d’agence autorisant le trafic sortant TCP 23456 et UDP 12346 vers les adresses IP des vBond/vSmart/vManage avec des mappages de longue durée. Là où le FAI impose un NAT symétrique, s’assurer qu’au moins un chemin vers un contrôleur prend en charge la traversée TCP.

7. Instrumenter les opérations avec des vérifications et des alarmes ciblées

   • Justification : Intégrer les vérifications « show sdwan control connections » et « show sdwan certificate status » dans le script du Jour 1. Dans vManage, s’abonner aux alarmes Control Connection Down et Certificate Expiring. Cela permet de faire remonter rapidement les sites mal configurés et de signaler les renouvellements avant leur expiration.

8. Établir un guide de récupération (runbook) pour les pannes de certificat ou de connectivité

   • Justification : Définir les étapes pour révoquer/réémettre les certificats d’équipement dans vManage, re-télécharger les numéros de série si nécessaire, et basculer entre DTLS/TLS comme mesure d’atténuation. Inclure des procédures pour la rotation des certificats de contrôleur sans impact sur le service et pour basculer entre les instances vBond. Cela minimise le MTTR pendant les déploiements de pointe.

En combinant un vBond joignable publiquement, un plan de contrôle TLS là où le NAT est restrictif, une gestion rigoureuse des identités et des garde-fous opérationnels, Acme Retail parvient à un onboarding déterministe à grande échelle tout en préservant la sécurité et la résilience du plan de contrôle SD-WAN.

← Architecture et plans de la fabric Cisco SD-WAN · Tous les domaines · OMP →

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