Cisco 300-415: Configuration des WAN Edge et gestion des modèles — 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

Cisco SD-WAN Manager (anciennement vManage) centralise l’intention, la configuration, la conformité et les opérations de cycle de vie pour les périphériques WAN Edge, tandis que vBond Orchestrator gère l’intégration des périphériques et que les contrôleurs vSmart exécutent le plan de contrôle de la superposition (overlay) à l’aide d’OMP. Dans les conceptions de production, la configuration basée sur des modèles (templates) est l’outil principal pour garantir l’exactitude et la répétabilité sur des centaines ou des milliers de WAN Edges, tout en permettant des valeurs spécifiques aux périphériques et des exceptions sécurisées. Cette section explique les constructions de modèles, le flux de travail du cycle de vie, les fonctions clés des modèles de fonctionnalités, les groupes de configuration modernes par rapport aux modèles de périphériques hérités, la gestion de la conformité et des dérives, l’utilisation de l’API, la gestion des images logicielles et les garde-fous de changement utilisés pour exploiter la fabric Cisco SD-WAN à grande échelle.

Constructions de modèles et réutilisation

• Modèles de fonctionnalités (Feature templates)
  • Intention atomique pour un domaine fonctionnel tel que Système, VPN, Interface VPN, Tunnels (TLOC/Transport), OMP, BGP/OSPF, QoS, NAT/ACL, Sécurité (zones, identités, IPS/URL), SNMP, Syslog, NTP, Hébergement d’applications (App-hosting), Cellulaire/LTE.
  • Chaque champ peut être défini sur une valeur fixe ou sur une variable spécifique au périphérique, permettant une large réutilisation.
• Modèles de périphériques (modèle hérité)
  • Un composite de modèles de fonctionnalités lié à un périphérique. L’attachement d’un périphérique nécessite de fournir toutes les variables spécifiques au périphérique (par exemple, l’adresse IP du système, l’ID du site, le nom d’hôte, les adresses d’interface).
  • Avantages : séparation claire des préoccupations ; réutilisation facile des modèles de fonctionnalités matures. Inconvénients : déploiements (pushes) sur l’ensemble du périphérique pour des changements mineurs ; prolifération de nombreux modèles de périphériques à mesure que les exceptions s’accumulent.
• Groupes de configuration (modèle moderne)
  • Un package de configuration hiérarchique qui correspond étroitement à l’arborescence de configuration du périphérique et prend en charge la portée (scoping) des variables et les mises à jour partielles par section.
  • Avantages : moins de constructions à gérer, déploiements ciblés au niveau de la section, gestion des exceptions plus simple, visualisation plus facile de la configuration effective. Inconvénients : nécessite des versions récentes de SD-WAN Manager ; les équipes habituées aux modèles de périphériques peuvent avoir besoin d’un plan de migration.
• Variables et valeurs spécifiques aux périphériques
  • Utilisez des variables pour l’identité (IP système, ID de site), l’adressage de la sous-couche (underlay) (interfaces VPN 0), les bouclages (loopbacks)/extensions TLOC, et les identifiants liés à l’inventaire (numéro de série, châssis).
  • Limitez les types de variables (IP, entier, énumération) et utilisez des valeurs par défaut lorsque cela est sûr. Les modes d’échec de la validation incluent les variables manquantes, les non-concordances de type ou les valeurs qui entrent en conflit avec des champs globalement uniques (par exemple, une IP système dupliquée).
• Stratégie de réutilisation
  • Créez un petit ensemble de modèles de fonctionnalités « de référence » (golden) par rôle de périphérique (agence, petite agence, hub, centre de données, périphérie cloud) et par type de transport (MPLS, haut débit, LTE).
  • Paramétrez les valeurs par site à l’aide de variables. Séparez les modèles pour isoler les fonctionnalités à forte volatilité (QoS, Sécurité, NAT) des fonctionnalités statiques (Système, OMP) afin de minimiser le rayon d’impact (blast radius) lors d’un changement.

Cycle de vie, conformité et flux de déploiement

• Conception et création
  • Définissez des modèles de fonctionnalités ou des groupes de configuration ; marquez les champs spécifiques aux périphériques comme des variables.
  • Importez ou vérifiez l’inventaire des périphériques, les certificats et le nom de l’organisation dans SD-WAN Manager. vManage stocke les configurations des périphériques et les inventaires de certificats associés.
• Attachement et validation
  • Associez les périphériques à un modèle de périphérique ou à un groupe de configuration ; remplissez les valeurs des variables (l’importation CSV ou l’API est courante à grande échelle).
  • Utilisez l’aperçu de la configuration pour comparer la configuration candidate rendue avec les standards prévus. La validation détecte les configurations qui se chevauchent (par exemple, une interface définie deux fois) ou les valeurs hors plage.
• Flux de déploiement
  • SD-WAN Manager compile la configuration candidate et utilise NETCONF pour la livrer au WAN Edge. Lors de l’intégration initiale, les modèles Système et VPN 0 garantissent la formation des connexions de contrôle : les WAN Edges établissent des connexions DTLS/TLS vers vSmart et, une fois les politiques et les TLOC échangés via OMP, des tunnels IPsec se forment vers d’autres WAN Edges. vBond orchestre l’échange de connectivité initial.
  • L’état de pré-production (staging) peut être utilisé pour autoriser les connexions de contrôle sans les tunnels du plan de données, pour une préparation contrôlée avant la mise en service.
• Conformité et dérive
  • Les vérifications de conformité comparent la configuration souhaitée (rendue à partir du modèle) à la configuration en cours d’exécution et signalent les dérives dues à des changements hors bande ou à des validations (commits) échouées/partielles.
  • Les options de remédiation incluent le redéploiement (re-pushing) de la configuration souhaitée, la réconciliation des exceptions autorisées dans les modèles, ou le lancement d’une restauration (rollback).
• Restauration (Rollback)
  • SD-WAN Manager archive les versions de configuration avec des ID de tâche (job IDs). Effectuez une restauration en rattachant une version antérieure du modèle ou en utilisant l’archive de configuration pour restaurer le dernier ensemble fonctionnel connu. Les restaurations sont atomiques par section lors de l’utilisation de groupes de configuration, ce qui réduit les risques.

Fonctions des modèles, exceptions et substitutions sécurisées

• Modèle système
  • Identité (nom d’hôte, IP système, ID de site), nom de l’organisation, adresses des contrôleurs, journalisation, NTP, AAA.
  • Modes de défaillance : une IP système/un ID de site en double, un nom d’organisation erroné ou des adresses de contrôleur incorrectes empêchent la formation du plan de contrôle. Dans les scénarios avec un vBond joignable publiquement sur l’interface WAN, l’option vBond « local » est utilisée pour privilégier l’adresse routable de l’équipement lors de la découverte.
• Modèles VPN
  • Transports underlay du VPN 0 pour le contrôle/les données ; VPN de service pour la segmentation du trafic utilisateur. Inclure les paramètres de routage (statique, BGP/OSPF), NAT, DHCP et DNS selon les besoins.
  • Modes de défaillance : une interface mal assignée à un mauvais VPN, l’absence de surcharge NAT (overload) ou des conflits DHCP provoquant des problèmes de joignabilité. N’oubliez pas que le VPN 0 transporte le trafic de contrôle.
• Modèles d’interface et de tunnel (TLOC)
  • Interfaces physiques/logiques, couleurs, encapsulations (IPsec ou GRE), extensions TLOC et temporisateurs BFD/hello.
  • Un TLOC est défini de manière unique par l’encapsulation, la couleur et l’IP système. Des combinaisons de couleur/encapsulation conflictuelles entre les transports peuvent bloquer le trafic ou produire des chemins asymétriques.
• Modèle OMP
  • Paramètres des pairs vers vSmart, types de routes (OMP, BGP, connectées, statiques), annonce/redistribution, temporisateurs, redémarrage en douceur (graceful restart) et préparation à l’insertion de services overlay.
  • Une redistribution trop large peut entraîner une fuite de routes entre les VPN ou dans l’underlay ; limitez-la soigneusement avec des politiques.
• Modèles de sécurité
  • Pare-feu basé sur les zones, IDS/IPS, filtrage d’URL, AMP, règles tenant compte des VPN. L’ordre des opérations est important ; confirmez la précédence et les refus implicites.
  • Surveillez la compatibilité des versions de fonctionnalités ; certaines fonctionnalités de sécurité nécessitent des versions spécifiques d’IOS XE SD-WAN.
• Modèles d’ajout CLI et exceptions sécurisées
  • Utilisez les ajouts CLI pour appliquer des commandes non encore modélisées dans les modèles de fonctionnalités, de préférence dans des domaines opérationnellement sûrs : télémétrie, objets SNMP, bannières, spécificités de journalisation, ajustements d’hébergement d’applications (app-hosting) ou réglages matériels de la plateforme qui ne chevauchent pas les sections gérées par les modèles.
  • Évitez les ajouts CLI qui touchent à l’identité (système, ID de site), à OMP, à l’adressage des interfaces, au transport du VPN 0 ou aux paramètres IPsec/TLOC déjà gérés par les modèles ; une configuration qui se chevauche pourrait être supprimée lors du prochain envoi de modèle ou provoquer des échecs de validation (commit).

Exemple d’ajout CLI (IOS XE SD-WAN) pour la télémétrie opérationnelle qui ne se chevauche pas avec les modèles :

logging buffered 100000 warnings
service timestamps debug datetime msec
snmp-server contact NOC noc@example.local
snmp-server location DC1-Rack12

API, gestion des images et garde-fous de modification

• API NETCONF et REST
  • SD-WAN Manager programme les appareils via NETCONF/YANG. En northbound, ses API REST (/dataservice) prennent en charge la gestion CRUD des modèles, le remplissage des variables, l’attachement, la validation, le déploiement, les opérations sur les images logicielles et le suivi des tâches (jobs).
  • Bonnes pratiques : utiliser des workflows idempotents, capturer les jetons CSRF et les cookies de session, respecter les limites de débit des API (rate limits) et considérer les ID de tâche (job IDs) comme votre source de vérité pour les résultats de déploiement.
• Images logicielles et mises à niveau des appareils
  • Téléversez les images logicielles dans le référentiel SD-WAN Manager ; épinglez les versions souhaitées par rôle, site ou groupe de configuration. Les plateformes matérielles prises en charge incluent les images Cisco IOS XE SD-WAN sur les familles ISR 4000 et ASR 1000, ainsi que les WAN Edges virtuels pour l’IaaS.
  • Déploiement contrôlé : mettez en œuvre des mises à niveau par anneaux (branches canary, puis cohortes par ID de site ou tag), avec des vérifications préalables (prechecks) (ressources, joignabilité du contrôleur, validité du certificat) et des vérifications postérieures (postchecks) (adjacences OMP, santé des tunnels de données).
  • Utilisez des fenêtres de maintenance et une planification automatisée. Pour les sites critiques, préparez un état préconfiguré (staged state) ou un redémarrage en douceur (graceful restart) le cas échéant pour minimiser les interruptions. Validez que les connexions de contrôle vers vSmart sont restaurées avant de passer à l’anneau suivant.
  • Plans de retour en arrière (rollback) : conservez l’image précédente, confirmez les déclencheurs de retour en arrière automatique et disposez d’un accès hors bande (out-of-band) par appareil en cas d’urgence (break-glass).
• Garde-fous d’automatisation et gestion déléguée des changements
  • Le RBAC dans SD-WAN Manager sépare les responsabilités : les auteurs pour les modèles de fonctionnalités (feature templates), les approbateurs pour les déploiements, les opérateurs pour les actions post-déploiement (day-2) (assignation d’images, mises à jour de variables). Restreignez qui peut détacher des modèles ou pousser des ajouts CLI (CLI add-ons).
  • Les workflows d’approbation et le modèle brouillon/publication des groupes de configuration permettent la revue par les pairs et des déploiements incrémentiels et limités à une section.
  • Appliquez des conventions de nommage/versionnage, taguez les appareils par rôle/site/transport pour un ciblage cohérent, et exigez un aperçu de la configuration ainsi que des portes de vérification de la santé (health verification gates) avant un déploiement de masse.

Scénario de problème pratique

Acme Health Services prévoit de standardiser 600 WAN Edges de succursales en utilisant une configuration basée sur des modèles, tout en introduisant une nouvelle pile de sécurité et en se préparant à une mise à niveau logicielle progressive. Les sites existants présentent des variations CLI ad hoc qui ont créé de la dérive (drift) et un comportement incohérent.

Approche :

1. Modéliser les rôles et construire une intention réutilisable

   • Créez des modèles de fonctionnalités de référence (golden feature templates) pour System, OMP, VPN 0 Transport, Service VPNs et Security, paramétrés avec des variables spécifiques à l’appareil pour l’IP système, l’ID de site, l’adressage des interfaces et les ASN BGP. Raisonnement : isole les invariants de grande valeur (identité, plan de contrôle) des données spécifiques au site, maximisant la réutilisation et réduisant les surfaces d’erreur.

2. Migrer vers des groupes de configuration pour des changements limités à une section

   • Construisez un groupe de configuration par rôle (Branch-Standard, Branch-Small, Hub), en important les modèles de fonctionnalités existants et en définissant les portées des variables. Raisonnement : permet des déploiements partiels (par exemple, mettre à jour uniquement les sections Security) sans toucher à System/OMP, réduisant ainsi le risque et les temps de déploiement (push times).

3. Normaliser les variables des appareils et corriger la dérive

   • Importez en masse le CSV des variables depuis l’inventaire, puis exécutez une vérification de conformité pour détecter la dérive. Pour les commandes ad hoc approuvées (logging/SNMP), capturez-les dans un ajout CLI (CLI add-on) attaché au groupe de configuration ; pour les chevauchements non sécurisés (VPN 0, OMP), supprimez-les des appareils et fiez-vous aux modèles. Raisonnement : codifie les exceptions en toute sécurité et élimine la configuration redondante qui serait élaguée (pruned) par les déploiements futurs.

4. Valider avec l’aperçu de la configuration et l’attachement canary

   • Utilisez l’aperçu de la configuration sur trois sites canary diversifiés, confirmez les adresses d’interface générées, le NAT du VPN 0, les paramètres OMP et les politiques de sécurité. Attachez le groupe de configuration à ces appareils et surveillez les connexions de contrôle (DTLS/TLS vers vSmart) et les tunnels de données (IPsec vers les pairs). Raisonnement : détection précoce des défauts de modèle ou de variable avant la mise à l’échelle.

5. Appliquer des contrôles de changement délégués

   • Assignez les rôles RBAC : Auteurs de modèles (créer/modifier les modèles), Approbateurs de déploiement (publier/attacher), Opérations (mises à jour de variables uniquement). Exigez une approbation pour les tâches de publication et d’attachement. Raisonnement : empêche les changements larges non autorisés et garantit la revue par les pairs.

6. Introduire la nouvelle pile de sécurité de manière incrémentielle

   • Dans le groupe de configuration, mettez à jour uniquement la section Security pour les sites canary, puis publiez et attachez cette section. Validez le trafic avec les compteurs de correspondance des politiques (policy hit counters) et la visibilité applicative avant d’étendre. Raisonnement : le changement limité à une section minimise l’impact collatéral tout en permettant une itération rapide.

7. Préparer les images logicielles et exécuter une mise à niveau par anneaux

   • Téléversez l’image cible IOS XE SD-WAN, assignez-la au groupe de configuration Branch-Standard et définissez des anneaux de mise à niveau : 5 sites canary, 50 sites, puis les cohortes restantes par ID de site. Activez les vérifications préalables (prechecks) et postérieures (postchecks) ; planifiez pendant les fenêtres de maintenance. Raisonnement : un déploiement contrôlé avec des portes de vérification de la santé (health gates) réduit le risque sur les 600 sites.

8. Surveiller la conformité et préparer les retours en arrière (rollbacks)

   • Après chaque anneau, vérifiez la conformité et la dérive, assurez-vous que l’échange de routes OMP est stable et que les politiques de sécurité sont appliquées. Conservez l’image précédente comme solution de repli (fallback) et gardez la dernière version de configuration fonctionnelle connue (last known-good) marquée pour un retour en arrière rapide. Raisonnement : chemin de récupération rapide si un comportement inattendu apparaît.

En unifiant l’intention dans des groupes de configuration, en contraignant les valeurs spécifiques aux appareils via des variables et en utilisant des ajouts CLI (CLI add-ons) uniquement pour les exceptions sûres, Acme Health Services obtient un comportement cohérent des WAN Edges. La visibilité de la conformité, les opérations à grande échelle pilotées par API et le déploiement d’images par anneaux fournissent une gestion du changement prévisible et à faible risque, tout en préservant la flexibilité pour les besoins spécifiques des sites.

← OMP · Tous les domaines · Tunnels du plan de données →

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