Le tail drop crée une synchronisation globale TCP : tous les flows reculent en même temps, puis redémarrent ensemble — throughput oscillant. WRED droppe aléatoirement et sélectivement avant saturation, cassant cette synchronisation.
| Aspect | RED | WRED |
|---|---|---|
| Profils de drop | Un seul profil pour tous les paquets | Profil par IP Precedence ou DSCP — classes différentes = thresholds différents |
| Priorité | Aveugle — traite tous les flows de façon identique | AF13 droppé avant AF12, avant AF11 — respect du drop precedence |
| TCP vs UDP | Drop sans discrimination | Drop sans discrimination aussi — WRED est efficace uniquement sur TCP |
| Cisco IOS | Commande random-detect sans option | Commande random-detect dscp-based ou prec-based |
| Usage | Obsolète en pratique | Standard sur liens WAN congestionné avec trafic DSCP marqué |
| Mécanisme | Quand droppe | Qui droppe | Effet TCP |
|---|---|---|---|
| Tail Drop | Queue 100% pleine | Tous les arrivants | Global Sync — oscillation |
| RED | Dès le min-threshold | Aléatoire, indifférencié | Échelonné, mais aveugle au DSCP |
| WRED | Dès le min-threshold du profil DSCP | Aléatoire, pondéré par DSCP | Échelonné + respect priorité |
| WRED + ECN | Dès le min-threshold | Marque CE bit — ne droppe pas | Optimal — zéro perte, signal congestion |
min-threshold (début des drops), max-threshold (début du tail drop),
mark-probability denominator (taux de drop au max-threshold).
Comprendre la courbe de drop est essentiel pour dimensionner WRED correctement.
P(drop) = (avg_queue - min_threshold) / (max_threshold - min_threshold) × (1 / mark_prob_denominator)P = (30-20)/(40-20) × 1/10 = 10/20 × 0.1 = 0.05 = 5%| Paramètre | Rôle | Valeur IOS par défaut | Impact si trop bas/haut |
|---|---|---|---|
| min-threshold | Profondeur queue à partir de laquelle WRED commence à dropper | Variable selon DSCP (ex: 20 pour AF11) | Trop bas → drops excessifs avant congestion réelle. Trop haut → WRED s'active trop tard, risque tail drop |
| max-threshold | Profondeur queue à partir de laquelle tail drop s'active (100%) | Variable selon DSCP (ex: 40 pour AF11) | Trop bas → tail drop précoce = même problème que sans WRED. Trop haut → grande latence |
| mark-probability denominator | Taux de drop au max-threshold = 1/denominator | 10 → 10% de drop au max-threshold | Trop petit (denom=2 → 50%) → drops agressifs. Trop grand (denom=100 → 1%) → WRED quasi-inefficace |
avg_queue = (1 - 2^-exp_weight) × prev_avg + 2^-exp_weight × current_queueexp-weighting-constant (défaut = 9) : plus la valeur est grande, plus la moyenne est lissée.
Une valeur faible (ex: 1) rend WRED réactif aux micro-bursts — rarement souhaitable.
| DSCP | min-threshold | max-threshold | mark-prob denom | Comportement |
|---|---|---|---|---|
| EF (46) | 22 | 40 | 10 | Voix — ne devrait pas être droppée (LLQ préférable) |
| AF11 (10) | 22 | 40 | 10 | Drop precedence LOW — protégé |
| AF12 (12) | 18 | 32 | 10 | Drop precedence MEDIUM |
| AF13 (14) | 14 | 24 | 10 | Drop precedence HIGH — premier sacrifié |
| AF21 (18) | 22 | 40 | 10 | DROP LOW |
| AF22 (20) | 18 | 32 | 10 | DROP MEDIUM |
| AF23 (22) | 14 | 24 | 10 | DROP HIGH |
| BE / default (0) | 20 | 40 | 10 | Best Effort — thresholds intermédiaires |
| CS1 à CS6 | Variables | Variables | 10 | Dépend du marking |
bandwidth (CBWFQ).
Il est incompatible avec les classes priority (LLQ) — IOS refuse ou ignore.
Il fonctionne également sur class-default avec WFQ.
! ── ÉTAPE 1 : class-maps ──────────────────────────────────────────── class-map match-any CM-VOIX match dscp ef class-map match-any CM-VIDEO match dscp af41 af42 af43 ! 3 drop precedences dans la même classe class-map match-any CM-DATA match dscp af21 af22 af23 ! ── ÉTAPE 2 : policy-map avec WRED sur classes CBWFQ ──────────────── policy-map PM-WAN-CHILD class CM-VOIX priority 128 ! LLQ — WRED incompatible ici class CM-VIDEO bandwidth 192 ! CBWFQ — WRED s'applique ici random-detect dscp-based ! active WRED avec profils DSCP par défaut ! ! AF43 droppé avant AF42, avant AF41 class CM-DATA bandwidth 96 random-detect dscp-based ! même logique : AF23 > AF22 > AF21 class class-default fair-queue random-detect ! RED simple sur le reste (best-effort) ! ── ÉTAPE 3 : policy parent + application ─────────────────────────── policy-map PM-WAN-PARENT class class-default shape average 512000 service-policy PM-WAN-CHILD interface GigabitEthernet0/1 bandwidth 512 service-policy output PM-WAN-PARENT
! Syntaxe : random-detect dscp value min-threshold max-threshold mark-prob-denominator class CM-VIDEO bandwidth 192 random-detect dscp-based ! ! Surcharger les thresholds par défaut pour AF41/AF42/AF43 : random-detect dscp af41 24 40 10 ! AF41 : min=24, max=40, mark-prob=10 random-detect dscp af42 20 34 10 ! AF42 : min=20, max=34, mark-prob=10 random-detect dscp af43 16 26 10 ! AF43 : min=16, max=26 — droppé le plus tôt ! ! Ajuster le lissage EWMA (défaut=9, valeurs 1-16) : random-detect exponential-weighting-constant 9 ! 9 = lissage normal | 1 = très réactif aux bursts | 16 = très lissé (lent à réagir)
! ── WRED + ECN — ajouter 'ecn' après random-detect ───────────────── class CM-VIDEO bandwidth 192 random-detect dscp-based random-detect ecn ! active ECN : marque CE au lieu de dropper ! ! Condition : les deux endpoints DOIVENT supporter ECN ! Si sender n'est pas ECN-capable (ECT=00) → WRED droppe normalement ! Si sender est ECN-capable (ECT=01 ou 10) → WRED marque CE=11 ! ! Vérifier support ECN côté serveur Linux : sysctl net.ipv4.tcp_ecn ! 0=disabled, 1=enabled, 2=passive ! ! Limites ECN : ! — Fonctionne uniquement pour TCP (pas UDP) ! — Les deux endpoints doivent le supporter ! — Certains firewalls bloquent les paquets CE — tester en prod
| Critère | WRED sans ECN | WRED + ECN |
|---|---|---|
| Compatibilité | Universelle — fonctionne avec tout sender | Requiert support ECN sur les deux endpoints |
| Pertes de paquets | Oui — paquet droppé, retransmis | Non — paquet livré avec CE marqué |
| Latence | Augmente au timeout TCP avant retransmission | Minimale — réduction fenêtre immédiate |
| Throughput | Baisse pendant retransmission | Reste élevé |
| Usage recommandé | Standard — réseau mixte | Datacenters, clouds, serveurs ECN-capables |
! ── Vérification principale ───────────────────────────────────────── show policy-map interface GigabitEthernet0/1 output ! Affiche : profils WRED par DSCP, mean queue depth, tail drops, WRED drops ! ── Stats WRED détaillées ──────────────────────────────────────────── show policy-map interface GigabitEthernet0/1 output class CM-VIDEO ! Affiche uniquement la classe CM-VIDEO avec tous ses compteurs WRED ! ── Profils WRED configurés ────────────────────────────────────────── show queueing interface GigabitEthernet0/1 ! ── Reset des compteurs ────────────────────────────────────────────── clear counters GigabitEthernet0/1
| Compteur | Valeur normale | Problème si... |
|---|---|---|
| WRED drops | Quelques drops — signe que WRED gère la congestion | Très élevé → thresholds trop bas ou lien sous-dimensionné |
| Tail drops | Idéalement 0 — WRED doit prévenir le tail drop | Non-zéro → max-threshold trop bas, ou congestion chronique |
| Mean queue depth | Stable entre min et max threshold | Proche de max → congestion persistante → augmenter bandwidth ou baisser charge |
| AF43 drops >> AF41 drops | Normal — drop precedence fonctionne | AF41 drops élevés → WRED inefficace ou lien saturé |
random-detect dans une classe priority est refusé ou ignoré par IOS.
La priority queue a son propre mécanisme de drop (le policer intégré).
Si le trafic dépasse la valeur priority, l'excès est droppé immédiatement par le policer —
WRED ne peut pas intervenir avant ce drop.
Règle : WRED uniquement sur bandwidth (CBWFQ) et class-default.
WRED fonctionne en signalant la congestion à TCP via les pertes (ou ECN).
TCP réduit sa fenêtre de congestion en réponse.
UDP est aveugle aux drops WRED — il continue d'envoyer au même débit.
Dropper de l'UDP avec WRED n'a aucun effet sur la congestion (le sender ne ralentit pas).
WRED sur du trafic majoritairement UDP = pertes sans bénéfice de congestion control.
AF13 a un drop precedence élevé = il est droppé EN PREMIER par WRED.
Cela ne signifie pas qu'il a une priorité de forwarding basse —
tous les paquets AF1x appartiennent à la même classe CBWFQ et ont le même bandwidth garanti.
Le drop precedence ne sert qu'à différencier qui sacrifie ses paquets en cas de congestion
dans la file, pas qui passe avant qui au scheduler.
Si le max-threshold est inférieur à la profondeur normale de la queue en trafic léger, WRED droppe en permanence même sans congestion réelle. Le mean queue depth doit rester sous le min-threshold en trafic normal, et monter vers max uniquement lors de bursts. Règle terrain : max-threshold ≥ 2 × min-threshold.
random-detect seul (sans dscp-based ni prec-based)
est du RED classique : un seul profil pour tous les paquets, indifférent au DSCP.
AF13 et AF11 sont droppés au même taux — le drop precedence est ignoré.
En production avec des paquets marqués, toujours utiliser random-detect dscp-based.
Certains firewalls, load balancers ou routeurs intermédiaires modifient ou bloquent
les paquets avec le bit CE=1 (ils les considèrent comme malformés ou suspects).
Avant de déployer WRED+ECN en production, vérifier le comportement de tous les équipements
sur le chemin. Tester avec ping ip ecn ou Wireshark en capturant les bits ECN.
random-detect dscp-based dans la classe CBWFQ. Utilise les thresholds IOS par défaut par valeur DSCP. Personnalisation : random-detect dscp af43 16 26 10 pour surcharger min=16, max=26, mark-prob=10 pour AF43.