Cisco 300-415: Opérations, surveillance et dépannage — 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.

Vue d’ensemble

Les opérations, la surveillance et le dépannage dans Cisco SD-WAN s’articulent autour de Cisco SD-WAN Manager (anciennement vManage), de la couche de contrôleurs (l’orchestrateur vBond et les contrôleurs vSmart), des routeurs WAN Edge (par ex., les séries ISR 4000 et ASR 1000 exécutant IOS XE SD-WAN), et des overlays de données et de contrôle qu’ils forment. Le plan de contrôle, piloté par vSmart, construit et maintient la topologie et les politiques via OMP et distribue les clés de chiffrement entre les routeurs Edge. Les équipements WAN Edge forment par défaut des connexions de contrôle DTLS (ou TLS si requis), coordonnent la connectivité initiale via vBond (qui doit être joignable dans l’espace d’adressage IP public pour la traversée NAT) et établissent des tunnels IPsec pour le plan de données. Une hygiène opérationnelle rigoureuse utilise une télémétrie riche, des runbooks définis, un contrôle des changements et des API automatisées pour maintenir l’assurance des SLA et réduire le temps moyen de réparation.

Surveillance, tableaux de bord et santé

• Tableaux de bord : Cisco SD-WAN Manager fournit des vues en temps réel et historiques sur la santé des sites, l’état des équipements, les connexions de contrôle, les SLA des tunnels, l’expérience applicative et la conformité des politiques. Les widgets par défaut mettent en évidence les connexions de contrôle (joignabilité de vBond/vSmart/vManage), le respect des SLA du routage applicatif (app-aware routing) et l’utilisation des interfaces. Les vues détaillées (drill-downs) corrèlent les alarmes, les événements et les statistiques par équipement ou par site.
• Alarmes et événements : La plateforme génère des alarmes sur les changements de joignabilité des contrôleurs, l’état des sessions OMP, les échecs de certificat, les redémarrages d’équipements, les non-concordances de politiques et la dégradation des performances (perte/latence/gigue au-delà des SLA). Les événements incluent des codes détaillés tels que DCONFAIL pour les échecs de connexion de contrôle et les non-concordances explicites de nom d’organisation (organization-name) lors de l’intégration. Les alarmes prennent en charge l’acquittement, la suppression et la transmission (e-mail/SNMP/syslog) vers les systèmes d’opérations centralisés.
• Santé des équipements : Les scores de santé combinent des indicateurs du plan de contrôle et du plan de données avec l’utilisation du CPU, de la mémoire, les journaux de crash et les erreurs d’interface. La santé des WAN Edge doit faire l’objet d’une analyse de référence (baseline) ; les seuils doivent être ajustés pour éviter la fatigue liée aux alarmes. La synchronisation temporelle (NTP) est essentielle ; un décalage d’horloge (clock skew) est une cause fréquente d’échecs de validation de certificat et de données de tendance trompeuses.
• vAnalytics et planification de la capacité : vAnalytics ajoute une visibilité applicative approfondie (classification basée sur NBAR2 à partir de cflowd), des lignes de base pour la qualité des chemins et des prévisions de capacité. Il met en évidence les principaux émetteurs (top talkers), les contributions au temps de réponse des applications (réseau contre serveur) et les fenêtres de saturation d’interface prévues. Pour la planification de la capacité, utilisez le débit du 95e centile sur des fenêtres glissantes de 30 jours et corrélez-le avec les violations de SLA des tunnels ; évaluez où une bande passante supplémentaire ou des ajustements de politique (QoS/AAR) offrent le meilleur retour sur les SLA.
• Expérience applicative : Les tableaux de bord applicatifs lient les flux aux performances des tunnels et au traitement QoS. Si une application critique sous-performe sur un chemin avec une gigue croissante, confirmez si le routage applicatif (app-aware routing) respecte le SLA et si les politiques de mise en file d’attente (queueing) sont alignées avec les marquages DSCP de bout en bout.

Télémétrie, Syslog, SNMP et export cflowd

• Télémétrie en streaming : Cisco SD-WAN Manager consomme la télémétrie pilotée par modèle (model-driven telemetry) des contrôleurs et des routeurs Edge pour les métriques de contrôle, d’interface et de plateforme. Le streaming réduit la surcharge liée à l’interrogation (polling) et augmente la granularité par rapport à l’interrogation SNMP traditionnelle. Pour les analyses externes, IOS XE SD-WAN prend en charge la télémétrie pilotée par modèle en mode dial-out vers des collecteurs gRPC ; dimensionnez soigneusement les collecteurs et les taux d’échantillonnage pour éviter toute surcharge sur les sites distants (branches).
• Syslog : Les routeurs Edge et les contrôleurs peuvent exporter les journaux syslog vers des collecteurs centralisés. Transmettez les événements importants (par ex., reconvergence du contrôle, mises à jour des politiques OMP, renouvellement des clés IPsec, crashs). Utilisez le syslog structuré pour une meilleure analyse (parsing). Limitez le débit et filtrez pour maintenir les performances des collecteurs.
• SNMP : Utilisez SNMPv3 pour l’interrogation sécurisée des interfaces, du CPU, de la mémoire et des capteurs environnementaux. Les traps SNMP peuvent être activés pour les alarmes clés (contrôle indisponible, BFD indisponible, CPU élevé). SNMP seul est insuffisant pour la télémétrie applicative moderne mais reste précieux pour l’intégration avec les outils NMS existants.
• cflowd (export de flux applicatif) : Cisco SD-WAN utilise cflowd (similaire à NetFlow/IPFIX) pour exporter des enregistrements par flux incluant l’ID de l’application (NBAR2), le DSCP, les octets/paquets, les flags TCP et des métadonnées de performance telles que le temps d’aller-retour (round-trip time), la perte et la gigue. L’export peut être dirigé vers Cisco SD-WAN Manager/vAnalytics et vers des collecteurs externes. Équilibrez la visibilité et la surcharge en ajustant l’échantillonnage, les délais d’expiration actif/inactif et les destinations d’export. Un export excessif sur les plateformes bas de gamme peut impacter le CPU ; préférez les analyses côté contrôleur lorsque cela est possible.

Dépannage du contrôle, d’OMP, de BFD et des tunnels

Un flux de travail cohérent permet de réduire rapidement le domaine de panne :

1. Établir la portée et la couche

• S’agit-il uniquement du plan de contrôle, du plan de données ou de la couche applicative ?
• Utilisez les tableaux de bord des sites et des appareils de SD-WAN Manager pour voir si plusieurs appareils, sites ou un seul chemin/couleur sont affectés.

2. Valider les connexions de contrôle

• vBond doit être joignable sur son IP publique ; par défaut, les contrôleurs utilisent le port 12346 pour DTLS/TLS.
• Le transport de contrôle par défaut est DTLS ; de nombreuses politiques de data center exigent TLS vers les contrôleurs. Assurez-vous que les boîtiers intermédiaires (middleboxes) autorisent le protocole sélectionné.
• Vérifiez la synchronisation de l’heure et les certificats (chaîne racine, validité, joignabilité CRL/OCSP).
• Erreurs courantes :
  • DCONFAIL : Échec générique de la connexion de contrôle ; les causes profondes incluent le port 12346 bloqué, l’échec de la traversée NAT, le rejet de certificat ou le routage vers les contrôleurs.
  • Incompatibilité d’organisation : L’org-name intégré dans les informations d’identification/configuration de l’appareil doit correspondre à celui des contrôleurs ; sinon, les sessions OMP ne se formeront pas.

3. Vérifier OMP et la politique

• OMP transporte les routes, les TLOC et les chaînes de services (service-chains) entre vSmart et les routeurs edge. Confirmez l’adjacence OMP avec tous les nœuds vSmart du cluster pour éviter un état de contrôle asymétrique.
• Validez les routes reçues/annoncées et l’acceptation par la politique. Une politique peut filtrer par inadvertance des TLOC ou des préfixes, créant un trou noir (blackholing) pour le trafic.
• Les TLOC sont définis par l’IP système, la couleur et l’encapsulation (GRE ou IPsec). Des incompatibilités de couleur ou d’encapsulation entre les pairs empêchent la formation du tunnel sur un transport donné.

4. Inspecter BFD et le SLA

• BFD suit la perte, la latence et la gigue par tunnel et alimente le routage applicatif (app-aware routing). Un battement (flapping) ou une gigue élevée déclenche une redirection (steering). Confirmez que les temporisateurs BFD/classes de SLA correspondent à l’intention de conception. Des temporisateurs trop agressifs sur des circuits de faible qualité entraînent des basculements inutiles.

5. Vérifier IPsec/le plan de données

• Inspectez les statistiques du tunnel, les SA IPsec, les encaps/decaps, les rejets pour rejeu (replay-drops) et la PMTU. Les problèmes de NAT-T et les trous noirs PMTU sont courants, en particulier sur les connexions à large bande (broadband).
• Validez que la mise en forme QoS (shaping) correspond à la bande passante contractuelle ; la sursouscription gonfle les mesures de perte/gigue et induit AAR en erreur.

Commandes show utiles sur les routeurs edge IOS XE SD-WAN :

show sdwan control connections
show sdwan omp peers | routes | tlocs
show sdwan bfd sessions
show sdwan ipsec inbound-connections outbound-connections
show platform hardware qfp active datapath utilization
show interfaces counters errors
show clock detail

Compromis et modes de défaillance :

• TLS vs DTLS : TLS peut être requis par la politique de sécurité et mieux traverser les proxys stricts ; DTLS offre une surcharge de négociation (handshake) plus faible. Choisissez de manière cohérente sur l’ensemble de la fabric.
• Sensibilité de BFD : Des temporisateurs serrés améliorent le temps de réaction mais augmentent l’utilisation du CPU et les faux positifs sur les liaisons bruitées.
• Complexité de la politique : Des politiques centralisées riches peuvent dévier de l’intention initiale ; préférez des objets de politique hiérarchiques et bien commentés, et simulez avant de déployer.

Gestion du cycle de vie, conformité et automatisation

• Planification de la mise à niveau logicielle :

  • Séquence : Mettez à niveau le cluster SD-WAN Manager, puis vBond, puis vSmart, et enfin les WAN Edges. Maintenez la compatibilité des versions conformément aux notes de version. Les contrôleurs doivent être sains et synchronisés avant d’intervenir sur les edges.
  • Référentiels d’images : Utilisez le référentiel de logiciels de SD-WAN Manager pour préparer les images. Les images des contrôleurs utilisent généralement les formats .qcow2 ou .ova ; les edges utilisent des paquets IOS XE SD-WAN spécifiques à la plateforme.
  • Mode maintenance : Placez le WAN Edge en mode maintenance pour drainer le trafic en douceur. L’équipement retire les routes TLOCs/OMP afin que les sessions migrent vers des chemins/sites alternatifs avant le redémarrage, minimisant ainsi l’impact sur l’utilisateur.
  • Restauration (Rollback) : Conservez une image précédente éprouvée en préparation. Si les vérifications post-intervention échouent, revenez à la dernière bonne configuration connue. IOS XE SD-WAN prend en charge les installations dual-bank et la rétrogradation pilotée par le contrôleur.
  • Planification : Utilisez des fenêtres de maintenance avec des vérifications préalables (état control/OMP/BFD, CPU/mémoire) et des vérifications post-intervention (SLA des applications, nombre de tunnels, taux d’erreurs).

• Conformité et dérive de la configuration :

  • L’état désiré est défini par les modèles de périphériques (device templates). SD-WAN Manager met en évidence la dérive entre la configuration en cours et le modèle ; remédiez-y avec des workflows de rattachement (reattach) ou d’acceptation de la dérive lorsque cela est justifié (par ex., un correctif d’urgence en CLI).
  • Les pistes d’audit enregistrent qui a changé quoi et quand (portée définie par le RBAC). Associez-les à un SIEM externe via syslog/webhooks pour un historique immuable.
  • Ensembles de règles de conformité : Validez que le nom de l’organisation (org-name), le schéma d’adressage IP système, l’utilisation des couleurs, les chiffrements IPsec, l’AAA et le NTP sont conformes aux standards.

• Opérations et reporting pilotés par API :

  • Les API REST /dataservice exposent des points de terminaison (endpoints) de surveillance, de configuration et d’action. Automatisez la génération de rapports (tendances SLA, applications principales), les mises à niveau de masse, l’intégration de sites et les contrôles de conformité.
  • Utilisez des jetons (tokens) et des comptes à portée RBAC. Mettez en œuvre des workflows idempotents et des validations préalables (pre-flight) avant d’appliquer des changements à grande échelle.

• Diagnostic des performances :

  • Commencez par le SLA du tunnel (perte, latence, gigue), puis le CPU/mémoire du périphérique, puis les rejets/erreurs d’interface et la profondeur des files d’attente. Corrélez avec les indicateurs de performance clés (KPIs) des applications provenant de cflowd.
  • Identifiez si la dégradation est liée à la qualité de la liaison, à la congestion/QoS ou au côté serveur en comparant l’expérience de plusieurs sites pour la même application et le même chemin.
  • Signaux de capacité : Une utilisation au 95e percentile en hausse, des rejets de file d’attente dans les classes prioritaires et des basculements de chemin fréquents par AAR indiquent la nécessité de modifier la politique ou la bande passante.

• Réponse aux incidents, contrôle des changements et RCA :

  • Les guides opérationnels (runbooks) définissent les premières actions de réponse : capturer les états control/OMP/BFD, collecter les journaux/fichiers de support technique pertinents et geler les changements non essentiels.
  • Le contrôle des changements impose une revue par les pairs pour les mises à jour de politiques et des déploiements progressifs avec des canaris.
  • L’analyse des causes profondes (RCA) combine les événements du contrôleur (qui/quand), la télémétrie des flux (quel trafic) et les métriques de chemin (où la dégradation a lieu) pour isoler le problème. Exemples : non-concordance de l’ORG après un changement d’intégration, un filtre de politique non intentionnel supprimant un TLOC, un trou noir PMTU sur la liaison broadband après un changement de CPE chez le FAI.

Scénario de problème pratique

Contoso Health exploite 150 cliniques connectées via un SD-WAN à double transport (couleur MPLS mpls et couleur broadband biz-internet) utilisant des WAN Edges ISR 4000. Après une fenêtre de maintenance pour migrer les contrôleurs vers un nouveau centre de données, plusieurs sites signalent de mauvaises performances EHR et des pannes intermittentes.

1. Vérifier la santé du plan de contrôle dans SD-WAN Manager

• Justification : Si le plan de contrôle est instable, tous les symptômes en aval sur le plan de données et les politiques s’ensuivent. Le tableau de bord affiche plusieurs événements DCONFAIL et des non-concordances d’ORG pendant la même fenêtre, indiquant des incohérences d’intégration après le déplacement du contrôleur.

2. Valider la joignabilité et les ports du contrôleur

• Justification : Le nouveau centre de données impose le TLS vers les contrôleurs. Confirmez que les équipements intermédiaires (middleboxes) autorisent le TLS vers les contrôleurs sur le port de contrôle par défaut 12346 et que vBond est joignable en IP publique pour la traversée NAT. Un port bloqué sur un pare-feu régional explique les défaillances de sites regroupés.

3. Corriger la non-concordance du nom d’organisation (organization-name)

• Justification : Les edges qui échouent à l’authentification mutuelle avec les contrôleurs en raison d’une non-concordance de l’org-name ne peuvent pas former d’OMP. Comparez l’org-name du modèle de périphérique avec les certificats du contrôleur ; mettez à jour les modèles pour qu’ils correspondent et rattachez-les. Cela restaure l’adjacence OMP avec vSmart pour les sites concernés.

4. Réconcilier l’heure et les certificats

• Justification : Le déménagement du DC a modifié la joignabilité NTP. Des horloges désynchronisées ont provoqué l’échec de certaines validations de certificats. Pointez tous les edges et contrôleurs vers un NTP redondant et vérifiez la convergence des horloges pour stabiliser l’authentification et les sessions de contrôle.

5. Vérifier les routes OMP, les TLOCs et l’acceptation des politiques

• Justification : La migration du contrôleur incluait une refonte des politiques. Utilisez show sdwan omp routes/tlocs et la visualisation des politiques pour confirmer que les préfixes critiques et tous les TLOCs sont appris et non filtrés. Une politique de données mal ordonnée rejetait le trafic du serveur EHR ; réordonnez et validez (commit) pour restaurer la joignabilité.

6. Évaluer le comportement de BFD/SLA et d’AAR

• Justification : La lenteur de l’EHR peut refléter la qualité du chemin. BFD montre une gigue croissante sur la liaison broadband ; AAR bascule constamment entre les chemins. Augmentez l’hystérésis dans la classe SLA et assurez-vous que la QoS priorise les flux EHR en fonction du DSCP. Cela réduit les changements de chemin inutiles.

7. Effectuer une mise à niveau logicielle ciblée avec le mode maintenance

• Justification : Un bug connu dans la version actuelle d’IOS XE SD-WAN signale par intermittence une gigue incorrecte sur biz-internet. Préparez le correctif recommandé dans le référentiel de logiciels. Mettez un sous-ensemble d’edges en mode maintenance, mettez-les à niveau, validez les vérifications post-intervention, puis déployez à plus grande échelle. Conservez l’image de restauration en préparation.

8. Automatiser la vérification et le reporting via l’API

• Justification : Utilisez les API /dataservice pour exporter les rapports post-incident sur le respect des SLA, les performances des applications et la stabilité du contrôle pour toutes les cliniques. L’automatisation garantit une vérification cohérente et génère un enregistrement auditable pour le contrôle des changements.

9. Documenter la RCA et renforcer les contrôles

• Justification : Les causes profondes étaient une omission de règle de pare-feu sur le port de contrôle 12346, une dérive de l’org-name dans les modèles et une mauvaise configuration NTP, aggravées par un problème d’ordre dans les politiques. Mettez à jour les guides opérationnels d’intégration, imposez une validation pré-changement basée sur l’API (joignabilité du contrôleur, vérifications de l’org-name, état NTP) et exigez des simulations de politique avant la validation (commit) pour éviter que cela ne se reproduise.

← Intégration Cloud · Tous les domaines

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