Cisco 200-301: WAN, automatisation, virtualisation et opérations réseau — Guide d'étude

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Fait partie du Cisco CCNA 200-301 — 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

La connectivité WAN, la virtualisation et l’automatisation ont convergé pour remodeler la manière dont les entreprises construisent, exploitent et sécurisent leurs réseaux. Les conceptions modernes combinent un transport de sous-couche (underlay) (lignes louées, Metro Ethernet, large bande et cellulaire) avec des superpositions (overlays) (VPN, GRE ou SD‑WAN) pour fournir un acheminement prévisible et piloté par des politiques. Le routage et le transfert virtuels (VRF) assurent la segmentation, tandis que des contrôleurs tels que Cisco DNA Center et les orchestrateurs SD‑WAN centralisent l’intention et rationalisent les changements. Les interfaces programmables et les outils comme les API REST, Ansible et Python permettent des opérations reproductibles, testables et auditables. Des pratiques d’exploitation saines — y compris la gestion des changements, les sauvegardes, la gestion des images, la reprise après sinistre et le dépannage structuré — lient la solution et réduisent le temps moyen de rétablissement (MTTR).

Connectivité et encapsulation WAN

La sélection du transport WAN est un équilibre entre le coût, la performance, la résilience et la complexité opérationnelle.

• Lignes louées (T1/E1, T3/E3, OC ou ligne privée Ethernet) : Circuits point à point dédiés avec une latence prévisible et des SLA solides. Avantages : performances déterministes, routage simple. Inconvénients : coût élevé, provisionnement plus lent.
• Metro Ethernet : Services Ethernet de fournisseur (E-Line, E-LAN, E-Tree) sur fibre, généralement 10/100/1000 Mbps et plus. Avantages : bande passante évolutive, transparence de la QoS avec les classes de fournisseur, transferts plus simples. Inconvénients : la topologie et la QoS peuvent varier selon l’opérateur ; risque de contraintes d’apprentissage MAC en cas d’extension L2.
• Large bande (DSL, câble, FTTH) : Internet en « best-effort » (meilleur effort) avec des débits asymétriques ou symétriques. Avantages : peu coûteux, déploiement rapide, grande disponibilité. Inconvénients : latence et gigue variables ; nécessite des superpositions (overlays) (IPsec/GRE/SD‑WAN) pour la segmentation et le chiffrement.
• VPN : Superpositions (overlays) sur des réseaux non fiables. IPsec de site à site sécurise le trafic ; DMVPN ajoute un dynamisme « spoke-to-spoke » ; l’accès à distance basé sur TLS s’adapte au nombre d’utilisateurs. Avantages : chiffrement et indépendance de la joignabilité par rapport à la sous-couche (underlay). Inconvénients : défis liés au MTU/à la fragmentation, surcharge cryptographique, dépendance à la stabilité d’Internet.
• Cellulaire (4G/LTE/5G) : Transport principal ou de secours avec un déploiement rapide. Avantages : véritable diversité de chemins de dernier recours, mise en service rapide. Inconvénients : performances variables, plafonds de données, problèmes de CGNAT.

Les encapsulations de base connectent les routeurs sur ces transports :

• HDLC : Encapsulation par défaut sur de nombreuses interfaces série Cisco. Tramage léger, propriétaire Cisco par défaut ; pas d’authentification.
• PPP : Encapsulation basée sur des standards sur des liaisons série ou PPPoE sur Ethernet. Prend en charge les « keepalives » LCP, l’authentification CHAP/PAP, le Multilink PPP (MLPPP) et IPCP pour les paramètres IP. Compromis : une surcharge légèrement supérieure à HDLC, mais ajoute l’interopérabilité et des fonctionnalités.

Exemple — PPP avec CHAP :

undefined

• GRE : Un tunnel léger pour encapsuler des protocoles passagers dans IP, créant une adjacence logique. GRE ne chiffre pas ; associez-le à IPsec pour la confidentialité et l’intégrité. Surveillez le MTU ; GRE ajoute 24 octets, IPsec en ajoute davantage.

Exemple — Tunnel GRE sur Internet :

undefined

Modes de défaillance courants et protections :

• Une encapsulation non concordante (PPP vs HDLC) empêche l’établissement de la liaison. Vérifiez avec show interfaces, l’encapsulation et les états LCP.
• Le MTU/la fragmentation avec GRE/IPsec/PPPoE provoque des trous noirs (black holes). Utilisez les commandes ip mtu et ip tcp adjust-mss appropriées ; validez avec PMTUD et des tests de joignabilité ICMP.
• Des secrets CHAP ou des noms d’hôte non concordants bloquent l’authentification PPP. Synchronisez les informations d’identification et testez avec debug ppp authentication.
• La large bande avec CGNAT peut interrompre IPsec à moins que NAT-T et le port UDP 4500 ne soient autorisés ; confirmez la joignabilité du port.

Virtualisation, réseaux de superposition/sous-jacents et SD-WAN

La virtualisation réseau sépare les réseaux logiques du transport physique pour offrir la segmentation, le multi-tenant et un transfert flexible.

• VRF (VRF-Lite sans MPLS, ou avec MPLS dans les cœurs de fournisseur) : Plusieurs tables de routage sur un seul équipement. Chaque VRF isole les interfaces, les routes et les politiques. Évitez les fuites de routes en utilisant des politiques de route-target explicites dans les déploiements MPLS ou un filtrage statique/de bordure en VRF-Lite.

Exemple — VRF-Lite simple :

ip vrf BLUE ! interface GigabitEthernet0/1 ip vrf forwarding BLUE ip address 10.10.10.1 255.255.255.0

• Réseau sous-jacent (underlay) vs réseau de superposition (overlay) : Le réseau sous-jacent fournit la joignabilité IP entre les nœuds (par ex., FAI, MetroE, MPLS). Les réseaux de superposition (GRE, IPsec, VXLAN, fabric SD-WAN) transportent le trafic des locataires (tenants) ou le trafic segmenté. Exploitez chaque couche indépendamment pour simplifier le dépannage — testez d’abord le réseau sous-jacent (ping entre les points de terminaison du tunnel), puis le réseau de superposition (ping à travers le tunnel).

Le SD-WAN enrichit les réseaux de superposition avec un contrôle et des politiques centralisés :

• Composants : Les routeurs de périphérie (edge) forment des tunnels de plan de données chiffrés ; les contrôleurs incluent un orchestrateur (intégration/traversée NAT), un plan de contrôle (échange de routes et politique de sécurité) et un plan de gestion (GUI/API, modèles, supervision). Les certificats établissent une confiance mutuelle et le zero-touch provisioning.
• Transfert basé sur les politiques : Le routage applicatif (application-aware routing) dirige les flux en fonction des métriques de SLA (perte, latence, gigue), du DSCP et de l’intention métier. Les politiques de données (chaînage de services, NAT), les politiques de contrôle (annonce/acceptation de routes) et les politiques de sécurité (FW/IDS) s’appliquent de manière cohérente.

Raisonnements de conception et compromis :

• Des transports doubles ou multiples (MPLS, Internet, LTE) améliorent la disponibilité et la rentabilité ; les contrôleurs sondent en continu les chemins et sélectionnent les meilleurs liens par application. Compromis : complexité accrue dans la conception des politiques et la supervision.
• Le contrôle centralisé réduit les erreurs de configuration mais est sensible à la joignabilité du contrôleur et aux cycles de vie des certificats. Échelonnez la redondance des contrôleurs sur plusieurs sites et supervisez les connexions de contrôle.
• Un routage asymétrique peut se produire lorsque les applications sont dirigées différemment selon la direction ; assurez-vous que le trafic de retour respecte les équipements à état (stateful) ou utilisez des politiques symétriques.

Modes de défaillance courants du SD-WAN :

• Un décalage de certificat/d’horloge empêche les connexions de contrôle. Imposez le NTP et suivez l’expiration des certificats.
• Problèmes de traversée NAT derrière des pare-feu stricts. Validez les ports UDP/TCP requis et les mécanismes de repli.
• Des séquences de politiques mal ordonnées peuvent entraîner la perte involontaire de préfixes ou une classification incorrecte des applications. Testez en pré-production (staging) et appliquez des compteurs de correspondances (hit-counters)/de la journalisation pour confirmer les correspondances.

Automatisation, Cisco DNA Center et Programmabilité

Le réseau basé sur l’intention (Intent-Based Networking) codifie les résultats souhaités en politiques et automatise leur application avec validation.

Concepts de Cisco DNA Center (DNAC) :

• Inventaire et topologie : Découvre les équipements via SNMP/CLI/API, construit la topologie et maintient les attributs matériels/logiciels.
• Automatisation : Provisioning basé sur des modèles, gestion des images, intégration des équipements (Plug and Play) et workflows d’accès défini par logiciel (software-defined access).
• Assurance : Scores de santé basés sur la télémétrie pour les clients, les équipements et les applications ; les lignes de base (baselines) et la détection d’anomalies accélèrent l’analyse des causes profondes.
• Politique : Traduit l’intention (segmentation, QoS, contrôle d’accès) en configurations déployables avec des vérifications de conformité.

API REST et encodage des données :

• Méthodes HTTP : GET (récupérer), POST (créer), PUT/PATCH (remplacer/modifier), DELETE (supprimer). GET est idempotent ; soyez attentif à l’idempotence pour les nouvelles tentatives (retries).
• Formats de données : JSON est le standard de facto ; YAML/TOML peuvent apparaître dans l’outillage mais REST échange généralement du JSON. Utilisez l’UTF-8 et les en-têtes Content-Type/Accept appropriés.
• Authentification : L’authentification basique (Basic auth) est simple mais non sécurisée sans TLS ; l’authentification par jeton (token-based auth) (clés d’API ou JWT) est préférée ; OAuth 2.0 fournit une autorisation déléguée. Utilisez toujours TLS, validez les certificats et gérez le rafraîchissement des jetons.
• Codes de statut : 200/201 pour un succès, 202 pour les opérations asynchrones, 400/404 pour les erreurs client, 401/403 pour les échecs d’authentification/autorisation, 429 pour les limites de débit (rate limits), 5xx pour les erreurs serveur. Concevez un backoff pour les codes 429/5xx.

Exemple — charge utile (payload) JSON pour une variable de modèle d’interface :

{ “interface”: “GigabitEthernet0/1”, “description”: “Liaison Agence”, “vrf”: “BLUE”, “ip_address”: “10.10.10.1”, “mask”: “255.255.255.0” }

Gestion de configuration et automatisation de l’infrastructure :

• Contrôle de version : Stockez les configurations, les modèles et les playbooks dans Git. Utilisez des branches et des pull requests pour la revue de code et les pistes d’audit.
• Idempotence : Les outils appliquent l’état désiré sans effectuer de changements répétés ; améliore la prévisibilité et la conformité.
• Inventaire et modèles (templating) : Structurez les inventaires d’hôtes/groupes et paramétrez les configurations avec Jinja2. Maintenez des configurations de référence (golden configurations) et des vérifications de conformité.
• Gestion des secrets : Protégez les identifiants et les clés en utilisant des coffres-forts (vaults) ou des abstractions d’environnement ; évitez le texte en clair dans les dépôts.
• CI/CD pour le réseau : Validez la syntaxe (lint) des configurations, simulez les politiques, exécutez des tests unitaires sur les modèles et mettez en pré-production (stage) les déploiements avec des vérifications avant/après (pre-checks/post-checks).

Cas d’usage d’Ansible et Python :

• Ansible : Changements rapides sur plusieurs équipements, mises à niveau d’images, provisioning d’interfaces/VRF et vérifications de conformité via les modules réseau. Extrait d’un playbook en exemple :

  • hosts: branch_routers connection: network_cli gather_facts: no tasks:
    • ios_config: lines: - ip vrf BLUE - interface GigabitEthernet0/1 - ip vrf forwarding BLUE - ip address 10.10.10.1 255.255.255.0

• Python : Scripting ad hoc, intégrations d’API et validations personnalisées. Utilisez requests pour les appels REST ou des bibliothèques pour le CLI réseau. Concept en exemple :

  import requests headers = {“X-Auth-Token”: token, “Content-Type”: “application/json”} payload = {“description”: “Mis à jour via l’API”} r = requests.patch(api_endpoint, headers=headers, json=payload) assert r.status_code in (200, 202)

Opérations, fiabilité et dépannage

Des opérations rigoureuses réduisent les risques et améliorent la disponibilité.

Contrôle des changements :

• Définir la portée, les risques, le plan de retour en arrière (rollback), les tests de validation et le calendrier. Exiger une revue par les pairs et un déploiement par étapes (labo → pilote → déploiement progressif).
• Les fenêtres de maintenance et les notifications aux clients permettent de gérer les attentes. Utiliser une méthode opératoire (method of procedure) avec des points de contrôle explicites.

Sauvegardes et gestion des images :

• Sauvegardes nocturnes des running-config, startup-config et des bases de données critiques des contrôleurs. Valider les sauvegardes par des restaurations périodiques en laboratoire.
• Images de référence (golden images) et catalogues d’images alignés sur les besoins matériels et fonctionnels. Précharger les images pendant les périodes creuses ; envisager l’ISSU là où il est pris en charge pour minimiser les interruptions de service.
• Vérifier les sommes de contrôle (checksums) MD5/SHA et les signatures ; suivre les notes de version (release notes) et les avis de terrain (field notices).

Reprise après sinistre :

• Gestion hors bande (out-of-band) et accès console pour les appareils bloqués (bricked).
• Contrôleurs redondants et stockage des sauvegardes hors site. Documenter et répéter périodiquement les procédures de reprise (runbooks).
• Pour le SD‑WAN et DNAC, exporter les clés/certificats et maintenir les procédures de redéploiement des contrôleurs.

Dépannage systématique :

• Définir le problème et son impact ; le reproduire si possible.
• Établir une base de référence : comparer l’utilisation actuelle du CPU, de la mémoire, les compteurs d’interface, les enregistrements de flux et la latence par rapport aux normes historiques. Les changements depuis le dernier état fonctionnel connu sont les principaux suspects.
• Isoler par couches OSI et par underlay vs overlay. Valider d’abord le niveau physique/liaison, puis la joignabilité IP, puis le plan de contrôle (routage/OMP), puis le plan de données (ACL/NAT/QoS), et enfin l’application.
• Formuler des hypothèses, tester avec des changements minimes et instrumenter avec des captures, des débogages ou de la télémétrie ciblés. Éviter les changements à l’aveugle.

Analyse des causes profondes (Root-cause analysis) :

• Documenter la chronologie, la chaîne de causalité et les facteurs contributifs. Distinguer le déclencheur du défaut sous-jacent (par ex., l’expiration d’un certificat a déclenché la perte de contrôle car les seuils de surveillance manquaient).
• Mettre en œuvre des actions correctives et préventives : surveillance, mise à jour des procédures (runbooks), normes de configuration et formation.

Pièges opérationnels courants :

• Dérives par rapport aux configurations de référence (golden configs) au fil du temps ; à résoudre avec des analyses de conformité et une remédiation automatique.
• Chevauchements de politiques non coordonnées dans le SD‑WAN ou les ACL provoquant des rejets de paquets non intentionnels ; à résoudre avec une analyse statique (linting) centralisée des politiques et l’examen des compteurs de correspondances (hit-counters).
• Surveillance inefficace de la latence/gigue pour les applications critiques ; à résoudre avec des sondes actives et des SLO liés à des alertes.

Scénario de problème pratique

BluePeak Manufacturing remplace son coûteux réseau MPLS par une double connexion Internet et une sauvegarde LTE pour ses 40 agences, tout en introduisant une segmentation basée sur les VRF et une automatisation centralisée.

1. Construire l’underlay et valider la joignabilité.

• Raison d’être : Un overlay fiable nécessite une connectivité IP stable entre les routeurs de périphérie WAN. Commander deux FAI pour chaque agence, les connecter à des ports WAN distincts sur le routeur et provisionner la LTE en tant que connexion tertiaire. Valider avec des pings et des traceroutes entre les adresses IP publiques, confirmer les comportements du NAT et s’assurer que l’ICMP n’est pas filtré pour prendre en charge le PMTUD.

2. Mettre en place les contrôleurs SD‑WAN et enrôler les routeurs de périphérie (edges).

• Raison d’être : Le contrôle centralisé permet des politiques basées sur l’intention (intent-driven). Déployer des nœuds d’orchestration, de contrôle et de gestion redondants ; intégrer la PKI d’entreprise ou utiliser les certificats intégrés. Utiliser le provisionnement sans intervention (zero-touch provisioning) pour intégrer de manière sécurisée les routeurs de périphérie derrière un NAT, en vérifiant la synchronisation de l’heure pour éviter les échecs de certificat.

3. Définir les VRF et segmenter le trafic.

• Raison d’être : Isoler les réseaux de production, invités (guest) et OT (technologie opérationnelle). Créer des VRF sur les passerelles des agences et du campus, lier les interfaces appropriées et ne laisser fuiter que les services requis via une redistribution contrôlée. Exemple dans les agences :

undefined

undefined

undefined

undefined

undefined

undefined

4. Créer des politiques applicatives (application-aware) et des sondes de SLA.

• Raison d’être : Orienter les applications critiques sur le meilleur chemin. Configurer des sondes de perte/latence/gigue par transport et définir des politiques : envoyer l’ERP sur le circuit Internet ayant la plus faible latence avec basculement vers un VPN équivalent au MPLS si les seuils sont dépassés ; forcer le VRF invité à n’utiliser que la connexion haut débit la moins chère. Activer le retour symétrique là où des services avec état (stateful) existent.

5. Gérer le MTU et la fragmentation pour les overlays.

• Raison d’être : Éviter les trous noirs (black holes) dus à la surcharge (overhead) GRE/IPsec. Définir ip mtu et TCP MSS adjust sur les tunnels si nécessaire, confirmer le PMTUD avec des pings utilisant le bit DF, et s’assurer que les pare-feux des FAI autorisent l’ICMP de type 3 code 4.

6. Automatiser le provisionnement de base avec Ansible et des modèles (templates).

• Raison d’être : Assurer la cohérence et la rapidité. Stocker l’inventaire des appareils et les variables dans Git, créer des modèles Jinja2 pour les VRF, les interfaces et la QoS, et les appliquer avec des playbooks idempotents. Vérifier en amont la disponibilité des images et valider en aval les adjacences de routage et les correspondances de politiques.

7. Intégrer Cisco DNA Center pour l’assurance et la gestion des images.

• Raison d’être : La surveillance continue de l’état et les logiciels standardisés réduisent les incidents. Importer les appareils dans l’inventaire, activer la télémétrie, définir des images de référence (golden images) par plateforme, planifier des mises à niveau par étapes et corriger automatiquement les dérives par rapport aux configurations de référence.

8. Sécuriser et surveiller avec des API.

• Raison d’être : L’accès programmatique permet de faire évoluer les opérations (scales operations). Utiliser l’authentification par jeton (token) pour interroger l’état des appareils, le statut des politiques et les SLA. Mettre en œuvre un mécanisme d’attente (backoff) pour les réponses 429 et alerter sur l’expiration des certificats des contrôleurs et les événements de panne du plan de contrôle.

9. Exécuter le contrôle des changements et la bascule (cutover) par phases.

• Raison d’être : Minimiser les risques. Lancer un pilote sur trois agences, surveiller les performances des applications et les correspondances de politiques, puis déployer par vagues avec des plans de retour en arrière vers le MPLS. Maintenir un accès hors bande (out-of-band) pendant la bascule.

10. Valider, documenter et effectuer une analyse des causes profondes (RCA).

• Raison d’être : Confirmer le succès et tirer des leçons. Comparer la latence/gigue après la bascule aux bases de référence, examiner les erreurs d’interface et les pertes, et collecter des métriques sur l’expérience utilisateur. Pour tout écart, tracer d’abord l’underlay, puis les chemins de l’overlay, ajuster les politiques et documenter les résultats pour affiner les modèles et les procédures (runbooks).

Cette approche fournit une connectivité WAN résiliente et rentable avec une segmentation et des politiques déterministes, tandis que les systèmes d’automatisation et d’assurance améliorent la qualité opérationnelle et réduisent le temps de détection (time-to-detect) et le temps de réparation (time-to-repair).

← Sécurité des réseaux et contrôle d’accès · Tous les domaines

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