Examinons de plus près la commande « show buffers » :
#show buffers
Buffer elements:
1116 in free list (1119 max allowed)
14344198 hits, 0 misses, 619 created
Public buffer pools:
Small buffers, 104 bytes (total 50, permanent 50, peak 80 @ 7w0d):
45 in free list (20 min, 150 max allowed)
4382143 hits, 14 misses, 30 trims, 30 created
0 failures (0 no memory)
Middle buffers, 600 bytes (total 75, permanent 25, peak 104 @ 1w5d):
40 in free list (10 min, 150 max allowed)
4410481 hits, 11530 misses, 7219 trims, 7269 created
2618 failures (0 no memory)
Big buffers, 1536 bytes (total 50, permanent 50, peak 110 @ 2w3d):
45 in free list (5 min, 150 max allowed)
3756688 hits, 546 misses, 1539 trims, 1539 created
8 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10):
10 in free list (0 min, 100 max allowed)
8 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Large buffers, 5024 bytes (total 0, permanent 0):
0 in free list (0 min, 10 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 0, permanent 0):
0 in free list (0 min, 4 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
On Remarque la présence de plusieurs Pool de buffers : « Small buffers, Middle buffers, … ». La commande nous renseigne les champs suivants :
  • Nom du pool de buffer + taille des buffers dans ce pool
    • Total : nombre total de buffers dans le pool (actuellement)
    • Permanent : nombre de buffers permanent et minimum du pool (on ne descendra jamais en dessous de cette valeur)
    • Peak : nombre maximal de buffers atteint dans ce pool @ quand
  • In free list : nombre de buffers libres dans le pool
    • Min : nombre minimum de buffers libres dans le pool (si il venait a y en avoir moins, l’IOS en allouerait de nouveaux)
    • Max allowed : nombre maximum de buffers libres dans le pool (si il venait a y en avoir plus l’IOS essaierait d’en supprimer tout en ne descendant jamais en dessous de la limite « Permanent »)
  • Hits : nombre de buffers qui ont été demandé dans ce pool
    • Misses : nombre de fois qu’un buffer a été demandé alors que la valeur de « In Free List » était inférieure à « Min »
    • Trims : nombre de buffers qui ont été supprimé par l’IOS dans le pool (par exemple lorsque « Max allowed » était dépassé)
    • Created : nombre de buffers qui ont été ajouté au pool parce que la taille du pool ne suffisait plus.
  • Failures : nombre de fois qu’un buffer a été demandé et qu’il n’a pu être fourni. (si une demande de buffer intervient pendant une interrupt, on ne sait pas augmenter la taille du pool de buffers et on ne sait pas satisfaire la demande)
    • No memory : nombre de fois qu’un buffer a été demandé et qu’il n’y avait pas assez de buffers libres ni assez de mémoire libre pour satisfaire la demande.
Prenons un exemple pour mieux comprendre ces informations : image Le pool Small buffers contient 10 buffers (10 libres / 10 buffers en permanence).
#show buffers
Small buffers, 104 bytes (total 10, permanent 10)
10 in free list (5 min, 8 max allowed)
0 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
image On reçoit 5 paquets, l’IOS alloue 5 buffers « 5 hits ».
#show buffers
Small buffers, 104 bytes (total 10, permanent 10)
5 in free list (5 min, 8 max allowed)
5 hits, 0 misses, 0 trims, 0 created
0 failures (0 no memory)
image On reçoit 4 paquets supplémentaires (hits+=4) « 9 hits ». La demande de 4 buffers provoque « 4 misses » car les 4 buffers font tomber le compteur de buffers libres en dessous du minimum de ce pool « 1 in free list / 5 min »
#show buffers
Small buffers, 104 bytes (total 10, permanent 10)
1 in free list (5 min, 8 max allowed)
9 hits, 4 misses, 0 trims, 0 created
0 failures (0 no memory)
image Vu que le nombre de buffers libre est inférieur au minimum, l’IOS alloue 4 buffers supplémentaires pour le satisfaire « 4 created ».
#show buffers
Small buffers, 104 bytes (total 14, permanent 10)
5 in free list (5 min, 8 max allowed)
9 hits, 4 misses, 0 trims, 4 created
0 failures (0 no memory)
image On reçoit 6 paquets supplémentaires. Il n’y a de place que pour 5 de ces paquets (hits+5) « 14 hits ». Le paquet n’ayant pas eu de buffer est perdu « 1 failure ». La demande de 6 buffers a provoqué (4+6 misses) « 10 misses » car le minimum n’est plus respecté.
#show buffers
Small buffers, 104 bytes (total 14, permanent 10)
0 in free list (5 min, 8 max allowed)
14 hits, 10 misses, 0 trims, 4 created
1 failures (0 no memory)
image Certains buffers qui étaient utilisés sont libérés « 12 in free list »
#show buffers
Small buffers, 104 bytes (total 14, permanent 10)
12 in free list (5 min, 8 max allowed)
14 hits, 10 misses, 0 trims, 4 created
1 failures (0 no memory)
image Le nombre de buffers libre est supérieur au maximum autorisé. L’IOS supprime l’excédant de buffers « 4 trims ».
#show buffers
Small buffers, 104 bytes (total 10, permanent 10)
8 in free list (5 min, 8 max allowed)
14 hits, 10 misses, 4 trims, 4 created
1 failures (0 no memory)
L’exemple ci-dessus montre le fonctionnement d’un pool de buffers dynamique. Certains pool de buffers sont statiques (pas d’allocation / suppression de buffers à la demande). Tous les buffers d’un pool de buffers donné possèdent la même taille. Cette taille est légèrement plus grande que le MTU typique d’un paquet provenant d’une interface. Grâce à cet espace supplémentaire, un processus peut ajouter des données au header du paquet lors de son traitement.
Small buffers, 104 bytes
Middle buffers, 600 bytes
Big buffers, 1536 bytes
VeryBig buffers, 4520 bytes
Large buffers, 5024 bytes
Huge buffers, 18024 bytes
Une interface possède un pool de buffer privé « Private particle pools » dont elle est seule à profiter. Lorsque son pool est plein, elle peut se servir dans un des publics pools (Small buffers, Middle buffers, …).
#show buffers
Private particle pools:
FastEthernet0/0 buffers, 1552 bytes (total 512, permanent 512):
0 in free list (0 min, 512 max allowed)
512 hits, 0 fallbacks
512 max cache size, 256 in cache
62643951 hits in cache, 0 misses in cache
N’importe quel processus peut demander un buffer provenant d’un public pool. Le traitement d’un paquet n’est pas nécessaire pour pouvoir effectuer cette demande. Un particle pool est un pool spécial, permettant à un paquet plus grand que la taille d’un des buffers de ce pool, de prendre plusieurs buffers contigus grâce à un chaînage. Cela permet d’accepter un paquet de virtuellement n’importe quelle taille. (buffer overflow difficile !). Dans le prochain post de cette lignée : Les méthodes de « packet switching ».