Cisco 300-410: Qualité de service et protection du plan de contrôle — Guide d'étude

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fait partie du Cisco CCNP Enterprise 300-410 ENARSI — 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 qualité de service (QoS) et la protection du plan de contrôle (CoPP/CPPr) garantissent ensemble que les applications critiques et le réseau lui-même restent stables en cas de charge élevée et d’attaques. La QoS différencie le trafic, priorise les flux sensibles au délai et gère la congestion sur les liaisons à faible bande passante. Le CoPP/CPPr protège le CPU du routeur et la pile de gestion contre les surcharges accidentelles et les événements malveillants. Une conception correcte repose sur un marquage de bout en bout cohérent, des frontières de confiance disciplinées, un conditionnement approprié (policing/shaping), des files d’attente bien dimensionnées, une prévention proactive de la congestion, un traitement attentif des tunnels/chiffrement et une validation continue à l’aide de compteurs corrélés au comportement des applications.

Classification, confiance et marquage de bout en bout

La classification et le marquage du trafic déterminent comment les paquets seront mis en file d’attente et potentiellement rejetés à chaque saut.

• Classification et correspondance

  • Correspondance sur les listes d’accès, DSCP/IP precedence, CoS (802.1p), les signatures d’application NBAR ou les en-têtes internes de tunnel (avec qos pre-classify).
  • Maintenir le déterminisme : faire correspondre sur les champs de couche 3/4 lorsque c’est possible ; utiliser NBAR uniquement lorsque c’est nécessaire en raison des implications sur le CPU de certaines plateformes.

• Frontières de confiance

  • Définir où le réseau accepte les marquages existants. Typiquement : ne pas faire confiance aux hôtes finaux ; faire confiance aux téléphones d’entreprise et aux liaisons montantes vers des domaines QoS connus.
  • À la périphérie, remarquez le trafic non fiable avec les valeurs DSCP définies par la politique ; ne faites confiance qu’aux appareils que vous gérez et authentifiez.
  • Sur les ports de commutateur vers les terminaux, supprimez la confiance (no trust dscp/cos) à moins de vérifier explicitement le type d’appareil.

• Marquage

  • Le DSCP (6 bits) est le principal marquage de bout en bout dans les réseaux IP. L’IP precedence (3 bits) est un héritage (legacy) et correspond aux bits de poids fort du DSCP.
  • Le CoS (802.1p, 3 bits) marque les trames de couche 2 sur les trunks VLAN ; mappez DSCP↔CoS de manière cohérente aux frontières L2/L3.
  • Dans les cœurs MPLS, la classe de trafic (TC, anciennement EXP) de 3 bits transporte la QoS ; mappez le DSCP vers le TC à l’entrée (ingress) et le TC vers le DSCP à la sortie (egress) pour préserver la sémantique à travers le cœur VPN ou TE.

• Cohérence du marquage

  • Réservez EF pour le trafic voix (faible gigue), CS3/AF31/AF32 pour la signalisation d’appel, AF4x pour la vidéo interactive, AF2x/AF1x pour les données critiques, CS0/BE pour le meilleur effort (best effort) et CS1 pour le trafic de fond (scavenger).
  • Documentez une politique QoS d’entreprise unique ; assurez-vous que les fournisseurs WAN la respectent et effectuent le mappage comme convenu contractuellement.
  • Évitez de remarquer à mi-chemin, sauf pour traduire entre domaines ; sinon, vous risquez une inversion de priorité et une complexité de dépannage accrue.

Exemple (marquage en entrée de périphérie) :

undefined

Modes de défaillance et compromis :

• Faire confiance à la mauvaise périphérie conduit à un abus de priorité ; les flux de faible valeur peuvent affamer les files d’attente critiques.
• Des mappages DSCP↔CoS incohérents cassent la QoS aux transitions L2/L3.
• Une utilisation excessive de NBAR sur les plateformes logicielles peut augmenter l’utilisation du CPU ; préférez les correspondances statiques.

Conditionnement, mise en file d’attente et prévention de la congestion

Le conditionnement du trafic façonne (shapes) le trafic aux débits que le réseau peut supporter et applique un contrôle (policing) là où des limites strictes sont requises.

• Policing vs. shaping

  • Le policing impose un débit à l’aide de seaux à jetons (token buckets) ; l’excédent est rejeté ou optionnellement remarqué. Il préserve la capacité de la liaison mais augmente les pertes et peut déclencher le backoff TCP et des nouvelles tentatives applicatives.
  • Le shaping met en tampon et libère à un débit cible (généralement un CIR d’opérateur) lissant les rafales et réduisant les rejets en aval ; il ajoute un délai et une gigue proportionnels à la profondeur de la file d’attente.

• Paramètres de rafale (Burst)

  • Les policers à débit unique et deux paramètres utilisent un débit d’information garanti (CIR) avec une rafale garantie (Bc) et optionnellement Be (rafale excédentaire).
  • Un Bc trop petit par rapport au RTT et au MTU provoque des rejets au niveau de la fragmentation et un débit inefficace ; dimensionnez Bc à au moins 1 à 2 fois le produit bande passante-délai pour le shaping, et à plusieurs MTU pour le policing.

• CBWFQ et LLQ

  • Le Class-Based Weighted Fair Queuing (CBWFQ) garantit une bande passante minimale aux classes. Configurez la bande passante en kbps ou en pourcentage sous une politique de shape.
  • La Low-Latency Queue (LLQ) ajoute un service à priorité stricte à une classe (priority), contrôlé (policed) au débit configuré pour éviter l’inanition (starvation). Seul le trafic voix/vidéo temps réel devrait être dans la LLQ.
  • Les limites de file d’attente (queue-limit) définissent le nombre maximal de paquets mis en tampon par classe ; une valeur trop élevée augmente la latence, une valeur trop basse augmente les rejets. Équilibrez en fonction de la tolérance de l’application.

• WRED vs. tail drop

  • Le tail drop ne rejette les paquets que lorsque les files d’attente sont pleines ; cela peut provoquer une synchronisation TCP globale et d’importantes oscillations.
  • Le Weighted Random Early Detection (WRED) commence les rejets probabilistes avant que la file ne soit pleine ; le WRED basé sur le DSCP permet aux classes de priorité supérieure de tolérer des files d’attente plus profondes avec une probabilité de rejet précoce plus faible.
  • Le WRED est bénéfique pour les flux TCP ; pour le trafic majoritairement UDP (voix), il ajoute des pertes sans mécanisme de backoff. N’activez pas le WRED dans la LLQ.

Exemple (shaping parent avec CBWFQ/LLQ et WRED enfant) :

undefined

Points de conception clés :

• Faites toujours du shaping au débit du plus petit goulot d’étranglement en aval que vous contrôlez ; laissez votre mise en file d’attente décider, pas le mécanisme de rejet du fournisseur.
• Dimensionnez la LLQ en fonction du codec et du volume d’appels ; incluez 5 à 10 % de surcharge (overhead) pour les en-têtes et la variabilité du VAD.
• N’activez le WRED que là où les flux TCP multiplexés dominent ; ajustez les poids de manière conservatrice pour éviter les rejets prématurés.

QoS sur les tunnels et les liaisons WAN

Les tunnels et le chiffrement masquent les en-têtes internes et modifient la MTU, ce qui affecte la classification et la fragmentation.

• GRE/DMVPN et IPsec

  • Sans traitement spécial, la classification ne voit que les en-têtes externes. Utilisez qos pre-classify sur les interfaces de tunnel pour que l’équipement effectue la classification sur le 5-tuple et le DSCP internes avant l’encapsulation/le chiffrement.
  • Préservez ou copiez le DSCP vers l’en-tête externe pour maintenir le comportement QoS du réseau pendant le transit.
  • Ajustez la MTU et la MSS pour éviter la fragmentation et les échecs de PMTUD ; pour IPsec, la fragmentation après chiffrement (fragmentation after-encryption) peut être requise sur certaines plateformes et certains opérateurs.

• QoS par tunnel et conception hiérarchique

  • Sur mGRE/DMVPN, appliquez une QoS hiérarchique (shaping par tunnel, puis LLQ/CBWFQ par classe) pour garantir un partage équitable entre les spokes.
  • Lorsque les circuits du fournisseur appliquent un CIR avec des policers stricts, effectuez un shaping au niveau du CIR ou légèrement en dessous pour éviter les tail drops (rejets en queue) du fournisseur.

Exemple (QoS sur un tunnel hub/spoke DMVPN) : interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! Platform-dependent: crypto ipsec fragmentation after-encryption

Pièges courants et mesures d’atténuation :

• L’absence de qos pre-classify entraîne le classement de tout le trafic dans la class-default après le chiffrement, pénalisant les flux en temps réel.
• Une MTU/MSS incorrecte provoque le blackholing (mise au trou noir) des segments volumineux et des performances applicatives irrégulières ; validez la MTU de chemin de bout en bout.
• L’application de politiques complexes au débit de la ligne (line rate) sur des tunnels logiciels peut surcharger le CPU ; préférez la décharge matérielle (hardware offload) lorsqu’elle est disponible.

Protection du plan de contrôle (CoPP/CPPr) et validation opérationnelle

CoPP protège le CPU du routeur en classifiant et en limitant le débit du trafic de contrôle et de gestion dans le chemin du plan de contrôle. CPPr ajoute une granularité plus fine en utilisant des sous-interfaces host, transit et CEF-exception.

• Fondamentaux de CoPP

  • Attachez les politiques au plan de contrôle, pas aux interfaces de données.
  • Les types de correspondance couramment pris en charge sont ip dscp, ip precedence et access-group. N’utilisez pas le mot-clé log sur les entrées ACL référencées par CoPP.
  • Séparez les protocoles de routage critiques (BGP, OSPF, RSVP/LDP le cas échéant) du trafic de gestion au mieux (best-effort) (HTTP) et du trafic de contrôle en vrac (exportations NetFlow vers le CPU dans des cas exceptionnels). Fournissez des CIR généreux pour les protocoles critiques.

• Détails de CPPr

  • control-plane host régit le trafic terminé sur le routeur (par ex., SSH, SNMP, sessions de routage).
  • control-plane transit gère le trafic d’exception remonté (punted) depuis le matériel (par ex., TTL dépassé, MTU dépassé).
  • control-plane cef-exception gère les remontées (punts) liées à CEF.
  • Appliquez des politiques différentes par sous-interface pour éviter les dommages collatéraux lorsqu’une classe se comporte mal.

• Exemple de CoPP avec exclusions et attachement correct : ip access-list extended ACL-TELNET-EXEMPT deny tcp host 10.1.1.1 any eq 23 deny tcp host 172.16.1.1 any eq 23 permit ip any any ip access-list extended ACL-BGP permit tcp any any eq 179 permit tcp any eq 179 any ip access-list extended ACL-HTTP permit tcp any any eq 80 permit tcp any any eq 443 ! class-map match-any CM-BGP match access-group name ACL-BGP class-map match-any CM-HTTP match access-group name ACL-HTTP class-map match-any CM-TELNET match access-group name ACL-TELNET-EXEMPT ! policy-map PM-COPP class CM-BGP police cir 256000 conform-action transmit exceed-action transmit class CM-HTTP police cir 64000 conform-action transmit exceed-action drop class CM-TELNET police cir 100000 conform-action transmit exceed-action drop class class-default police cir 32000 conform-action transmit exceed-action drop ! ! Ensure policy is on the control plane, and not on data interfaces: no interface GigabitEthernet0/0 service-policy input PM-COPP control-plane service-policy input PM-COPP

Remarques :

• Une limitation de débit trop agressive sur BGP peut entraîner des keepalives manqués, des réinitialisations de session et une instabilité des routes (route churn). Si vous devez appliquer un policing, définissez un CIR suffisant et envisagez exceed-action transmit pour éviter les pertes lors des pics de trafic.

• Exemptez des sources de gestion de confiance spécifiques en utilisant des deny dans l’ACL avant le permit ; appliquez l’ACL comme correspondance (match) sous la classe appropriée.

• Compléments au plan de gestion

  • IPv6 RA Guard bloque les Router Advertisements non autorisés (rogue) sur les ports L2 mais ne peut pas protéger lorsque le RA est tunnelisé ; appliquez la protection aux extrémités du tunnel ou utilisez l’authentification lorsque c’est possible.
  • IPv6 Source Guard utilise la table de liaison (binding table) pour n’autoriser que les adresses sources valides ; il abandonne le trafic provenant de sources IPv6 inconnues/non allouées sur les ports d’accès, réduisant ainsi le trafic d’exception traité par le CPU.
  • Le durcissement de l’équipement (désactiver les services inutilisés, utiliser des ACL sur les lignes vty, limiter les communautés SNMP) réduit l’exposition du plan de contrôle.

• Validation et compteurs

  • Utilisez show policy-map interface et show policy-map control-plane pour vérifier le nombre de paquets, les pertes (drops) et les actions de policing. Exécutez d’abord show policy-map control-plane lorsque des symptômes de surcharge du CPU apparaissent (par ex., lenteur de SSH, requêtes SNMP intermittentes).
  • Sur les plateformes à transfert matériel (hardware-forwarding), corrélez avec show platform hardware qfp active statistics drop ou des compteurs ASIC équivalents pour les pertes WRED/tail drops.
  • Pour les files d’attente, vérifiez leur profondeur, les pertes tail/WRED et le policing de la file prioritaire en utilisant show policy-map interface et show queueing interface.
  • Recherchez les symptômes applicatifs :
    • La gigue (jitter) vocale, la perte de paquets ou un son haché suggèrent que la LLQ est trop petite ou que la frontière de confiance (trust boundary) est incorrecte.
    • Des connexions SSH lentes ou qui se déconnectent mais des pings normaux peuvent indiquer un policing CoPP du trafic de gestion.
    • Des requêtes SNMP intermittentes sont corrélées avec des pertes dans la classe de gestion ou des remontées (punts) d’exception CEF dépassant les limites.
    • L’effondrement du débit TCP en charge avec une augmentation des pertes WRED est un comportement attendu ; avec uniquement du tail drop, recherchez des flux synchronisés en dents de scie (sawtooth).

Scénario de problème pratique

Acme Engineering exploite un réseau DMVPN à hub unique sur une connexion Internet haut débit avec IPsec+mGRE. Les utilisateurs signalent une qualité VoIP hachée vers le siège (HQ), un polling SNMP intermittent des routeurs de succursale, et des connexions SSH lentes ou qui se déconnectent vers le hub pendant les heures de pointe.

1. Établir des frontières de confiance (trust boundaries) et remarquer le trafic en périphérie

• Justification : Les téléphones et les liaisons montantes de confiance sont les seuls équipements autorisés à marquer le trafic en EF/CS3 ; tout autre trafic d’accès est remarqué en BE. Cela empêche l’abus de priorité qui pourrait pénaliser les classes temps réel.

2. Mettre en œuvre une QoS hiérarchique sur le tunnel DMVPN

• Justification : Appliquer un shaper parent au tunnel au débit mesuré du fournisseur (par ex., 20 Mbps) pour éviter le policing en amont. Sous le parent, utiliser LLQ pour la voix EF, des classes de bande passante pour la vidéo et les données critiques, WRED pour les classes à dominante TCP, et fair-queue pour la classe par défaut. Cela localise la gestion de la congestion avant que l’opérateur ne perde des paquets.

3. Activer qos pre-classify et ajuster MTU/MSS

• Justification : qos pre-classify garantit que la politique correspond à l’IP/port/DSCP interne avant l’encapsulation GRE/IPsec. ip mtu 1400 et ip tcp adjust-mss 1360 empêchent la fragmentation/le blackholing dus à la surcharge d’encapsulation. La fragmentation après chiffrement (after-encryption) est configurée pour s’adapter au comportement du fournisseur.

4. Retirer la politique CoPP appliquée à l’interface et l’attacher au plan de contrôle

• Justification : CoPP doit protéger le CPU quelle que soit l’interface d’entrée. Détachez toute service-policy en entrée des interfaces physiques et appliquez PM-COPP au plan de contrôle pour gouverner de manière centralisée le trafic remonté (punted) et terminé sur l’hôte.

5. Créer des classes CoPP distinctes avec des CIR sûrs ; exempter les sources de confiance

• Justification : Placer BGP dans sa propre classe avec un CIR suffisant pour les keepalives et les rafales ; configurer conform/exceed transmit pour éviter les réinitialisations de session. Appliquer un policing sur HTTP/HTTPS à de faibles débits pour limiter la gestion web vers le CPU. Pour les exceptions Telnet/SSH, refuser (deny) les IP de gestion de confiance dans l’ACL afin que la politique ne les limite pas, tout en continuant à contrôler toutes les autres sources.

6. Valider et itérer en fonction des compteurs et des symptômes

• Justification : Utiliser show policy-map control-plane pour confirmer que les pertes de gestion correspondent aux problèmes SSH/SNMP observés ; ajuster les CIR jusqu’à ce que les pertes cessent. Utiliser show policy-map interface Tunnel30 pour vérifier l’utilisation de la LLQ et s’assurer qu’aucun policing de dépassement de priorité ne se produit avec un volume d’appels normal. Surveiller les pertes WRED et tail drops dans les classes critiques ; si la qualité de la voix reste médiocre sans pertes dans la LLQ, augmenter légèrement le pourcentage de la LLQ ; si des pertes se produisent, dimensionner plus précisément la LLQ et le shaper parent en fonction du codec et de la bande passante.

En appliquant une frontière de confiance correcte, en effectuant le shaping avant le goulot d’étranglement, en classifiant avant l’encapsulation et en protégeant le plan de contrôle avec des politiques CoPP/CPPr correctement dimensionnées, Acme Engineering restaure la qualité de la voix et stabilise l’accès à la gestion sans sacrifier le débit global.

← Routage et distribution multicast · Tous les domaines · VPN →

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