Cisco 350-401: Automatisation, programmabilité et APIs — Guide d'étude

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Fait partie du Cisco CCNP Enterprise 350-401 ENCOR — 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 réseaux d’entreprise évoluent d’une configuration appareil par appareil vers des opérations basées sur des contrôleurs, pilotées par l’intention et avec une automatisation en boucle fermée. La programmabilité expose l’état et le contrôle du réseau via des API et des modèles de données, tandis que des outils comme Python, Ansible et Git permettent des workflows reproductibles et testables. L’objectif est d’exprimer les résultats souhaités de manière déclarative, de laisser les contrôleurs traduire l’intention en politique et en configuration, de mesurer les résultats grâce à la télémétrie et à l’assurance, et de corriger les écarts automatiquement ou avec une approbation humaine. Atteindre cet objectif nécessite de comprendre les rôles des contrôleurs, les API et les protocoles (REST, NETCONF/RESTCONF avec YANG), les formats de données (JSON, XML, YAML), les plateformes d’automatisation (Cisco DNA Center) et les disciplines opérationnelles (idempotence, contrôle de version, tests, gestion des risques et restauration/rollback).

Contrôleurs, intention et opérations en boucle fermée

• Réseaux basés sur des contrôleurs et rôles :
  • Cisco SD-WAN sépare les plans : vManage fournit le plan de gestion unique ; vSmart gère le plan de contrôle et distribue les politiques qui dirigent l’acheminement des données à travers la fabric ; vBond orchestre l’intégration (onboarding) et peut agir comme un serveur STUN pour traverser le NAT. Les routeurs de périphérie (edge) SD-WAN utilisent OMP comme protocole de plan de contrôle pour communiquer avec vSmart.
  • Cisco SD-Access crée un réseau en superposition (overlay) qui fournit une séparation logique de couches 2 et 3. Un nœud de plan de contrôle de la fabric maintient une base de données globale de correspondance terminal-emplacement, tandis qu’un nœud de bordure de la fabric connecte la fabric aux réseaux externes. Dans le sans-fil, la Gestion des Ressources Radio (Radio Resource Management) s’exécute sur le contrôleur sans fil.
• Intention et configuration déclarative :
  • L’intention décrit le résultat souhaité, et non la manière de le mettre en œuvre sur chaque appareil. Les systèmes déclaratifs (par exemple, « segmenter les invités partout avec un accès Internet uniquement ») permettent aux contrôleurs de compiler la politique en configurations spécifiques aux appareils.
  • Compromis : Les modèles déclaratifs simplifient les opérations et réduisent la dérive (drift), mais peuvent masquer les détails d’implémentation. Les opérateurs ont besoin d’outils transparents pour la comparaison/prévisualisation (diff/preview) et la restauration (rollback) afin de maintenir la confiance.
• Opérations en boucle fermée :
  • Mesurer : Collecter l’état via la télémétrie en continu (streaming) et l’assurance du contrôleur.
  • Analyser : Détecter les écarts par rapport à l’intention (par exemple, violations de segmentation, chutes de SLA).
  • Agir : Corriger via des mises à jour de politiques, des changements de configuration ou de l’ingénierie du trafic.
  • Modes de défaillance : Les tempêtes d’événements ou une télémétrie bruitée peuvent déclencher des faux positifs ; les boucles de remédiation peuvent osciller. Des garde-fous (limites de débit, hystérésis, approbations humaines) et une corrélation robuste empêchent le surmenage (thrashing).

API, modèles de données et protocoles

• API REST :
  • Méthodes : GET (lire), POST (créer/agir), PUT (remplacer), PATCH (mise à jour partielle), DELETE (supprimer), HEAD/OPTIONS (métadonnées).
  • Codes de statut : 2xx succès (200 OK, 201 Created), 3xx redirections, 4xx erreurs client (400 mauvaise requête, 401 non autorisé, 403 interdit, 404 non trouvé, 409 conflit, 429 limite de débit), 5xx erreurs serveur (500, 503).
  • Authentification : Basic (sur TLS), mécanismes de jeton/bearer, et OAuth 2.0. Utilisez toujours TLS ; évitez d’intégrer des identifiants dans les URI. Gérez le rafraîchissement et l’expiration des jetons.
  • Limites de débit (Rate limits) : Les serveurs peuvent réguler le débit (throttle) avec un code 429 et l’en-tête Retry-After. Implémentez un retrait exponentiel (exponential backoff), de la gigue (jitter) et un suivi du budget de requêtes dans les clients.
• Formats de données et validation :
  • Le JSON est courant pour REST ; le XML reste prédominant dans NETCONF ; le YAML est utilisé pour les fichiers rédigés par des humains (inventaires, playbooks, ensembles de variables). Convertissez le YAML en JSON en interne si nécessaire.
  • Validation de schéma : Utilisez JSON Schema pour les charges utiles (payloads) JSON ; XML Schema pour le XML ; YANG pour la gestion basée sur des modèles (types, contraintes, instructions must/when). Validez côté client avant l’envoi pour détecter les erreurs le plus tôt possible.
• NETCONF, RESTCONF, YANG, RPC et banques de données (datastores) :
  • Les modèles YANG définissent les structures de données et les opérations pour la configuration et l’état.
  • NETCONF utilise XML sur SSH, avec des opérations comme , , , , , . Les banques de données (datastores) incluent généralement running et candidate ; candidate permet une préparation et une validation (prepare-and-commit) avec atomicité.
  • RESTCONF mappe les ressources modélisées en YANG sur une interface RESTful via HTTP(S), en utilisant JSON ou XML avec des types de médias standardisés. Les méthodes correspondent à la sémantique de NETCONF (PATCH/PUT pour les modifications).
  • Modes de défaillance et conception :
    • Conflit de verrouillage (Lock contention) : Coordonnez les pour éviter les interblocages (deadlocks) ; utilisez une portée limitée et des délais d’attente (timeouts).
    • Défaillances partielles : Préférez la banque de données candidate + pour des changements transactionnels. Si seule la banque running est disponible, utilisez des groupes de changements structurés et des points de contrôle (checkpoints).
    • Dérive de modèle (Model drift) : Les appareils peuvent prendre en charge différentes révisions de modules YANG ; négociez les capacités et testez pendant l’intégration continue (CI).
• Exemples concis :
  • Mise à jour partielle RESTCONF (échange HTTP) : PATCH /restconf/data/ietf-

Outils et Workflows : Python, Ansible, Git et Pipelines

• Automatisation avec Cisco DNA Center :
  • Les API REST Northbound fournissent un accès à l’inventaire, aux modèles, au provisionnement et à l’assurance. Les interfaces Southbound connectent le contrôleur aux équipements (CLI, SNMP, NETCONF/RESTCONF) pour appliquer l’intention.
  • Les workflows de découverte peuvent utiliser CDP, LLDP et des plages d’adresses IP. Utilisez le contrôle d’accès basé sur les rôles, des modèles par projet et des variables par site. L’Assurance corrèle la télémétrie pour identifier des problèmes, des scores de santé et des remédiations suggérées — des entrées clés pour l’automatisation en boucle fermée.
• Fondamentaux de Python pour l’automatisation réseau :
  • Langage de base : types, fonctions, modules, environnements virtuels et journalisation (logging).
  • Bibliothèques : requests/httpx (REST), ncclient (NETCONF), jinja2 (templating), pyyaml, json, pandas (manipulation de données), rich/logging pour l’observabilité.
  • Bonnes pratiques : validation des entrées, nouvelles tentatives avec temporisation, exceptions structurées, timeouts et tests unitaires. Sérialisez la logique métier à l’écart des E/S pour simplifier les tests.
• Ansible :
  • L’inventaire (Inventory) définit les hôtes et les groupes ; conservez host_vars/group_vars en YAML.
  • Les Playbooks déclarent l’état désiré ; des modules tels que ios_config, ios_facts, iosxe_config, restconf_config et uri effectuent les actions. Utilisez les rôles pour encapsuler la logique réutilisable.
  • Idempotence : Les modules garantissent que des exécutions répétées convergent sans changements non intentionnels. Utilisez check_mode et diff pour prévisualiser ; notifiez les handlers pour sauvegarder uniquement en cas de changement.
  • Exemple :
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Gestion des changements : utilisez des fenêtres de maintenance, une stratégie série ou par lots, et une limitation (throttling) par site pour limiter le rayon d’impact. Capturez automatiquement les vérifications pré/post-déploiement.
• Git, gestion de versions, tests et pipelines :
  • Stockez l’intention du réseau (variables YAML, modèles Jinja, playbooks), les configurations générées et les tests dans Git. Utilisez les branches, les pull requests et la revue de code. Les commits sémantiques et les tags alignent les versions avec les déploiements.
  • Tests : linter les fichiers YAML et les playbooks, valider les schémas YANG/JSON, exécuter les tests unitaires et les tests de scénario Ansible Molecule. Intégrez des vérifications synthétiques préalables (par exemple, la joignabilité) dans la CI.
  • Pipelines : Dev → pré-production/laboratoire → canary en production → déploiement progressif. Les points de contrôle (gates) incluent l’analyse statique, les exécutions à blanc sur des simulateurs, les approbations et le rollback automatique en cas de régression de la santé.

← Sécurité d’entreprise et services d’identité · Tous les domaines · Assurance réseau →

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