Cisco 300-415: Politique centralisée et ingénierie du trafic — 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

La politique centralisée dans Cisco SD-WAN est le cadre qui vous permet de programmer le comportement du trafic et l’intention de routage depuis les contrôleurs vSmart à travers l’ensemble de la fabric. vSmart, qui gère le plan de contrôle de l’overlay via OMP, distribue la politique de contrôle centralisée (pour les routes OMP et les TLOC) et les politiques de plan de données telles que les politiques de données, de routage applicatif (app-route) et cflowd. Ces politiques façonnent la topologie (hub-and-spoke, restriction de maillage), sélectionnent les chemins en fonction des performances des applications, dirigent les flux vers des services et segmentent le trafic par VPN. Étant donné que les politiques peuvent altérer à la fois la joignabilité du plan de contrôle et le transfert du plan de données, une conception soignée, un aperçu et un déploiement par étapes sont essentiels pour éviter les pannes.

Types de politiques centralisées et blocs de construction

• Politique de contrôle centralisée

  • Portée : Plan de contrôle (OMP) entre les appareils WAN Edge et vSmart.
  • Objectif : Filtrer/modifier les annonces de routes OMP et de TLOC, définir des attributs (préférence, tag, origine, TLOC) et construire des topologies (hub-and-spoke, maillage partiel).
  • Direction : Entrante (vers vSmart depuis le WAN Edge) et sortante (depuis vSmart vers le WAN Edge).

• Politique de données centralisée

  • Portée : Classification du plan de données (L3/L4, champs, app-ID) au niveau du WAN Edge, installée par vSmart.
  • Objectif : Autoriser/refuser les flux, définir le VPN, définir le TLOC, définir le DSCP/marquage, réguler (police), mettre en miroir (mirror) et réaliser l’insertion/chaînage de services.
  • Direction : Évaluée au niveau du WAN Edge par rapport au côté service (LAN) ou au côté tunnel (WAN) selon l’endroit où elle est programmée ; les conceptions ciblent généralement l’entrée côté service pour les flux utilisateur-vers-WAN et le côté tunnel pour le retour si un comportement symétrique est requis.

• Politique de routage applicatif (app-route)

  • Portée : Sélection de chemin du plan de données basée sur l’application et le SLA (perte, latence, gigue) mesurés par BFD.
  • Objectif : Diriger le trafic vers les TLOC/couleurs préférés, définir des classes de SLA basées sur des sondes, définir des solutions de repli et effectuer une ingénierie de trafic dynamique par application/famille.
  • Comportement clé : Évalue en continu les performances du chemin ; peut changer de chemin lorsque le SLA se dégrade.

• Politique cflowd

  • Portée : Télémétrie de flux (similaire à IPFIX/NetFlow) générée par les WAN Edges.
  • Objectif : Activer/désactiver les exportateurs par VPN, définir les taux d’échantillonnage, les modèles et les collecteurs (vManage ou externes).
  • Note de conception : L’échantillonnage doit équilibrer la visibilité avec la surcharge CPU/bande passante ; l’activation par VPN prend en charge le reporting segmenté.

Les listes de politique sont des objets de correspondance réutilisables :

• Liste de sites : ID de site utilisés pour sélectionner où les politiques s’attachent et pour faire correspondre les sites d’origine/destination des routes.
• Liste de VPN : VRF (VPN) utilisés pour segmenter la portée de la politique et construire des règles par segment.
• Liste de préfixes : Préfixes IP pour faire correspondre les routes OMP ou le trafic de données.
• Liste de préfixes de données : Objet de préfixe spécialisé pour la classification de la politique de données.
• Liste de TLOC : Tuples composés de l’IP système, de la couleur et de l’encapsulation, utilisés pour faire correspondre ou définir des attributs de TLOC.
• Liste de couleurs : Une ou plusieurs couleurs de transport (par ex., biz-internet, mpls, public-internet) pour le ciblage/l’affinité de lien.
• Liste d’applications : Applications/groupes NBAR2 pour classifier le trafic pour les politiques d’app-route ou de données.
• Classe de SLA : Seuils de latence, de perte et de gigue liés à l’app-route pour une orientation basée sur la performance.

Structure et évaluation des séquences de politique :

• Les séquences sont ordonnées, la première correspondance l’emporte. Chaque séquence a :
  • Conditions de correspondance : Listes/champs (site/VPN/préfixe/TLOC/couleur/app, ports L4, DSCP, protocole).
  • Actions : Accepter/refuser, définir des attributs (TLOC, VPN, DSCP, préférence, tag), insertion de service, réguler (police), mettre en miroir (mirror).
• Action par défaut : Appliquée si aucune séquence ne correspond. Les valeurs par défaut courantes sont ‘accept’ (contrôle/données) pour éviter les rejets involontaires ; les valeurs par défaut ‘deny’ explicites sont utilisées délibérément et nécessitent une validation minutieuse.
• Direction :
  • La direction de la politique de contrôle se situe au niveau de vSmart (OMP entrant/sortant).
  • Les politiques de données et d’app-route opèrent sur le trafic au niveau du WAN Edge ; choisissez un comportement côté service ou côté tunnel pour correspondre au flux que vous souhaitez affecter, et assurez la symétrie du trafic de retour lorsque des services stateful sont sur le chemin.

Conception de la politique du plan de contrôle et manipulation des routes/TLOC

La politique de contrôle est l’outil de référence pour façonner la topologie de la surcouche (overlay), car elle détermine quelles routes OMP et quels TLOC un site peut envoyer ou recevoir :

• Manipulation des routes OMP

  • Utilisez une politique de contrôle entrante (inbound) pour filtrer, marquer (tag) ou définir des attributs sur les routes apprises d’un site avant qu’elles n’entrent dans la RIB de la surcouche sur vSmart.
  • Utilisez une politique de contrôle sortante (outbound) pour limiter les routes annoncées à des sites spécifiques (par exemple, ne pas annoncer les préfixes appris des spokes à d’autres spokes).
  • Actions courantes : définir la préférence (influence le meilleur chemin OMP), définir un marqueur (tag) (pour une correspondance ultérieure), définir l’origine, définir des contraintes de site d’origine.

• Manipulation des TLOC

  • Faites correspondre les attributs TLOC (IP système, couleur, encapsulation) pour filtrer ou préférer des transports spécifiques.
  • Les actions incluent la modification des attributs ou des préférences TLOC pour que les annonces de routes favorisent une couleur donnée (par exemple, préférer MPLS pour les sous-réseaux critiques).
  • Compromis : un filtrage TLOC trop agressif peut isoler des sites si le transport restant tombe en panne. Préférez l’ajustement des attributs à un refus global (blanket deny), sauf si vous disposez de chemins redondants.

• Modèles de topologie

  • Hub-and-spoke (en étoile) : la politique de contrôle sortante de vSmart vers les spokes refuse l’annonce des routes provenant des spokes à d’autres spokes ; les hubs reçoivent et annoncent tout.
  • Restriction de maillage (mesh) : similaire au hub-and-spoke, mais autorise des paires spoke-à-spoke spécifiques (par exemple, des maillages régionaux) via des exceptions dans les séquences de politique.
  • Segmentation : combinez les listes de VPN avec le filtrage de routes pour maintenir les surcouches par VPN isolées ; n’annoncez que les préfixes par défaut ou des préfixes sélectionnés aux sites restreints.

Modes de défaillance et compromis :

• Une politique de contrôle sortante mal appliquée avec un refus par défaut (deny default) peut retirer des routes critiques, isolant ainsi des sites. Utilisez toujours une acceptation par défaut (default accept) et ajoutez des refus ciblés, sauf si votre aperçu confirme explicitement la couverture.
• La modification des attributs OMP à grande échelle peut déclencher une instabilité des routes (route churn) ; échelonnez le déploiement par listes de sites pour réduire le choc sur le plan de contrôle.
• La réécriture des attributs TLOC peut entraîner un transfert asymétrique si le chemin de retour n’est pas influencé de manière équivalente ; validez les deux directions.

Routage applicatif (AAR), insertion de services et segmentation

Le routage applicatif (Application-aware routing - AAR) et la politique de données fournissent ensemble une ingénierie de trafic fine :

• AAR et pilotage du trafic

  • Les classes de SLA définissent des niveaux de perte/latence/gigue acceptables ; les sondes BFD par paire de TLOC fournissent des mesures en temps réel.
  • La politique de routage applicatif (app-route) correspond à des applications ou à des champs L3/L4 et sélectionne des listes de couleurs/TLOC préférées ; si le SLA est violé, le basculement s’effectue conformément à la politique.
  • Conseils de conception :
    • Évitez les seuils de SLA trop stricts qui provoquent des basculements intempestifs (flapping) ; incluez une hystérésis en utilisant des multiplicateurs de sondes et des seuils raisonnables.
    • Pour les applications sensibles à la réorganisation des paquets, préférez un changement sur le prochain nouveau flux (« move on next new flow ») plutôt que des changements en cours de flux, ou épinglez les flux en utilisant le hachage cohérent (consistent hashing) là où il est pris en charge.
    • Lorsque AAR et la politique de données définissent tous deux le TLOC, donnez la priorité à AAR pour la sélection du chemin et utilisez la politique de données pour l’insertion/marquage de services ; évitez les actions qui se chevauchent dans la même classe de trafic.

• Enchaînement et insertion de services

  • L’action de politique de données « service » insère le trafic à travers des services sur site (on-prem) ou en colocation (pare-feu, IDS/IPS, nœuds de service SD-WAN).
  • Enchaînez plusieurs services dans l’ordre requis ; assurez une insertion symétrique pour les services à état (stateful) sur les chemins aller et retour.
  • Compromis : chaque saut de service ajoute de la latence et des domaines de défaillance potentiels. Mettez en œuvre des vérifications de santé (health checks) et des comportements de basculement ouvert/fermé (fail-open/closed) cohérents avec la posture de sécurité.

• Segmentation du trafic

  • Les VPN fournissent une segmentation stricte ; la politique centralisée s’applique par VPN en utilisant des listes de VPN.
  • Le routage inter-VPN (fuite de routes ou route leaking) peut être réalisé avec une politique de données en utilisant « set VPN » pour des flux spécifiques ; limitez-le strictement avec des correspondances de préfixe/application et auditez-le fréquemment.
  • Pour les services partagés (par exemple, DNS, identité), annoncez les préfixes de service depuis un VPN de services vers les VPN consommateurs avec une politique de contrôle, plutôt que par des fuites étendues dans le plan de données.

Exemple d’extrait de routage applicatif (app-route) illustrant le pilotage basé sur le SLA :

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Opérations : Attachement, Validation et Dépannage

Attachement de politique via vSmart :

• Définir des politiques centralisées dans vManage et les attacher à des listes de sites et des listes de VPN. vSmart compile la politique et la distribue aux WAN Edges via des sessions OMP sécurisées DTLS/TLS dans le VPN 0.
• Délimitez soigneusement les changements ; une seule instance de politique peut affecter des centaines de sites. Utilisez des listes de sites pour échelonner les déploiements par région ou par fonction.

Simulation, prévisualisation et déploiement échelonné de la politique :

• Prévisualisation : Avant l’activation, utilisez la prévisualisation de vManage pour inspecter la politique compilée spécifique à l’équipement (ce que chaque WAN Edge recevra). Confirmez la logique de correspondance/action, les actions par défaut et les directions.
• Simulation : Utilisez la simulation de politique pour tester les correspondances de flux et les actions attendues (par ex., quel TLOC une application/5-tuple donné utilisera). Validez les mappages de classes de SLA et la classification des applications.
• Déploiement échelonné :
  • 1. Attacher à une liste de sites canaris (quelques sites).
  • 2. Surveiller les KPI du plan de contrôle et du plan de données (comptages de routes OMP, BFD, correspondances app-route).
  • 3. Étendre la liste de sites de manière incrémentale.
• Gestion des versions et restauration (rollback) : Conservez les versions antérieures de la politique ; si un comportement inattendu est détecté, désactivez rapidement la nouvelle politique ou revenez à la version précédente.

Débogage des résultats inattendus et de la précédence :

• Vérification du plan de contrôle

  • show omp tlocs, show omp routes : Confirmer la présence/absence de routes et de TLOCs conformément à l’intention de la politique.
  • show policy received/installed : Vérifier les compteurs de la politique de contrôle et quelles séquences ont correspondu.
  • Symptôme : Les sites spoke ne peuvent pas atteindre les autres après le déploiement → vérifier les lignes deny de la politique de contrôle sortante vers les spokes et les actions par défaut.

• Vérification du plan de données et de l’AAR

  • show app-route stats/flows et show bfd sessions : Valider l’état du SLA et les décisions de chemin.
  • show sdwan policy service-path ou équivalent : Confirmer les compteurs d’insertion de service et l’ordre de chaînage.
  • show ip route vpn X et traceroute vpn X : Vérifier le chemin de transfert réel.
  • Symptôme : Changements de chemin inattendus/instabilité (flapping) → assouplir le SLA ou ajuster les multiplicateurs de sondes ; s’assurer qu’une politique de données qui se chevauche ne définit pas également le TLOC.

• Précédence et conflits de politiques

  • Les décisions AAR ont généralement la précédence pour la sélection de chemin ; utilisez la politique de données principalement pour l’insertion de services, le marquage et le contrôle d’accès.
  • Des critères de correspondance qui se chevauchent entre les politiques peuvent créer une ambiguïté. Gardez les domaines de correspondance mutuellement exclusifs ou introduisez un ordre et des balises (tags) pour lever l’ambiguïté.
  • Une action par défaut accept peut masquer des séquences manquantes ; ajoutez des compteurs explicites en “observation seule” (par ex., mirror/police low) ou une journalisation temporaire pour valider les correspondances avant d’appliquer des deny.

• Validation cflowd

  • show cflowd statistics/exporters : S’assurer que les exportateurs par VPN sont actifs et que l’échantillonnage fonctionne comme prévu.
  • CPU élevé après l’activation de cflowd → augmenter l’intervalle d’échantillonnage ou limiter aux VPN/applications essentiels.

Scénario de Problème Pratique

Northwind Traders migre vers Cisco SD-WAN et doit appliquer une topologie hub-and-spoke pour les VPN PCI, orienter Office 365 vers le meilleur chemin Internet, et insérer un service de pare-feu régional pour le trafic invité sans impacter les applications critiques.

Approche :

1. Construire les listes de politiques

   • Créer des listes de sites : HUBS (datacenters), SPOKES (agences).
   • Créer des listes de VPN : PCI_VPN, GUEST_VPN, CORP_VPN.
   • Créer des listes d’applications : O365, BEST_EFFORT.
   • Créer des listes de couleurs : PRIVATE (mpls), DIA (biz-internet, public-internet). Justification : Les listes réutilisables permettent une portée précise et un déploiement échelonné sécurisé ; la séparation des VPN soutient la segmentation.

2. Définir les classes de SLA

   • GOLD : perte 0,5 %, latence 100 ms, gigue 20 ms.
   • SILVER : perte 1 %, latence 150 ms, gigue 30 ms. Justification : Aligner les seuils sur les performances de transport réalistes pour éviter l’instabilité des chemins (path flapping) ; plus stricts pour O365 que pour le best-effort.

3. Implémenter la politique de contrôle pour le hub-and-spoke PCI

   • En entrée vers vSmart : marquer (tag) les routes apprises des SPOKES dans le PCI_VPN.
   • En sortie de vSmart : vers les SPOKES, annoncer les routes des HUBs et les routes par défaut ; refuser l’annonce des routes PCI originaires des SPOKES aux autres SPOKES ; vers les HUBS, tout annoncer. Justification : La topologie est appliquée au niveau du plan de contrôle, garantissant que les spokes n’apprennent les routes les uns des autres qu’à travers les hubs et préservant la segmentation dans le VPN PCI.

4. Créer une politique app-route pour O365 et best-effort

   • Faire correspondre O365 dans le CORP_VPN avec le SLA GOLD ; couleur préférée DIA avec un repli (fallback) sur PRIVATE.
   • Faire correspondre BEST_EFFORT avec SILVER ; couleur préférée PRIVATE avec un repli sur DIA. Justification : O365 fonctionne mieux sur un accès Internet direct lorsque le SLA est respecté ; basculer sur MPLS si nécessaire. Le trafic best-effort peut préférer MPLS pour des raisons de coût/politique tout en autorisant un repli sur DIA.

5. Insérer un pare-feu régional pour le trafic invité

   • Politique de données dans le GUEST_VPN : insertion de service vers la chaîne de services du pare-feu régional dans les deux directions, aller (côté service vers WAN) et retour (tunnel vers service).
   • S’assurer que la santé du service de pare-feu est surveillée ; définir un fail-open (basculement en mode ouvert) pour le cas d’usage invité afin de préserver la disponibilité. Justification : L’inspection stateful nécessite un parcours symétrique ; l’insertion bidirectionnelle évite les coupures de session. La tolérance au risque pour les invités permet un fail-open si le service est en panne.

6. Attacher les politiques via vSmart avec un déploiement échelonné

   • Attacher la politique de contrôle aux HUBS et à un sous-ensemble canari de SPOKES dans le PCI_VPN.
   • Attacher les politiques app-route et de données d’abord à une région limitée. Justification : Limite le rayon de l’impact (blast radius) ; valide le comportement de la politique avant une expansion globale.

7. Valider et surveiller

   • Prévisualiser les politiques compilées par équipement ; confirmer les actions par défaut.
   • Utiliser la simulation pour tester des exemples de flux (O365 depuis une agence du CORP_VPN, trafic web invité depuis le GUEST_VPN).
   • Surveiller show omp routes/tlocs (joignabilité PCI), show app-route stats (chemin O365), show policy service-path (compteurs du pare-feu invité), et les sessions BFD. Justification : Confirme que les résultats des plans de contrôle et de données correspondent à la conception, et que le pilotage basé sur le SLA fonctionne comme prévu.

8. Étendre et renforcer

   • Ajouter progressivement les SPOKES restants à l’attachement de la politique de contrôle.
   • Resserrer la politique invité avec des limites de débit (rate limits) ; ajuster les seuils du SLA pour O365 si des oscillations de chemin se produisent. Justification : L’ajustement itératif réduit le risque opérationnel et assure une expérience utilisateur stable.

Cette séquence sépare nettement le contrôle de la topologie (OMP) du pilotage et des services du plan de données, utilise la segmentation pour protéger PCI, applique le routage applicatif basé sur le SLA pour la performance, et maintient la sécurité opérationnelle grâce à la prévisualisation, la simulation et l’attachement échelonné.

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

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