Modèles QoS – QoS – CCIE

Pourquoi des modèles QoS ?

Internet a été conçu pour fonctionner en Best Effort : chaque paquet est traité de façon identique, sans garantie de délai ni de débit. Ça suffit pour un email — pas pour de la voix ou de la vidéo en temps réel. Deux modèles ont été proposés pour y remédier : IntServ (réservation explicite par flux) et DiffServ (classification par agrégats). Le second a gagné pour des raisons de scalabilité.

Le problème fondamental : latence sur Internet

Un appel G.711 nécessite une latence end-to-end < 150 ms (recommandation G.114). Sur un réseau Best Effort surchargé, un paquet voix peut attendre derrière 50 paquets FTP dans une file FIFO — facilement 300–500 ms. Résultat : écho, coupures, incompréhensible. C'est le problème que DiffServ et IntServ cherchent à résoudre par des mécanismes différents.

Best Effort — le modèle par défaut d'Internet

Best Effort signifie qu'Internet fait de son mieux pour livrer chaque paquet — sans garantie de délai, de débit, ni d'ordre. C'est intentionnel : la simplicité de l'IP (pas d'état dans le réseau, pas de signalisation) est ce qui a permis à Internet de scaler à des milliards d'équipements. Le "problème" n'est visible que pour les applications sensibles à la latence.

Comportement FIFO

Quand Best Effort suffit

Best Effort est parfaitement acceptable pour : email, web classique, transferts de fichiers, bases de données non temps réel. Tant que la bande passante est suffisante par rapport au trafic, la latence reste faible et Best Effort fonctionne bien. QoS n'est nécessaire que sur les liens congestionnés ou pour les applications sensibles à la latence.

Critère	Best Effort
Garantie débit	Aucune
Garantie latence	Aucune
État dans les routeurs	Aucun — stateless
Signalisation requise	Non
Scalabilité	Infinie
Complexité config	Zéro
Adapté voix/vidéo temps réel	Non (lien surchargé)

IntServ — réservation de ressources par flux

IntServ (Integrated Services, RFC 2210) garantit la qualité de service en réservant explicitement les ressources (bande passante, buffers) pour chaque flux individuel. Le protocole de signalisation RSVP (Resource Reservation Protocol, RFC 2205) transporte les demandes de réservation de bout en bout. Chaque routeur sur le chemin maintient un état par flux et s'engage à respecter la réservation.

Classes de service IntServ

Classe	Nom	Garantie	Usage
GS	Guaranteed Service	Délai borné + débit garanti — réservation stricte	Voix, vidéo conférence temps réel
CLS	Controlled Load Service	Comportement "réseau non chargé" — pas de borne stricte	Applications adaptatives
BE	Best Effort	Aucune	Tout le reste

Pourquoi IntServ n'a pas scalé

Problème de scalabilité : un routeur cœur de réseau avec 100 000 flux simultanés doit maintenir 100 000 états RSVP + 100 000 timers de rafraîchissement (RSVP soft-state, refresh toutes les 30s). À l'échelle d'Internet — des milliards de flux — c'est impossible. IntServ reste viable dans les réseaux d'entreprise fermés (MPLS TE, appels VoIP contrôlés) mais ne peut pas fonctionner sur Internet public.

Config RSVP IOS (entreprise)

! Activer RSVP sur une interface
interface GigabitEthernet0/1
 ip rsvp bandwidth 512 128   ! 512 kbps total réservable, 128 kbps max par flux

! Vérification
show ip rsvp interface
show ip rsvp reservation
show ip rsvp installed
show ip rsvp request

! RSVP avec MPLS Traffic Engineering
interface GigabitEthernet0/1
 ip rsvp bandwidth
 mpls traffic-eng tunnels

DiffServ — différenciation par agrégats de trafic

DiffServ (Differentiated Services, RFC 2474/2475) répond au problème de scalabilité d'IntServ : au lieu de réserver des ressources pour chaque flux individuel, on classe le trafic en quelques classes agrégées (une dizaine maximum) et on applique un Per-Hop Behavior (PHB) à chaque classe sur chaque routeur. L'état est dans le paquet (le DSCP), pas dans les routeurs — scalabilité infinie.

Les PHBs définis par DiffServ

PHB	DSCP	Comportement par saut	Mécanisme IOS
EF — Expedited Forwarding	46	Latence bornée, faible jitter, faible perte — trafic en sortie ≤ trafic en entrée	LLQ — `priority`
AF — Assured Forwarding	AFxy (10–38)	4 classes × 3 niveaux de drop. Dans la classe : livraison assurée. Hors contrat : droppé selon précédence	CBWFQ + WRED
CS — Class Selector	CS0–CS7 (0,8,16…56)	Rétrocompatibilité IP Precedence. Comportement défini par opérateur	CBWFQ ou police
BE — Best Effort / DF	0	Aucune garantie — servi avec la capacité résiduelle	WFQ, FIFO, fair-queue

Le principe clé : l'état est dans le paquet

Scalabilité DiffServ : les routeurs cœur n'ont pas besoin de connaître les flux individuels. Ils lisent les 6 bits DSCP et appliquent le PHB correspondant — c'est un simple lookup en TCAM. Que ce soit 1 000 ou 1 milliard de flux simultanés, le routeur gère le même nombre de classes (une dizaine). C'est ce qui rend DiffServ scalable là où IntServ ne l'est pas.

Tableau comparatif — Best Effort vs IntServ vs DiffServ

Critère	Best Effort	IntServ / RSVP	DiffServ
Granularité	Aucune	Par flux individuel	Par classe agrégée
État dans les routeurs	Aucun (stateless)	Par flux (scalabilité nulle)	Aucun (état dans le paquet)
Signalisation	Aucune	RSVP (PATH + RESV)	Aucune (DSCP dans paquet)
Garantie par flux	Non	Oui — stricte	Non (statistique)
Scalabilité	Infinie	Faible (millions de flux)	Infinie
Complexité config	Nulle	Élevée (RSVP end-to-end)	Modérée (MQC)
Fonctionne sur Internet	Oui (c'est la base)	Non	Partiel (DSCP souvent remis à 0)
Déploiement réel	Universel	Rare (MPLS TE, CUCM)	Standard entreprise/MPLS
RFC de référence	RFC 791 (1981)	RFC 2205, 2210 (1997)	RFC 2474, 2475 (1998)

Quand utiliser quoi ?

Scénario	Modèle recommandé	Raison
Réseau interne entreprise avec voix/vidéo	DiffServ (MQC)	Simple, scalable, compatible équipements standard
WAN MPLS opérateur	DiffServ (DSCP → MPLS EXP)	L'opérateur mappe DSCP sur ses classes MPLS
Réseau multicast vidéo critique (broadcast)	IntServ (RSVP)	Garantie stricte nécessaire, réseau fermé et contrôlé
Petite entreprise, lien non saturé	Best Effort	Si la BW suffit, QoS n'apporte rien
MPLS Traffic Engineering	IntServ (RSVP-TE)	RSVP-TE pour établir et maintenir les LSPs

Pièges CCIE — Modèles QoS

⚠ IntServ n'est pas scalable sur Internet — c'est voulu

IntServ ne peut fonctionner que dans un domaine réseau fermé et contrôlé (entreprise, MPLS privé). Sur Internet, les routeurs cœur ne maintiennent pas d'états RSVP. Confondre les deux domaines d'application est une erreur classique au CCIE.

⚠ DiffServ ne garantit rien par flux

DiffServ donne une garantie statistique au niveau de la classe, pas par flux individuel. Si 100 appels voix arrivent simultanément sur un lien dimensionné pour 10, les 90 flux excédentaires seront droppés malgré le marquage EF. DiffServ doit toujours s'accompagner d'un Call Admission Control (CAC) pour la voix.

⚠ DSCP remis à 0 sur Internet = DiffServ inefficace

La majorité des FAI ne respectent pas le DSCP des clients (ou le remettent à 0). DiffServ fonctionne end-to-end uniquement sur un réseau privé MPLS avec SLA opérateur. Sur Internet public, seul le DiffServ interne au domaine est garanti.

⚠ RSVP soft-state — rafraîchissement obligatoire

RSVP est un protocole soft-state : les réservations expirent si elles ne sont pas rafraîchies toutes les 30 secondes (par défaut). Si le flux de rafraîchissement est interrompu, la réservation disparaît. À opposer aux protocoles hard-state (ATM, Frame Relay) qui maintiennent l'état jusqu'à suppression explicite.

⚠ Best Effort n'est pas "pas de QoS"

Sur un lien non congestionné, Best Effort fonctionne parfaitement pour toutes les applications. QoS n'est nécessaire que si le lien est saturé ou proche de la saturation. Déployer une config QoS complexe sur un lien à 1 Gbps utilisé à 10% n'apporte rien — et introduit une complexité de debugging inutile.

Flash Cards — Modèles QoS

Clique sur une carte pour révéler la réponse.

Quels sont les 3 modèles QoS ? Citer les RFCs associées.

Best Effort — RFC 791 (1981). IntServ — RFC 2205, 2210 (1997). DiffServ — RFC 2474, 2475 (1998).

Pourquoi IntServ ne scale pas sur Internet ?

Chaque routeur doit maintenir un état par flux (N flux = N entrées en mémoire + N timers RSVP). À l'échelle d'Internet avec des milliards de flux simultanés, c'est impossible. IntServ n'est viable que dans des réseaux fermés et contrôlés.

Qu'est-ce qu'un PHB (Per-Hop Behavior) dans DiffServ ?

Le comportement qu'un routeur applique à un paquet en fonction de son DSCP. Exemples : PHB EF = priority queue (LLQ), PHB AF41 = CBWFQ avec bandwidth garanti, PHB BE = WFQ. Chaque routeur applique son PHB indépendamment.

Quels sont les deux messages RSVP et leurs sens ?

PATH : du sender vers le receiver (→) — annonce les paramètres du flux. RESV : du receiver vers le sender (←) — confirme et réserve les ressources sur chaque routeur du chemin.

DiffServ garantit-il la qualité pour chaque flux voix individuellement ?

Non. DiffServ donne une garantie statistique par classe, pas par flux. Si trop de flux EF arrivent simultanément, les surplus sont droppés. C'est pourquoi DiffServ pour la voix doit s'accompagner d'un CAC (Call Admission Control).

Quelle est la commande IOS pour activer RSVP sur une interface ?

ip rsvp bandwidth [total-kbps] [max-per-flow-kbps]. Exemple : ip rsvp bandwidth 512 128 — 512 kbps total réservable, max 128 kbps par flux.

RSVP est-il hard-state ou soft-state ? Quelle conséquence ?

Soft-state : les réservations expirent si non rafraîchies (défaut : 30s). Si le flux RSVP de rafraîchissement est interrompu, la réservation disparaît automatiquement. C'est un mécanisme de sécurité — pas de réservation "zombie".

Dans quel cas utiliser IntServ plutôt que DiffServ ?

Quand une garantie absolue par flux est nécessaire dans un réseau fermé et contrôlé : MPLS Traffic Engineering (RSVP-TE pour les LSPs), réseau de broadcast vidéo critique, Call Manager Cisco avec RSVP CAC. Pas sur Internet public.

Référence commandes — IntServ/RSVP

!================================================
! RSVP — activation et configuration
!================================================
interface GigabitEthernet0/1
 ip rsvp bandwidth 512 128
 !  └─ 512 kbps total réservable sur cette interface
 !     128 kbps max par flux individuel

! Désactiver RSVP sur une interface
 no ip rsvp bandwidth

! RSVP avec authentification MD5
interface GigabitEthernet0/1
 ip rsvp authentication
 ip rsvp authentication key monmotdepasse

!================================================
! RSVP VÉRIFICATION
!================================================
show ip rsvp interface                ! Interfaces avec RSVP activé
show ip rsvp interface detail         ! Détail bande passante réservée
show ip rsvp reservation              ! Réservations actives
show ip rsvp sender                   ! Senders (PATH state)
show ip rsvp installed                ! Flux installés dans CEF
show ip rsvp request                  ! Requêtes en cours
show ip rsvp neighbor                 ! Voisins RSVP
debug ip rsvp detail                  ! Debug (verbeux !)

!================================================
! RSVP-TE (MPLS Traffic Engineering)
!================================================
mpls traffic-eng tunnels
interface GigabitEthernet0/1
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1000000

! Tunnel TE avec RSVP
interface Tunnel0
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng bandwidth 512
 tunnel mpls traffic-eng path-option 1 dynamic

show mpls traffic-eng tunnels
show ip rsvp installed detail

Note sur DiffServ — pas de commandes globales

DiffServ n'a pas de commande globale à activer — c'est un modèle, pas un protocole. Il s'implémente via MQC (class-map + policy-map + service-policy) que tu trouveras dans le chapitre 08 — MQC. Les PHBs EF/AF/BE se traduisent en priority, bandwidth, fair-queue dans les policy-maps.