Les switches sont rapides. Le problème a changé, pas disparu.
Un Catalyst 9300 ou un Nexus 93180 forward à 40 Mpps avec des buffers profonds. Sur un campus full 10G, la congestion est quasi inexistante entre les switches — c'est vrai. Mais la QoS n'a pas disparu : elle a migré vers les points de contention réels.
Liens surdimensionnés, congestion rare. QoS utile principalement pour le trust boundary au port d'accès et pour passer les markings correctement vers le WAN.
Le WAN reste le goulot. 100M ou 1G partagé entre Teams, backup S3, Salesforce et vidéo surveillance. Sans LLQ, la voix est détruite dès qu'un backup démarre.
Exigences strictes : jitter < 30ms, perte < 1%, latence < 150ms. Un seul burst de backup sur le lien WAN casse la qualité audio pendant 10 secondes.
Ce qui a vraiment changé avec les réseaux modernes
| Avant (réseau legacy) | Maintenant (réseau moderne) |
|---|---|
| Liens WAN à 2–64 Mbps | Liens WAN à 100M–10G mais toujours partagés |
| Voix sur ISDN/TDM séparé | Voix sur IP (Teams, Webex) = partage le même lien que tout |
| QoS partout, même sur LAN | QoS au edge WAN + trust boundary LAN access |
| Config manuelle par protocole | SD-WAN avec QoS par application (App-ID) |
| DSCP sur tous les équipements | DSCP bleaché sur internet — SD-WAN overlay compense |
Ton DSCP EF survivra-t-il jusqu'à destination ?
C'est la question que pose un architecte. Un ingé CCIE qui ne sait que configurer police rate sur un IOS mais ignore ce qui arrive au DSCP quand le paquet traverse un Palo Alto ou un provider internet n'est pas architecte — il est technicien.
Cat 9K
FW
ISR/ASR
MPLS
si SLA DSCP
Teams client
FW
→ BE (0) ✗
Teams DC
SNAT
DSCP ? ✗
réponse
DSCP 0
Palo Alto, F5, Checkpoint — leur rôle dans la chaîne QoS
PAN-OS dispose d'une vraie QoS : QoS policy par App-ID, profils de bande passante, shaping, et re-marking DSCP à l'egress. Peut classifier par application (Teams, Zoom, SAP) — plus puissant que DSCP seul.
Point critique : Par défaut, PAN-OS préserve le DSCP des paquets. Mais si une QoS policy est appliquée avec re-marking, le DSCP original est écrasé. À vérifier dans chaque déploiement.
F5 peut conserver ou re-marquer le DSCP — mais en mode SNAT complet (le plus courant), le header IP est réécrit. Le DSCP du client vers le serveur est perdu.
Solution : iRule pour copier le DSCP original dans le nouveau header, ou configurer ip-tos-to-server dans le profil FastL4/TCP.
Checkpoint a un QoS blade (ex-FloodGate) mais il est rarement déployé en production. La plupart des architectures Checkpoint n'activent pas le QoS blade — la QoS est gérée en amont par les équipements Cisco.
La grande majorité des ISP remettent le DSCP à zéro (Best Effort) aux points de peering. Les SLA internet ne garantissent aucun traitement différencié. C'est structurel — pas configurable.
Seule solution : SD-WAN overlay ou MPLS avec SLA DSCP explicite.
Où la QoS bout-en-bout est possible
| Périmètre | QoS E2E possible ? | Condition |
|---|---|---|
| Campus LAN interne | ✅ Oui | Trust boundary configuré au port d'accès, markings honorés sur tous les switches |
| WAN MPLS provider | ✅ Oui | SLA MPLS avec mapping DSCP explicite — à vérifier contractuellement |
| SD-WAN overlay | ⚠️ Partiel | QoS sur l'overlay garantie, mais l'underlay internet ne l'est pas |
| Multi-site même AS | ✅ Oui | Tu contrôles tous les équipements — possible si config cohérente |
| Internet public | ❌ Non | DSCP bleaché aux peerings — structurellement impossible |
| Multi-vendeur (PA + Cisco) | ⚠️ Partiel | Possible si PA configuré pour préserver/re-marquer correctement |
| F5 en SNAT | ❌ Perdu | Header réécrit — DSCP perdu sauf iRule ou profil ip-tos spécifique |
Un CCIE qui connaît police rate mais ignore ce qui arrive au DSCP quand le paquet traverse son Palo Alto n'est pas architecte. Il est technicien sur sa portion de réseau. La vraie valeur ajoutée d'un architecte c'est de tracer le chemin complet d'un paquet et d'identifier exactement où le marking est préservé, modifié ou perdu.
C'est la même logique que ISE sans Windows AD/ADCS/PKI : connaître le bout de câble sans comprendre l'écosystème dans lequel il s'insère — inutile en production, dangereux en architecture.
La bonne question n'est pas "comment configurer CBWFQ ?" — c'est "est-ce que ma QoS policy a encore un sens quand le paquet sort de mon périmètre ?"