Cisco 300-415: Qualité de service et services de multidiffusion — 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

Les services de qualité de service (QoS) et de multicast dans Cisco SD-WAN sont conçus pour préserver l’expérience applicative sur divers transports tout en permettant une distribution évolutive et basée sur des politiques du trafic en temps réel et de groupe. La QoS assure la priorité, la mise en forme (shaping) et l’utilisation équitable de la bande passante par application et par tunnel d’overlay ; le multicast permet une réplication efficace et contrôlée par des politiques des flux pour les récepteurs sur différents sites. Ensemble, ils traduisent l’intention (la voix/vidéo doit être protégée contre la perte et la gigue ; les applications critiques doivent respecter les SLA) en un comportement cohérent du plan de données, coordonné par le plan de contrôle SD-WAN (vSmart) et appliqué au niveau des périphériques WAN Edge.

Architecture QoS, files d’attente, ordonnancement, mise en forme, contrôle de débit et allocation de bande passante

La QoS dans Cisco SD-WAN est hiérarchique et sensible au transport :

• Classification : Identifier les flux par champs (L3/L4), DSCP, signatures applicatives (NBAR2 sur IOS XE SD-WAN), ou contexte de VPN et de préfixe.
• Marquage : Définir ou préserver le DSCP côté service, le réécrire si nécessaire pour les contraintes du WAN, et le mapper aux files d’attente de sortie via des mappes QoS.
• Mise en file d’attente et ordonnancement : Les interfaces de sortie implémentent plusieurs files d’attente matérielles/logicielles avec une file d’attente à faible latence et à priorité stricte (LLQ) pour le trafic en temps réel et des ordonnanceurs pondérés (WFQ/WRR/CBWFQ) pour les autres classes.
• Mise en forme (shaping) : Lisser le trafic de sortie à un débit configuré (par interface, par sous-interface ou par tunnel) pour éviter les policers du fournisseur et absorber les rafales.
• Contrôle de débit (policing) : Limiter le débit et éventuellement remarquer ou rejeter le trafic non conforme en entrée ou en sortie ; utilisé avec parcimonie pour éviter les ralentissements applicatifs (brownouts).
• Allocation de bande passante : Réserver une bande passante minimale (garanties) par classe et plafonner les maximums si nécessaire ; s’assurer que la LLQ a un plafond strict et explicite pour éviter l’inanition des autres files d’attente.

Conseils de conception et compromis :

• Mettre en forme (shape) à un débit sûr, inférieur au policer effectif du FAI. Pour les circuits Internet variables, 90 à 95 % de la bande passante nominale est un point de départ pratique ; ajuster en fonction des rejets et de la latence observés en charge.
• La profondeur de la file d’attente (mise en tampon) doit équilibrer le délai par rapport à la perte. Dimensionner à environ une fraction du produit bande passante-délai ; une taille trop petite provoque des rejets en fin de file (tail drop) ; une taille trop grande augmente la latence pour les classes inférieures.
• Utiliser la LLQ uniquement pour les flux de contrôle voix/vidéo courts et à débit constant ; ne pas placer de flux vidéo à haut débit dans la LLQ — les assigner à une file d’attente pondérée de haute priorité avec un plafond de bande passante clair.
• Préférer la mise en forme (shaping) au contrôle de débit (policing) en sortie. Appliquer des policers pour les contrats de débit explicites ou le trafic d’entrée non fiable.
• Sur les liens physiques partagés transportant plusieurs overlays, activez la QoS par tunnel (PTQ) afin que chaque tunnel sécurisé basé sur BFD reçoive son propre ordonnanceur/shaper, empêchant un seul overlay très sollicité de monopoliser le lien.
• Une politique spécifique au transport (sensible à la couleur/au TLOC) permet d’avoir des mappes QoS, des shapers et des garanties de classe distincts par underlay (par exemple, un shaping plus strict et un ensemble de DSCP réduit sur Internet par rapport à des classes plus riches sur MPLS).

QoS par tunnel et spécificités du transport :

• La PTQ virtualise l’ordonnancement de sortie par tunnel IPsec/DTLS/TLS afin que les garanties et les plafonds s’appliquent par chemin, et non seulement par interface. C’est essentiel lorsqu’un périphérique Edge forme plusieurs tunnels sur la même interface (par ex., des régions vSmart/vBond doubles ou plusieurs pairs distants).
• Assigner différentes mappes QoS par couleur (biz-internet, mpls, lte) pour respecter les listes blanches DSCP du fournisseur et éviter un remarquage inattendu (par ex., regrouper les classes AF dans la classe par défaut sur le haut débit).

Classification et marquage avec DSCP, mappes QoS et gestion de la congestion

La classification de confiance commence à la périphérie du VPN de service :

• Frontières de confiance : Si le domaine d’accès LAN n’est pas compatible avec la QoS, classifiez et marquez au niveau du WAN Edge en utilisant l’ID d’application L7 ou les tuples L3/L4. Si le LAN est compatible avec la QoS, auditez et préservez le DSCP tout en le normalisant vers une mappe QoS WAN.
• Stratégie DSCP : EF pour la voix interactive, AF41/42 pour la vidéo, AF31/AF21 pour les données critiques, les classes CS3/AF pour la signalisation, CS0/DF pour le best effort, et CS1 (ou LE) pour le scavenger. Aligner avec les valeurs acceptées par le fournisseur.
• Mappe QoS : Mapper le DSCP à une file d’attente et éventuellement le réécrire en sortie ; maintenir un mappage un-à-un ou plusieurs-à-un qui respecte les limites de l’underlay.

Bref exemple de vérifications utiles en production :

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

Gestion de la congestion et dimensionnement des files d’attente :

• Commencer avec une LLQ de petite taille et plafonnée pour EF (par exemple, 10 % du débit mis en forme) et appliquer un contrôle de débit (policing) au sein de la LLQ pour empêcher le dépassement par des flux mal marqués.
• Allouer la bande passante restante en utilisant des poids WRR/CBWFQ alignés sur la priorité métier (par ex., 30 % de données critiques, 20 % de vidéo, 35 % de best effort, 5 % de scavenger).
• Envisager d’activer le rejet anticipé (WRED) pour les classes de trafic de masse lorsque la plateforme le supporte afin d’éviter la synchronisation globale ; ne pas activer le rejet anticipé sur la LLQ ou les petites files d’attente de contrôle.

Modes de défaillance à surveiller :

• Le remarquage par l’opérateur regroupe les DSCP, plaçant le trafic en temps réel dans la classe best effort ; le résultat est de la gigue et de la perte de paquets pendant les pics de trafic. Vérifier avec des captures de paquets et les profils QoS du fournisseur.
• Des shapers mal dimensionnés entraînent des rejets en fin de file (tail drops) persistants ; l’inanition de la LLQ se produit si elle n’est pas plafonnée ou si la vidéo inonde la LLQ.
• L’absence de PTQ sur une interface partagée fait que les overlays « voisins bruyants » consomment la bande passante et dégradent les tunnels critiques.

Priorisation des applications, intention métier et application des SLA

Cisco SD-WAN exprime l’intention applicative via une politique centralisée sur le contrôleur vSmart, qui gère le plan de contrôle de l’overlay et distribue les politiques aux WAN Edges. Le routage applicatif (Application-Aware Routing ou AAR) dirige le trafic en fonction de la perte, de la latence et de la gigue mesurées par transport et par tunnel à l’aide de BFD. Pour l’optimisation du SaaS, Cloud OnRamp peut intégrer la perte et la latence basées sur HTTP vers l’application, en plus des métriques BFD vers un site de passerelle.

Meilleures pratiques :

• Définir des listes d’applications et des classes de SLA par criticité métier :
  • VOIX : EF, cible <150 ms unidirectionnel, <30 ms de gigue, <1% de perte ; diriger uniquement sur les chemins respectant ces seuils.
  • VIDÉO : AF4x, gigue/perte légèrement plus tolérantes que pour la voix ; préférer les chemins à large bande passante et à faible perte.
  • DONNÉES CRITIQUES : AF3x/AF2x ; limiter la perte et la latence selon les exigences de l’application.
• Utiliser une politique centralisée pour le routage applicatif (AAR) afin de préférer les chemins qui respectent le SLA par classe ; basculer sur des chemins secondaires en cas de dégradation.
• Combiner l’AAR avec une QoS par transport : un chemin sélectionné doit avoir des ressources réservées pour la classe ; sinon, le trafic peut respecter le SLA du chemin mais être tout de même mis en file d’attente ou abandonné en sortie (egress).
• Pour le SaaS via un site de passerelle, valider les deux :
  • La perte/latence HTTP vers le point de terminaison SaaS.
  • La perte/latence BFD vers le site de passerelle.
• Assurer la préservation du DSCP de bout en bout ; en sortie, ne réécrire que lorsque les underlays l’exigent, et restaurer les marquages si l’extrémité distante leur fait confiance.

Vérifications opérationnelles :

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

Pièges courants :

• Des seuils de SLA trop stricts provoquent des battements de chemin (path flapping) ; introduire une hystérésis et des temporisateurs de maintien (hold timers).
• Un manque de bande passante pour une classe sur le chemin choisi entraîne une congestion auto-infligée ; aligner les choix de l’AAR avec la capacité de la QoS par transport.
• Une mauvaise classification (par ex., la voix découverte comme ‘best effort’) due à des charges utiles chiffrées ou à des signatures NBAR manquantes ; utiliser la confiance DSCP (DSCP trust) ou des correspondances L4 explicites comme solution de repli.

Principes fondamentaux de la multidiffusion et conception de la multidiffusion en overlay

La multidiffusion sur SD-WAN (Multicast over SD-WAN) découple le plan de contrôle de la multidiffusion du LAN des contraintes de l’underlay :

• Principes fondamentaux :
  • Les récepteurs signalent leur intérêt avec IGMPv2/v3 vers le routeur LAN de premier saut (le WAN Edge dans le VPN de service).
  • Le mode PIM Sparse est recommandé dans le VPN de service ; les points de rendez-vous (RP) orchestrent les jonctions initiales.
• Plan de contrôle de l’overlay :
  • Les routeurs WAN Edge créent des routes de service de multidiffusion vers le contrôleur vSmart via OMP.
  • Le contrôleur vSmart, agissant dans le rôle d’annonceur de réplicateur/RP de multidiffusion, propage les informations du RP à travers l’overlay et transmet les demandes de jonction (joins) pour les groupes demandés vers la source ou le PIM-RP, comme spécifié dans le message de jonction PIM d’origine.
  • vSmart sélectionne un ou plusieurs WAN Edges comme réplicateurs de plan de données. L’Edge côté source envoie une seule copie au réplicateur, qui la réplique ensuite vers les Edges récepteurs, minimisant ainsi l’utilisation de la bande passante sur les liaisons à capacité limitée.
• Plan de données :
  • La réplication s’effectue sous forme de paquets unicast chiffrés à travers les tunnels de l’overlay ; les frontières du VPN de service sont préservées (la multidiffusion est par VPN/VRF).
  • La multidiffusion inter-VPN n’est pas automatique ; si nécessaire, utilisez un chaînage de services (service-chaining) explicite ou des passerelles de couche applicative.

Considérations de conception et compromis :

• Placez le RP logiquement à proximité des sources ou des datacenters centraux. Dans un overlay SD-WAN, fiez-vous à vSmart pour annoncer le RP aux récepteurs, garantissant des jonctions cohérentes.
• Activez la multidiffusion uniquement dans les VPN où elle est nécessaire ; limitez le débit du trafic de contrôle des récepteurs (IGMP) pour protéger le CPU.
• Sur les liaisons à faible bande passante, centralisez la réplication sur un hub/réplicateur disposant d’une capacité suffisante pour éviter la réplication N×flux sur les circuits d’accès.
• Validez la MTU pour éviter la fragmentation des flux à haut débit ; envisagez de modeler (shaping) les classes vidéo indépendamment des files d’attente du plan de contrôle.

Modes de défaillance :

• L’absence d’un querier IGMP sur le LAN entraîne le vieillissement des groupes et la perte de flux ; assurez-vous que le WAN Edge ou un commutateur LAN agisse en tant que querier.
• Une non-concordance de RP ou un filtrage dans la politique centralisée interrompt les jonctions ; confirmez l’accessibilité du RP à travers l’overlay.
• Un trafic de contrôle de multidiffusion excessif composé de petits paquets peut être confondu avec une attaque DDoS ; limitez le débit et surveillez les files d’attente de contrôle.
• Des frontières de VPN de service mal spécifiées entraînent une non-livraison ; la multidiffusion ne traverse pas les VPN à moins d’une ingénierie explicite.

Essentiels du dépannage :

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

Corrélez les rejets de file d’attente (queue drops) avec les KPI applicatifs ; pour la multidiffusion, assurez-vous que les jonctions IGMP sont vues au niveau de l’Edge, que les routes de service OMP existent et que le réplicateur choisi est joignable via un tunnel sain.

Scénario de problème pratique

NorthRiver Health exploite 120 cliniques avec deux transports (MPLS et Internet). Des plaintes font état d’une voix hachée, d’une vidéo de télémédecine pixélisée et d’une multidiffusion IPTV intermittente dans les salles d’attente.

Approche :

1. Établir les frontières de confiance et classifier le trafic

• Justification : Une classification précise est un prérequis à la priorisation. Préserver le DSCP des domaines LAN conformes ; en son absence, classifier par application (NBAR2) et tuples L4, en mappant la voix sur EF, la vidéo sur AF41, et les DME (Dossiers Médicaux Électroniques) critiques sur AF31.

2. Créer des cartes QoS et des shapers spécifiques au transport

• Justification : MPLS respecte AF/EF, ce qui n’est souvent pas le cas d’Internet. Configurer des cartes QoS par couleur : jeu de classes complet sur MPLS ; classes regroupées sur Internet avec préservation de EF et AF4. Modeler (shaper) le trafic MPLS à 95% du CIR et Internet au débit durable mesuré pour éviter les policeurs du fournisseur.

3. Activer la QoS par tunnel sur les interfaces WAN partagées

• Justification : Plusieurs overlays partagent la même liaison physique. La PTQ (Per-Tunnel QoS) empêche un tunnel site-à-cloud chargé d’affamer les tunnels voix/vidéo site-à-datacenter en allouant des planificateurs et des minimums par tunnel.

4. Réserver et plafonner la LLQ pour la voix ; pondérer la vidéo et les données critiques

• Justification : La voix nécessite une latence/gigue bornée ; plafonner la LLQ à 10% pour éviter la privation (starvation). Attribuer 25–30% à la vidéo AF4 avec un maximum strict. Allouer 25% au trafic DME AF3, le reste au meilleur effort (best effort) et au scavenger.

5. Mettre en œuvre une politique AAR centralisée sur vSmart avec des classes de SLA

• Justification : vSmart distribue une politique centralisée qui place la voix/vidéo/DME sur des chemins respectant les objectifs de SLA en utilisant la perte/latence/gigue BFD. Ajouter de l’hystérésis pour éviter les battements (flaps). Pour les modules DSE (Dossier de Santé Électronique) SaaS via une passerelle, inclure la perte/latence HTTP vers le SaaS et BFD vers le site de la passerelle.

6. Déployer la multidiffusion overlay avec la sélection du réplicateur par vSmart

• Justification : Une distribution IPTV efficace nécessite une réplication contrôlée. Activer la multidiffusion dans le VPN IPTV, configurer PIM-SM et le RP, et laisser vSmart annoncer le RP et sélectionner un Edge de datacenter comme réplicateur pour protéger les circuits à faible débit des cliniques de la réplication N-directionnelle.

7. Valider et itérer avec la télémétrie

• Justification : Confirmer le comportement sous charge. Utiliser :
  • show sdwan app-route statistics pour vérifier la sélection de chemin SLA.
  • show policy qos-queue / show policy-map interface pour évaluer l’utilisation des files d’attente et les rejets.
  • show ip igmp groups et show sdwan omp services pour les jonctions de multidiffusion et les routes de service. Ajuster les débits des shapers et les poids des files d’attente pour éliminer les rejets en fin de file (tail drops) pour la voix/vidéo tout en maintenant une latence acceptable pour les données critiques.

8. Garde-fous et gestion des anomalies

• Justification : Prévenir la récurrence et détecter les régressions. Appliquer des policeurs en entrée sur les segments LAN non fiables pour étrangler le trafic mal marqué, limiter le débit IGMP pour protéger le CPU du plan de contrôle, et définir des alertes sur les violations de SLA AAR et les compteurs de rejets de file d’attente pour déclencher une remédiation proactive.

Cette séquence garantit que NorthRiver Health traduit son intention métier en une QoS cohérente et sensible au transport, ainsi qu’en une livraison de multidiffusion fiable. La voix obtient un traitement strict et borné ; la vidéo et les DME reçoivent une bande passante priorisée et pondérée ; les chemins sont sélectionnés par des mesures de SLA en direct ; et la multidiffusion est répliquée efficacement sans surcharger les liaisons des succursales.

← Sécurité · Tous les domaines · Intégration Cloud →

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