Token Bucket – QoS – CCIE

Le générateur de jetons

Le générateur de jetons est une horloge interne qui produit des jetons à intervalle régulier. Ce n'est pas aléatoire — c'est une fréquence fixe, dérivée mathématiquement du CIR que tu configures.

🟡

↓ BC jetons / Tc

Bucket (BC max)

CIR — Committed Information Rate

La vitesse de génération des jetons, exprimée en bits/s. C'est le débit que tu "contractes". Le générateur produit exactement CIR bits de jetons par seconde — pas plus.

CIR = 512 000 bps → 512 000 jetons/s

Tc — Timing Interval

L'intervalle entre chaque dépôt de jetons dans le bucket. Le générateur ne dépose pas jeton par jeton en continu — il accumule pendant Tc puis dépose d'un coup.

Tc = BC / CIR (en secondes)

BC — Burst Committed

La quantité de jetons déposée à chaque Tc. C'est aussi la taille maximale du bucket. Les 3 paramètres sont liés — tu ne peux pas les choisir indépendamment.

BC = CIR × Tc

La relation mathématique fondamentale

Exemple : CIR = 512 000 bps, Tc = 125 ms

BC = CIR × Tc
BC = 512 000 × 0.125
BC = 64 000 bits = 8 000 octets

Toutes les 125 ms, le générateur dépose 64 000 bits de jetons dans le bucket.
Sur 1 seconde complète → 8 dépôts × 64 000 bits = 512 000 bits = CIR ✓

Comparaison selon le Tc

Tc	Dépôts/seconde	BC déposé	Effet
125 ms (défaut)	8	CIR/8	Équilibré — recommandé
10 ms	100	CIR/100	Très granulaire — voix/vidéo
500 ms	2	CIR/2	Gros bursts autorisés
1 000 ms	1	CIR	1 dépôt/s — pas recommandé

Le Bucket

Le bucket (seau) est simplement un compteur de jetons. Pas un buffer réseau, pas une file d'attente — juste un compteur qui monte et descend.

Propriétés du bucket

Propriété	Valeur	Explication
Taille maximale	BC (bits)	Le bucket ne peut pas contenir plus de BC jetons. Les jetons excédentaires sont perdus — le bucket ne déborde pas, il rejette.
Taille initiale	BC (plein)	Au démarrage, le bucket commence plein. Le premier burst est autorisé immédiatement.
Implémentation	Logiciel	C'est un simple entier en mémoire — pas de hardware dédié. Très léger à implémenter.
Coût de fabrication	Quasi nul	Un compteur 32 ou 64 bits en RAM. Pas de ASIC, pas de buffer physique. C'est pourquoi la QoS est scalable.
Localisation	Par interface / par classe	Chaque class-map dans une policy-map a son propre bucket indépendant.

Le bucket ne déborde pas — il rejette

Bucket plein (BC = 64 000 bits) :
  Générateur tente de déposer 64 000 bits supplémentaires
  → Bucket already at max → jetons supplémentaires PERDUS
  → Pas d'erreur, pas de log — silencieux

Conséquence : si le trafic est absent pendant longtemps,
le bucket reste plein à BC — pas au-delà.
Le "crédit accumulé" est limité à BC.

Ce que le bucket n'est PAS

Idée reçue	Réalité
Le bucket stocke des paquets	❌ Non — il stocke des jetons (compteur). Les paquets ne sont jamais "dans" le bucket.
Plus le bucket est grand, mieux c'est	❌ Non — un BC trop grand autorise des bursts massifs qui impactent les autres flux.
Le bucket est un buffer hardware	❌ Non — c'est un entier en RAM. Différent des buffers de queue (CBWFQ, FIFO).
Le bucket vide = paquet droppé	⚠️ Dépend : en policing oui, en shaping le paquet attend dans une queue.

Le PIR

Le PIR (Peak Information Rate) n'est pas une option qui agrandit le bucket C — c'est un second générateur de jetons, totalement indépendant, avec son propre bucket : le bucket P. Ce bucket P a exactement les mêmes propriétés mécaniques que le bucket C vu dans l'onglet précédent, juste à un débit et une taille différents.

Propriétés du bucket P

Propriété	Valeur	Explication
Débit de génération	PIR (bps)	Toujours strictement supérieur à CIR — c'est la définition même du débit "de crête". Si PIR = CIR, le Dual Rate n'a aucun intérêt par rapport au Single Rate.
Taille maximale	PBS (bits)	Peak Burst Size — l'équivalent du BC, mais pour le bucket P. Formule identique : PBS = PIR × Tc.
Taille initiale	PBS (plein)	Comme le bucket C, le bucket P démarre plein au boot — un burst immédiat est possible sur les deux buckets dès le départ.
Implémentation	Logiciel, indépendant du bucket C	Deux compteurs entiers distincts en RAM. Aucun lien physique entre eux — seulement une relation logique dans l'algorithme de décision (trTCM).
Localisation	Par classe, comme le bucket C	Chaque class-map avec un policer Dual Rate porte DEUX compteurs indépendants : un bucket C et un bucket P, chacun avec sa propre horloge de remplissage.

Le bucket P ne se remplit PAS par débordement du bucket C

Erreur fréquente : penser que le bucket P se remplit quand le bucket C déborde,
comme le fait le bucket Be dans le Single Rate Three Color.

Réalité — deux horloges indépendantes qui tournent en parallèle :
  t=0ms   : bucket C = BC (plein), bucket P = PBS (plein)
  t=125ms : générateur CIR dépose ses jetons dans C — indépendamment
            générateur PIR dépose ses jetons dans P — indépendamment
  t=250ms : idem, chaque générateur tourne à son propre rythme

Le bucket C peut être vide pendant que le bucket P est encore à moitié plein —
ce sont deux réservoirs séparés, jamais connectés physiquement.

Ce que le PIR n'est PAS

Idée reçue	Réalité
PIR est juste un CIR plus gros	❌ Non — ce n'est pas une valeur qu'on agrandit, c'est un mécanisme à part avec son propre générateur et son propre bucket.
Le bucket P, c'est la même chose que le Be du Single Rate	❌ Non — le Be du Single Rate se remplit par débordement du bucket C (un seul générateur). Le bucket P a son propre générateur à PIR, jamais par débordement.
Sans trafic longtemps, le bucket P finit par dépasser PBS	❌ Non — comme tout bucket, il plafonne à PBS. Aucun bucket n'accumule au-delà de sa taille max, quelle que soit la durée d'inactivité.
En CONFORM, seul le bucket C perd des jetons	⚠️ Faux pour le Dual Rate — en trTCM, les DEUX buckets C et P sont débités en CONFORM. Détail complet dans l'onglet Single vs Dual.

Les Jetons

Un jeton représente l'autorisation de transmettre un bit (ou un octet, selon l'implémentation). Sur Cisco IOS, 1 jeton = 1 bit.

Cycle de vie d'un jeton

1. NAISSANCE : le générateur crée des jetons au rythme CIR bps
              → toutes les Tc ms, BC jetons sont ajoutés au bucket

2. STOCKAGE : les jetons attendent dans le bucket (max BC jetons)
             → si bucket plein → nouveaux jetons perdus

3. CONSOMMATION : à l'arrivée d'un paquet, le système vérifie
                 si le bucket contient suffisamment de jetons
                 → Paquet de 1500 octets = 12 000 bits = 12 000 jetons requis

4. DÉCISION :
   bucket ≥ 12 000 jetons → CONFORM → paquet transmis, jetons débités
   bucket < 12 000 jetons → EXCEED/VIOLATE → selon la politique

Granularité : bits vs octets

Implémentation	1 jeton =	Bucket pour 512 kbps
Cisco IOS (police)	1 bit	BC en bits
Cisco IOS (shape)	1 bit	BC en bits
Certaines implém. Linux	1 octet	BC en octets

Que se passe-t-il pendant une période sans trafic ?

t=0s   : bucket = BC (plein au démarrage)
t=1s   : aucun trafic → bucket reste plein (nouveaux jetons perdus)
t=10s  : aucun trafic → bucket toujours à BC — pas de "crédit accumulé"
t=10.1s: burst de trafic → bucket plein disponible → burst autorisé jusqu'à BC

Conclusion : le bucket NE s'accumule PAS au-delà de BC.
Une heure de silence ne donne pas plus de "crédit" qu'une seconde de silence.
Le crédit maximum est toujours limité à BC bits.

Le paquet doit payer en jetons

À chaque arrivée d'un paquet, le système effectue une vérification atomique : le bucket contient-il assez de jetons pour "payer" ce paquet ? La décision est immédiate — pas de calcul complexe.

L'algorithme de décision

À l'arrivée du paquet :
  tokens_requis = taille_paquet_en_bits

  if bucket_courant ≥ tokens_requis:
      bucket_courant -= tokens_requis
      action = CONFORM   ← paquet dans la bande

  elif (bucket_courant + be_bucket) ≥ tokens_requis:  ← dual bucket seulement
      be_bucket -= (tokens_requis - bucket_courant)
      bucket_courant = 0
      action = EXCEED    ← paquet hors CIR mais dans Be

  else:
      action = VIOLATE   ← paquet au-delà de tout seuil

✅

CONFORM

Le bucket contient assez de jetons. Le paquet est dans la bande CIR. Action typique : transmit

⚠️

EXCEED

Bucket CIR vide mais bucket Be disponible (dual bucket). Paquet hors CIR mais dans le burst étendu. Action : transmit ou drop selon config

🚫

VIOLATE

Les deux buckets sont vides. Paquet au-delà de tout seuil autorisé. Action typique : drop

Exemple chiffré — paquet qui paie

Config : CIR = 512 kbps, BC = 64 000 bits, Tc = 125 ms
État   : bucket = 64 000 jetons (plein)

Arrivée paquet #1 : 1500 octets = 12 000 bits
  bucket = 64 000 - 12 000 = 52 000 jetons → CONFORM ✓

Arrivée paquet #2 : 1500 octets = 12 000 bits
  bucket = 52 000 - 12 000 = 40 000 jetons → CONFORM ✓

... 3 paquets de plus ...
  bucket = 4 000 jetons

Arrivée paquet #6 : 1500 octets = 12 000 bits requis
  bucket = 4 000 < 12 000 → EXCEED/VIOLATE ✗

après Tc = 125 ms → le générateur a produit CIR × Tc = 64 000 jetons
  bucket = min(4 000 + 64 000, 64 000) = 64 000 jetons (plein à nouveau)

Single Bucket vs Dual Bucket

Single Rate — Two Color (1 bucket)

Un seul bucket de taille BC. Deux décisions possibles : CONFORM ou EXCEED. C'est le modèle de base, suffisant pour la majorité des cas.

BC

Token Bucket

Taille = BC

→ CONFORM (transmit)
→ EXCEED (drop/transmit)

Cisco IOS — Single Rate Two Color :
police rate 512000 bps burst 64000
  conform-action transmit
  exceed-action  drop

Single Rate — Three Color (2 buckets : BC + Be)

Deux buckets en cascade. Le premier bucket (BC) se vide en premier. Si vide, le deuxième bucket (Be) prend le relais. Trois décisions : CONFORM / EXCEED / VIOLATE.

BC

Bucket 1

CIR tokens

→

Be

Bucket 2

Burst étendu

→ CONFORM (transmit)
→ EXCEED (transmit/set-dscp)
→ VIOLATE (drop)

Cisco IOS — Single Rate Three Color :
police rate 512000 bps burst 64000 peak-burst 128000
  conform-action transmit
  exceed-action  set-dscp-transmit AF11   ← re-mark et laisse passer
  violate-action drop

Le PIR — Peak Information Rate (Dual Rate Three Color)

Le Dual Rate est souvent réduit à tort à "un bucket de plus". En réalité la mécanique change complètement : il y a deux générateurs de jetons indépendants, chacun avec son propre débit et son propre bucket. Contrairement au Be du Single Rate Three Color — qui se remplit uniquement par débordement du bucket CIR — le bucket PIR a sa propre horloge et son propre débit, totalement indépendant du CIR.

⚡ génère à CIR

C

Bucket C

taille = BC = CIR × Tc

⚡ génère à PIR

P

Bucket P

taille = PBS = PIR × Tc

Formule du PBS

Exemple : CIR = 512 000 bps, PIR = 1 024 000 bps, Tc = 125 ms

BC  = CIR × Tc = 512 000 × 0.125 = 64 000 bits
PBS = PIR × Tc = 1 024 000 × 0.125 = 128 000 bits

Le bucket P est toujours ≥ au bucket C, puisque PIR > CIR par définition.

L'algorithme de décision (RFC 2698 — trTCM)

À l'arrivée du paquet :
  tokens_requis = taille_paquet_en_bits

  if P_bucket < tokens_requis:
      action = VIOLATE   ← même le bucket le plus permissif (PIR) est insuffisant

  elif C_bucket < tokens_requis:
      P_bucket -= tokens_requis
      action = EXCEED    ← débit CIR dépassé, mais dans l'enveloppe PIR — seul P est débité

  else:
      C_bucket -= tokens_requis
      P_bucket -= tokens_requis
      action = CONFORM   ← les DEUX buckets sont débités

Config Cisco IOS — Two-Rate Policer

Cisco IOS — Dual Rate Three Color (trTCM) :
police cir 512000 bc 64000 pir 1024000 be 128000
  conform-action transmit
  exceed-action  set-dscp-transmit AF11
  violate-action drop

Ici, "bc" = taille du bucket C (CIR) et "be" = taille du bucket P (PIR).
Nommage IOS trompeur : ce "be" n'est PAS le Be du Single Rate 3-color — c'est le PBS.

Comparaison rapide

Modèle	Buckets	Décisions	Usage typique
Single Rate 2-color	1 (BC)	CONFORM / EXCEED	Policing simple, accès internet
Single Rate 3-color	2 (BC + Be)	CONFORM / EXCEED / VIOLATE	Policing avec burst toléré + re-mark
Dual Rate 3-color	2 (CIR + PIR)	CONFORM / EXCEED / VIOLATE	MPLS DiffServ, provider QoS

🎮 Simulateur Token Bucket

Règle le CIR et le BC, envoie des paquets, observe le bucket en temps réel.

⚙️ Token Bucket — Single Rate Two Color

CIR (bps) 256 000

BC (bits) 32 000

Tc calculé 125 ms

ENVOYER UN PAQUET :

⚡ génère 32 000 bits / 125ms

🟡

32 000

100% plein

max: 32 000 bits

JETONS DISPONIBLES

32 000 bits

DERNIER PAQUET

—

DÉCISION

—

STATISTIQUES

✅ CONFORM: 0
⚠️ EXCEED: 0
🚫 VIOLATE: 0

JOURNAL :

// Prêt — configurez CIR et BC, puis envoyez un paquet

Flash Cards — Token Bucket

Clique pour révéler la réponse.

Quelle est la relation mathématique entre CIR, BC et Tc ?

BC = CIR × Tc
ou Tc = BC / CIR

Exemple : CIR=512 kbps, Tc=125ms → BC = 512 000 × 0.125 = 64 000 bits

Que se passe-t-il quand le bucket est plein et que le générateur continue ?

Les jetons excédentaires sont perdus — le bucket ne déborde pas, il rejette silencieusement. Le niveau maximum reste BC.

Combien de jetons coûte un paquet de 1500 octets sur Cisco IOS ?

1 500 octets × 8 = 12 000 bits = 12 000 jetons. Sur IOS, 1 jeton = 1 bit.

Quelle est la taille initiale du bucket au démarrage ?

BC — le bucket commence plein. Cela autorise un burst immédiat dès le démarrage, avant même que le générateur ait eu le temps de remplir.

Quelle est la différence entre CONFORM, EXCEED et VIOLATE ?

CONFORM : bucket CIR suffisant → dans la bande
EXCEED : bucket CIR vide, bucket Be disponible → hors CIR mais dans burst
VIOLATE : les deux buckets vides → au-delà de tout seuil

Qu'est-ce que Be dans un dual-bucket ?

Be = Burst Excess. Le deuxième bucket qui permet un burst au-delà du CIR. Il se remplit moins vite que BC (ou selon la config PIR). Les paquets EXCEED peuvent être transmis avec un DSCP dégradé ou droppés selon la policy.

1 heure sans trafic = combien de jetons accumulés ?

BC jetons — pas plus. Le bucket est limité à BC. L'absence de trafic ne crée pas de crédit supplémentaire. Le bucket reste plein à BC maximum.

Le bucket est-il implémenté en hardware ou software ?

Software — c'est un simple compteur entier en RAM. Très léger, pas de ASIC dédié. C'est pourquoi on peut avoir des dizaines de class-maps avec chacune leur bucket sans impact significatif sur les ressources.

Quelle est la différence fondamentale entre policing et shaping vis-à-vis du bucket ?

Policing : bucket vide → paquet droppé immédiatement
Shaping : bucket vide → paquet mis en attente dans une queue jusqu'au prochain remplissage

Même mécanisme de bucket, comportement opposé sur les paquets exceed.

→ détaillé dans les pages Policing et Shaping

Quel est le Tc par défaut sur Cisco IOS ?

125 ms (8 intervalles par seconde). C'est le compromis standard entre granularité et charge CPU. Il peut être modifié en changeant BC dans la commande police.

Token Bucket — Le cœur mécanique de la QoS