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. |
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
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
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
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
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.
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.