Cisco 300-415: Tunnels du plan de données, BFD et routage sensible aux applications — 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 sépare le plan de contrôle du plan de données et construit un overlay chiffré et piloté par des politiques sur des transports hétérogènes. Le contrôleur vSmart gère le plan de contrôle de l’overlay et la connectivité des WAN Edge, distribuant les routes, les clés de sécurité et les intentions via OMP. Les routeurs WAN Edge forment des tunnels de plan de données IPsec sécurisés vers d’autres WAN Edges, tandis que les connexions de contrôle vers vSmart, vBond et vManage utilisent DTLS par défaut (ou TLS). La vivacité et la qualité des chemins sont mesurées en continu avec BFD, ce qui alimente les politiques de routage applicatif (AAR) pour diriger les applications vers les tunnels les plus performants selon des classes de SLA basées sur la perte, la latence, la gigue ou le MOS.

Fondamentaux de l’overlay et du plan de données

• Plan de contrôle versus plan de données

  • Plan de contrôle : Les WAN Edges établissent des connexions de contrôle DTLS/TLS sécurisées vers vBond (pour la traversée NAT et l’orchestration), vSmart (échange de politiques et de routes via OMP) et vManage (gestion, configuration des appareils et stockage des certificats). À l’état de préparation (« staging »), les appareils forment des connexions de contrôle mais n’établissent pas de tunnels de données.
  • Plan de données : Les WAN Edges forment des tunnels IPsec directement vers d’autres WAN Edges pour le trafic utilisateur. Le plan de données est responsable de la transmission et applique les décisions d’ingénierie de trafic communiquées via les politiques du plan de contrôle.

• Tunnels de plan de données IPsec et TLOCs

  • Un Transport Locator (TLOC) identifie de manière unique une connexion de transport WAN et est défini par le tuple {system-IP, color, encapsulation}. L’encapsulation est IPsec ou GRE ; dans la plupart des déploiements et sur IOS XE SD-WAN (cEdge), IPsec est utilisé.
  • Les « colors » (couleurs) sont des étiquettes sémantiques pour les types d’underlay et les propriétés NAT (par exemple, mpls, biz-internet, public-internet, lte, private1–private6). Les « public colors » impliquent généralement une traversée NAT avec l’aide de vBond.
  • Des tunnels se forment entre chaque paire de TLOCs joignables, sauf si l’attribut « restrict » est utilisé. Avec deux sites, chacun ayant un WAN Edge et deux TLOCs publics, et sans attributs « restrict », quatre tunnels IPsec se forment (maillage complet entre les paires de couleurs).
  • L’extension TLOC permet à deux WAN Edges redondants sur un site de partager des transports via une liaison croisée (« cross-link »), offrant une redondance de transport sans dupliquer les circuits physiques par châssis.

• Étiquettes de transport et de service

  • vSmart utilise OMP pour annoncer les routes et les TLOCs et pour allouer des étiquettes transportées dans l’en-tête de l’overlay. Les étiquettes de transport identifient les TLOCs distants pour le démultiplexage du trafic à travers l’overlay. Les étiquettes de service identifient le VPN de service de destination ou un service en chaîne. Ces étiquettes sont internes à l’overlay SD-WAN et ne sont pas des étiquettes de l’underlay MPLS.

• Compromis opérationnels et modes de défaillance

  • Des transports mal « colorés » (par exemple, marquer un transport MPLS comme public-internet) peuvent entraîner une formation de tunnel sous-optimale ou des échecs de traversée NAT.
  • L’attribut « restrict » empêche la croissance non désirée du maillage complet ; l’omettre sur les couleurs internet peut conduire à une mise à l’échelle excessive des tunnels et à une surcharge de sondage inutile.
  • Des problèmes de certificat ou d’horloge empêchent la connectivité du plan de contrôle (DTLS/TLS). Sans convergence du plan de contrôle vers vSmart, aucune clé de plan de données n’est échangée et les tunnels IPsec ne se forment pas.

Mesure de la vivacité et de la qualité des chemins avec BFD

• Fonctionnement de BFD

  • Cisco SD-WAN exécute BFD sur chaque tunnel de plan de données pour fournir une détection de vivacité et une mesure de qualité quasi en temps réel. BFD utilise des « hellos » périodiques légers pour détecter l’état up/down (blackouts) et des sondes actives pour mesurer la latence, la gigue et la perte (brownouts).
  • Temporisateurs et intervalles clés
    • Intervalle Hello : généralement 1000 ms (configurable par couleur ou globalement).
    • Multiplicateur : généralement 6 (configurable), donnant un temps de détection de intervalle-hello × multiplicateur (par exemple, ~6 secondes).
    • Intervalle de sonde applicative (App-probe) pour l’échantillonnage de performance AAR : typiquement 1 seconde (configurable), avec des moyennes glissantes calculées sur une courte fenêtre pour lisser les pics transitoires.
  • Mesures BFD
    • Latence : temps aller-retour des sondes sur chaque tunnel.
    • Gigue : variation de la latence entre les sondes.
    • Perte : pourcentage de sondes non retournées.
    • MOS : dérivé de la latence, de la gigue et de la perte pour évaluer l’adéquation à la voix.

• Gestion des brownouts versus blackouts

  • Blackout : Une session BFD inactive (pas de connectivité) déclenche le retrait immédiat du chemin de la table de transfert. Le trafic est basculé selon la préférence du prochain tunnel disponible sans attendre l’évaluation AAR.
  • Brownout : La session BFD reste active, mais les métriques mesurées violent les seuils de SLA. AAR peut diriger des flux applicatifs spécifiques vers des tunnels alternatifs qui respectent les SLAs, même si le tunnel d’origine continue de transporter d’autre trafic.

• Recommandations de conception et compromis

  • Des temporisateurs agressifs accélèrent le basculement mais augmentent la charge CPU et la consommation de bande passante, en particulier dans les grands maillages. Équilibrez les intervalles de « hello » et de sonde en fonction de la mise à l’échelle et de la stabilité du transport.
  • Les caractéristiques de chemin asymétriques (par exemple, satellite ou cellulaire) exigent des seuils de SLA plus souples et des multiplicateurs potentiellement plus élevés pour éviter le battement (« flapping »).
  • Pour la voix et les applications interactives, préférez des intervalles de sonde applicative plus rapides et activez l’hystérésis/hold-down pour réduire l’oscillation pendant les congestions transitoires.

Routage sensible aux applications : Conception des politiques et des SLA

• Identification et classification des applications

  • Les périphériques WAN Edge utilisent le DPI (NBAR2 sur IOS XE SD-WAN) pour classifier les applications par signatures, heuristiques de protocole et, si disponibles, métadonnées telles que TLS SNI et QUIC ALPN. Pour le trafic chiffré sans métadonnées identifiables, le moteur se rabat sur les attributs de flux (5-uplet) et les mappages configurés (ports, DSCP).
  • La classification s’effectue généralement sur les premiers paquets et est mise en cache pour assurer la cohérence de la session. Maintenez les signatures à jour pour préserver la précision.

• Classes de SLA et politique de mesure

  • Définissez des classes de SLA avec des seuils de perte, de latence, de gigue et éventuellement de MOS. Chaque classe de SLA référence un profil de sonde de performance (app-probe) qui pilote l’intervalle d’échantillonnage et le comportement de lissage de BFD.
  • Exemples de SLA typiques :
    • Voix : latence ≤ 150 ms, gigue ≤ 30 ms, perte ≤ 1 %, MOS ≥ 4.0.
    • Transactionnel : latence ≤ 200 ms, perte ≤ 1 %.
    • En vrac : pas de SLA strict ; préférer les chemins à plus large bande passante et à moindre coût.

• Comportement de préférence de chemin

  • La politique AAR lie les listes d’applications aux classes de SLA et spécifie une couleur préférée (preferred-color) et une couleur de secours (backup-color) (ou des listes de TLOC). La logique de décision est la suivante :
    1. Si le chemin préféré respecte le SLA, le trafic est envoyé sur ce chemin.
    2. Si le chemin préféré viole le SLA mais que le chemin de secours le respecte, le trafic est dirigé vers le chemin de secours.
    3. Si aucun chemin ne respecte le SLA, utiliser le meilleur chemin disponible par préférence ou par coût (dégradation progressive).
  • Le pilotage en cas de dégradation (brownout) se fait par flux ; les flux existants peuvent être déplacés en fonction de la politique (le pilotage des nouveaux flux est le comportement par défaut ; le déplacement en cours de flux peut être limité pour TCP à moins qu’une résilience de session ne soit conçue).

• Éléments de construction de la politique

  • Construisez des listes d’applications (groupes DPI), des classes de SLA (perte/latence/gigue/MOS) et des listes de TLOC (couleurs) dans vManage. Créez ensuite une séquence de politique AAR mappant liste d’applis → classe de SLA → couleurs préférées/de secours.
  • Combinez avec des politiques de données de trafic (traffic data policies) si vous devez définir le DSCP, appliquer des zones ou insérer un chaînage de services avant les décisions AAR.
  • Utilisez une politique de contrôle (control-policy) distincte pour influencer l’acceptation/l’annonce des routes ; ne confondez pas l’AAR (data-policy) avec la politique de contrôle (control-policy). Les listes de sites définissent la portée d’application de l’AAR.

• Compromis de conception

  • Des SLA trop stricts peuvent provoquer des oscillations. Introduisez une hystérésis ou des temporisateurs de pénalité pour éviter les changements de chemin fréquents.
  • Tenez compte du coût : ne placez les chemins cellulaires facturés à l’usage qu’en tant que secours de dernier recours ; activez les plafonds de données si disponibles.
  • Coordonnez avec la QoS : l’AAR choisit le chemin ; la QoS et la mise en file d’attente par chemin doivent toujours protéger les classes critiques pendant la congestion.

Vérification et Dépannage

• Contrôles de santé rapides

  • Plan de contrôle :
    • cEdge : show sdwan control connections
    • vEdge : show control connections
  • Tunnels du plan de données :
    • cEdge : show sdwan tunnels
    • vEdge : show ipsec outbound-connections / show ipsec inbound-connections
  • Sessions et qualité BFD :
    • cEdge : show sdwan bfd sessions; show sdwan app-route stats
    • vEdge : show bfd sessions; show app-route stats

• Exemples d’extraits de commandes

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• Ce qu’il faut rechercher

  • L’état du tunnel est up, mais la perte/latence/gigue BFD dépasse le SLA : brownout—attendez-vous à un routage AAR. Validez que le chemin de secours respecte le SLA et que la politique lie la bonne liste d’applications.
  • Instabilité de la session BFD : réduisez l’agressivité ou enquêtez sur les pertes/mises en file d’attente de l’underlay ; vérifiez le MTU et la fragmentation (gestion du bit DF) pour éviter la perte de sondes.
  • Aucun tunnel formé sur une couleur : vérifiez la sémantique de couleur NAT/public/privé, la configuration NAT de l’interface, et que vBond est joignable pour la traversée NAT. Confirmez l’heure et les certificats si les connexions de contrôle sont absentes.
  • Maillage complet et échelle de sondes inattendus : appliquez une restriction sur les couleurs internet ou utilisez des listes TLOC pour délimiter la connectivité.
  • Erreur de classification DPI : mettez à jour les signatures NBAR2 et confirmez l’absence de substitutions de port L4 conflictuelles. Pour les applications chiffrées, envisagez une classification basée sur SNI/ALPN ou un marquage DSCP en amont.

• Raisonnement opérationnel

  • Validez toujours la connectivité du plan de contrôle en premier (vBond pour l’orchestration/NAT, vSmart pour OMP/politique, vManage pour la configuration/certificats). Sans vSmart, les clés du plan de données ne sont pas distribuées, et aucune SA IPsec ne se forme.
  • Corrélez les décisions AAR avec les mesures BFD et les classes de SLA. Si un chemin est sélectionné contrairement aux attentes, inspectez l’état de conformité au SLA au moment de la décision, pas seulement les moyennes actuelles.
  • Pour les conceptions à double DC, évitez les routes LAN en double en harmonisant l’AS de l’overlay sur les WAN Edges des DC lors de la redistribution OMP↔BGP à travers une interconnexion de DC.

Scénario de problème pratique

Contoso Health exploite 300 cliniques avec deux transports sur chaque site : MPLS (couleur mpls) et haut débit (couleur biz-internet). Les utilisateurs signalent une qualité vocale médiocre et intermittente, tandis que les applications de données fonctionnent bien. L’objectif est de privilégier le MPLS pour la voix, de basculer sur le haut débit pendant les brownouts, et d’assurer un basculement rapide en cas de blackout sans oscillation.

1. Valider la santé de l’overlay et la formation du plan de données

• Justification : Confirmer les prérequis. Utilisez show sdwan control connections pour s’assurer que DTLS/TLS vers vSmart/vBond/vManage est stable et show sdwan tunnels pour vérifier le maillage complet des tunnels MPLS et haut débit. Si des tunnels sur biz-internet sont manquants, vérifiez l’assignation de couleur et le NAT ; vBond doit être joignable dans l’espace public pour aider à la traversée NAT.

2. Calibrer les minuteurs BFD et de sondes

• Justification : Réglez le hello BFD à 1000 ms, multiplicateur 6 pour une détection de vivacité équilibrée (~6 s) et une échelle raisonnable. Configurez l’intervalle des sondes d’application (app-probe) à 1 s pour une détection opportune des brownouts. Des minuteurs excessivement agressifs peuvent causer une surcharge CPU et de l’instabilité ; des réglages trop lâches entravent la réactivité pour la voix.

3. Définir les classes de SLA

• Justification : Créez une classe de SLA Voice-SLA avec une latence ≤ 150 ms, une gigue ≤ 30 ms, une perte ≤ 1%, un MOS ≥ 4.0. Créez une classe Data-SLA avec une latence ≤ 200 ms, une perte ≤ 1%. Ces seuils reflètent la sensibilité de la voix et la performance WAN typique ; le MOS consolide l’expérience utilisateur à travers plusieurs métriques.

4. Construire les listes d’applications

• Justification : Utilisez DPI (NBAR2) pour définir App-List-Voice pour les médias SIP/RTP/Teams/Zoom et App-List-Data pour les applications transactionnelles. Incluez les motifs TLS SNI/QUIC ALPN pour les plateformes voix/vidéo modernes. Lorsque la classification est incertaine, se rabattre sur les marquages DSCP EF/AF41 appliqués à la périphérie du LAN.

5. Construire la politique AAR

• Justification : Associez App-List-Voice à Voice-SLA avec preferred-color mpls et backup-color biz-internet. Associez App-List-Data à Data-SLA avec preferred-color biz-internet et backup-color mpls pour préserver la bande passante MPLS. Cela garantit que la voix utilise le MPLS lorsqu’il est sain et bascule sur le haut débit uniquement pendant les brownouts ou les blackouts, tandis que les données privilégient l’internet économique.

6. Ajouter une hystérésis et un hold-down

• Justification : Configurez un minuteur de retour (revert timer) pour que la voix ne revienne au MPLS qu’après une conformité au SLA soutenue (par exemple, 30–60 s). Cela évite l’oscillation pendant les pics de gigue transitoires. De même, appliquez une pénalité ou un amortissement sur le haut débit s’il viole le SLA de manière répétée dans une courte fenêtre de temps.

7. Coordonner la QoS et le MTU

• Justification : Sur les deux transports, assurez-vous que la mise en file d’attente EF et le shaping s’alignent sur les débits du circuit. Un décalage peut gonfler la gigue/perte vue par les sondes BFD et la voix RTP. Validez le MTU du chemin et désactivez DF là où la fragmentation est inévitable, empêchant les pertes de sondes qui se font passer pour de la perte de paquets.

8. Vérifier et itérer

• Justification : Utilisez show sdwan app-route stats sla-class Voice-SLA pour confirmer la réussite/échec du SLA par tunnel. Observez les flux en direct avec show sdwan app-route statistics flows pour s’assurer que la voix est dirigée vers le MPLS et bascule sur le haut débit uniquement lorsque le MPLS viole le SLA. Pendant les tests, congestionnez intentionnellement le MPLS pour valider le comportement en cas de brownout, puis mesurez le temps de retour.

En suivant ces étapes, Contoso Health s’assure que BFD fournit une détection rapide des blackouts, que AAR réagit aux brownouts en utilisant des classes de SLA précises, et que DPI classifie avec précision les applications vocales. La combinaison produit une qualité vocale prévisible, une utilisation efficace des transports et un comportement de basculement contrôlable à travers la fabrique SD-WAN.

← Configuration des WAN Edge et gestion des modèles · Tous les domaines · Politique centralisée et ingénierie du trafic →

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