Là où le policing droppe, le shaping attend. Les paquets en excès entrent dans un buffer et sortent au rythme du CIR. Aucun paquet n'est perdu — mais ils peuvent être retardés. C'est la bonne solution pour le WAN.
| Critère | Shaping | Policing |
|---|---|---|
| Excès de trafic | Bufferisé → retardé | Droppé ou remarqué |
| Paquets perdus | Non (sauf buffer plein) | Oui (exceed/violate) |
| Latence ajoutée | Oui (jitter possible) | Non |
| Impact voix | Acceptable si LLQ actif | Drops = dégradation |
| Cas d'usage principal | Egress WAN — respecter débit contractuel | Ingress ISP — enforcer SLA client |
| Direction | Egress (output) uniquement sur IOS | Ingress ou egress |
Si le routeur a été silencieux pendant plusieurs Tc, les jetons non utilisés s'accumulent dans Be (Excess Burst). Au prochain burst, il peut envoyer BC + Be bits — un burst plus grand que la normale. Après ce burst, Be se vide et on revient au BC normal.
| Paramètre | Signification | Valeur typique |
|---|---|---|
| CIR | Committed Information Rate — débit moyen garanti (bps) | Débit contractuel WAN |
| BC | Committed Burst — bits envoyés par Tc. BC = CIR × Tc | CIR × 125 ms |
| Tc | Timing interval. IOS calcule Tc = BC / CIR | 125 ms par défaut |
| Be | Excess Burst — accumulation pendant les silences. Permet un burst plus grand ponctuel. | = BC (défaut IOS) |
GigabitEthernet0/1 physique à 1 Gbps raccordée à
un lien WAN ISP à 512 kbps. Vous configurez LLQ avec priority 128 et appliquez
directement la policy sur l'interface. Résultat : LLQ est configuré mais la voix n'est pas prioritaire.shape average 512000 :Bc = CIR × Tc bits — soit 64 000 bits toutes les 125 ms sur un lien 512k.shape et priority/bandwidth dans la même classe.
Ces commandes opèrent à des niveaux différents du scheduler :shape average → contrôle le débit total de la classe (pacing Tc)priority / bandwidth → ordonnent les paquets à l'intérieur de ce débitshape dans class-default
+ appel de l'enfant via service-policy.priority (LLQ),
bandwidth (CBWFQ), fair-queue (WFQ). Ne jamais l'appliquer directement sur l'interface.
! ── ÉTAPE 1 : class-maps (classification) ───────────────────────── class-map match-any CM-VOIX match dscp ef ! G.711, G.729 — voix RTP match dscp cs5 ! signalisation SIP/H.323 class-map match-any CM-VIDEO match dscp af41 ! vidéoconférence temps réel class-map match-any CM-APPS match dscp af31 ! applicatifs métier critiques ! ── ÉTAPE 2 : policy enfant — LLQ + CBWFQ ───────────────────────── ! C'est ici que s'appliquent les règles de priorité et de garantie ! Les valeurs bandwidth/priority sont en kbps dans une policy-map policy-map PM-WAN-CHILD class CM-VOIX priority 128 ! LLQ : 128 kbps — sort EN PREMIER, policer intégré ! ! si trafic > 128k → excès droppé (pas bufferisé) class CM-VIDEO bandwidth 128 ! CBWFQ : 128 kbps garantis — servi après LLQ class CM-APPS bandwidth 128 ! CBWFQ : 128 kbps garantis class class-default fair-queue ! WFQ pour backup/web — prend ce qui reste (~128k) ! ── ÉTAPE 3 : policy parent — shape + appel enfant ───────────────── ! Contient UNIQUEMENT shape dans class-default + service-policy vers l'enfant ! Ne jamais mettre priority/bandwidth ici — IOS refusera policy-map PM-WAN-PARENT class class-default shape average 512000 ! crée le sas logiciel — pace à 512 kbps ! ! Bc = 512000 × 0.125 = 64 000 bits par Tc service-policy PM-WAN-CHILD ! LLQ+CBWFQ tournent dans ce sas ! ── ÉTAPE 4 : application sur l'interface ────────────────────────── ! TOUJOURS le parent sur l'interface — jamais l'enfant directement interface GigabitEthernet0/1 bandwidth 512 ! déclare la CIR à IOS — référence pour les % QoS ! ! ne limite PAS le trafic — juste un paramètre IOS service-policy output PM-WAN-PARENT ! output uniquement — jamais input
| Contrainte | Règle | Dans ce scénario 512k |
|---|---|---|
| priority ≤ shape rate | La LLQ du child ne peut pas dépasser le CIR du parent | 128 ≤ 512 ✓ |
| Règle des 75% | Somme des bandwidth + priority dans child ≤ 75% du CIR shapé | 128+128+128 = 384 = 75% de 512 ✓ (limite exacte) |
| bandwidth dans child | Référence = CIR du parent (512k), pas la vitesse physique de l'interface | bandwidth 128 = 128 kbps = 25% des 512k shapés |
| service-policy sur l'interface | Toujours appliquer le PARENT — jamais l'enfant directement | Erreur fréquente : appliquer PM-WAN-CHILD sur l'interface |
| shape uniquement en output | Shaping = contrôle de l'émission — ingress = policing | service-policy output PM-WAN-PARENT |
Si service-policy output PM-WAN-CHILD est appliqué sans parent, la voix LLQ est configurée
mais quasiment inactive. Les paquets ne passent pas par la Shape Queue — la file logicielle ne se congestionne jamais
— LLQ ne s'active pas. Résultat identique à une absence totale de QoS sur Ethernet WAN.
shape average 512000 seul dans class-default sans service-policy enfant
crée le sas logiciel mais laisse un FIFO à l'intérieur. Voix et backup sont bufferisés ensemble.
Le sas est actif mais non trié — la voix attend quand même derrière un transfert backup.
Toujours coupler shape parent + LLQ child.
Si priority 600 dans child mais shape average 512000 dans parent,
IOS accepte la config mais le policer LLQ est théoriquement supérieur au débit total disponible.
En pratique la voix peut consommer 100% du lien shapé — starvation complète des autres classes.
Règle : priority ≤ 33% du CIR parent en production voix.
bandwidth sur l'interface Ethernet WANSans bandwidth 512 sur une GigE, IOS pense que le lien fait 1 000 000 kbps.
Les calculs bandwidth percent dans l'enfant seront 2000× trop grands.
bandwidth percent 25 = 25% de 1 Gbps = 250 Mbps au lieu de 128 kbps.
La règle des 75% sera aussi faussée. Toujours déclarer la CIR réelle.
Dans la policy parent, shape doit être dans class class-default —
jamais dans une classe nommée comme CM-VOIX. La raison : tout le trafic doit passer par le sas,
y compris la voix. Si shape est dans une classe spécifique, seule cette classe est pacée —
les autres classes débordent directement dans la hardware TX Queue à vitesse physique.
! ── shape average — débit MOYEN = CIR ───────────────────────────── ! Le plus courant — respecte strictement le contrat ISP policy-map PM-SHAPE-AVG class class-default shape average 512000 ! CIR seul — Bc/Be calculés par IOS ! ! Syntaxe complète : shape average CIR [Bc] [Be] (Bc et Be en bits) shape average 512000 64000 64000 ! CIR=512k Bc=64000b Be=64000b ! ↑ ↑ ↑ ! bps bits bits ! ! Calcul IOS par défaut (Tc=125ms) : ! Bc = CIR × Tc = 512000 × 0.125 = 64 000 bits ! Be = 0 (pas d'excess burst par défaut en average) ! ── shape peak — débit MOYEN = CIR + Be/Tc ───────────────────────── ! Plus agressif — autorise un burst au-delà du CIR chaque Tc ! Rarement utilisé en prod — risque de drops ISP si lien contractuel policy-map PM-SHAPE-PEAK class class-default shape peak 512000 ! PIR ≈ 2×CIR si Bc=Be ! ! Avec shape peak : chaque Tc libère Bc + Be bits ! Bc = 64 000 bits (CIR portion) ! Be = 64 000 bits (excess burst — emprunté sur Tc suivant) ! Débit effectif = (Bc + Be) / Tc = 128 000 / 0.125 = 1 024 kbps
| Paramètre | shape average | shape peak |
|---|---|---|
| Débit moyen | = CIR | = CIR × (1 + Be/BC) ≈ 2×CIR |
| Utilisation Be | Accumulation sur silence | Utilisé chaque Tc |
| Risque | Aucun (respecte contrat) | ISP peut dropper (dépasse contrat) |
| Cas d'usage | Standard WAN contractuel | Lien non contractuel, test lab |
! ── shape average percent ─────────────────────────────────────────── ! Référence = commande 'bandwidth' de l'interface (pas la vitesse physique) interface GigabitEthernet0/1 bandwidth 512 ! déclare la CIR à IOS — référence pour les % policy-map PM-SHAPE-PCT class class-default shape average percent 50 ! 50% de 512k = 256 kbps — s'adapte si bandwidth change ! ── Application egress (shaping = output uniquement) ──────────────── interface GigabitEthernet0/1 bandwidth 512 service-policy output PM-WAN-PARENT ! toujours output — jamais input ! ── Vérification ──────────────────────────────────────────────────── show policy-map interface GigabitEthernet0/1 output show traffic-shape show traffic-shape statistics
| Ce que vous voyez | Signification | Action |
|---|---|---|
| drops LLQ = 0 | Voix jamais droppée — config correcte | Rien à faire |
| drops LLQ > 0 | Voix droppée — LLQ saturé | Augmenter priority bandwidth |
| output queue pleine | Buffer shaping plein — trafic best effort droppé | Normal si trafic > CIR |
| rate offert > shape rate | Shaping actif — buffer utilisé | Normal — shaping fonctionne |
Sur IOS/IOS-XE, shape average dans une policy-map ne fonctionne
qu'en output sur l'interface. Si tu appliques la policy en input,
IOS refuse la commande ou l'ignore silencieusement.
Le policing ingress, c'est l'affaire de l'ISP — pas du routeur client.
Un shape average 512000 seul dans class-default sans child policy-map
crée un buffer FIFO. Voix et données sont mélangées. Un gros transfert
peut faire attendre des paquets voix dans la file.
Toujours coupler shaping parent + LLQ child dès qu'il y a de la voix.
shape peak pousse le débit au-delà du CIR contractuel.
L'ISP police en ingress — l'excès sera droppé de son côté.
Tu shapes pour ne rien dropper localement, mais l'ISP droppe quand même.
Résultat : retard (buffer) + drops ISP = pire que sans shaping.
Utiliser shape average en production.
En shaping, Be = accumulation de jetons pendant les périodes de silence
→ burst ponctuel autorisé au-delà du BC normal.
En policing dual bucket, Be = deuxième bucket séparé rempli au PIR.
Le mot est le même, le mécanisme est différent. Question classique CCIE.
La priority dans la child policy ne peut pas dépasser le débit
shapé par le parent. Si parent shape = 512 kbps et child priority = 600 kbps,
IOS accepte la commande mais la priorité sera limitée à 512 kbps.
En pratique : dimensionner LLQ à max 25-33% du shape rate.
Tc = BC / CIR. Si BC est grand, Tc est grand. Entre deux Tc, le routeur est en pause — les paquets voix attendent. Sur un lien lent (512 kbps), Tc = 125 ms est déjà à la limite. Un BC trop grand → Tc 500 ms → voix coupée. Conseil : garder Tc entre 10 ms et 125 ms sur les liens voix.
Cliquez sur une carte pour révéler la réponse.