Ce document discute des défaillances et des pannes de mémoire tampon sur le processeur de routage (RP).
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Le RP divise sa mémoire processeur en pools. Chaque pool contient un certain nombre de blocs de mémoire de taille égale. Ces blocs de mémoire sont appelés tampons.
Il existe six pools de mémoires tampon :
Petites : mémoires tampon de 104 octets
Mémoire tampon moyenne de 600 octets
Grande mémoire tampon de 1 524 octets
Très volumineux : mémoires tampon de 4 520 octets
Grandes : mémoires tampon de 5 024 octets
Énorme : mémoires tampon de 1 8024 octets
Par exemple, si un processeur d'interface doit transmettre un paquet de 20 octets au RP, il “ demander ” tampon de petite taille. Si un processeur d'interface doit transmettre un paquet de 500 octets au RP, il demande une mémoire tampon intermédiaire, etc.
Remarque : le processeur d'interface doit demander un tampon d'une certaine taille.
Lorsque le processeur d'interface demande une mémoire tampon, ceci se produit :
Si un tampon libre existe dans le pool demandé, le tampon est accordé. Sinon, la requête génère une ” manquante “ et l'algorithme de tampon tente de “ créer ” plus de mémoires tampon pour ce pool .
Quand IOS n'obtient pas de tampon de petite taille, il ne supprime pas le paquet. Il incrémente le compteur défaillant et passe à la mémoire tampon de niveau suivant, qui est la mémoire tampon du milieu et demande une mémoire tampon à cet endroit. S'il ne parvient pas à obtenir un tampon moyen, il demande le tampon de niveau suivant, qui est un tampon Big. Ce processus se poursuit jusqu'à ce qu'il atteigne le pool de tampons Huge. S'il ne parvient pas à obtenir un tampon énorme, alors il abandonne le paquet.
Lorsque vous utilisez le jeu de fonctions IBM, une erreur génère presque toujours une défaillance.
Bien que les fonctionnalités IBM puissent être commutées par processus, le code permettant d'obtenir un tampon pour passer un paquet d'une interface au RP s'exécute au niveau d'interruption.
Impossible de créer des tampons au niveau d'interruption ; par conséquent, un miss met en file d'attente sa demande pour plus de mémoires tampon au RP.
Étant donné qu'une mémoire tampon supplémentaire ne peut pas être créée sur place, la requête de mémoire tampon échoue et le paquet est abandonné.
Les pannes de mémoire tampon sont l'une des raisons les plus courantes des abandons de paquets. Lorsque des pertes de paquets se produisent en raison d'une défaillance de la mémoire tampon, ceci se produit :
Après une défaillance de la mémoire tampon, le RP a une requête en attente pour créer plus de mémoires tampon de la taille appropriée pour le pool particulier.
Pendant que le RP traite la demande de création de mémoires tampon, il peut y avoir d'autres échecs dans le pool.
Le RP peut même ne pas créer davantage de mémoires tampon, en raison de contraintes de mémoire dans le système lorsque les mémoires tampon supplémentaires sont nécessaires.
Essentiellement, l'opération de création de tampons peut prendre plusieurs microsecondes, dans lesquelles les paquets sont continuellement abandonnés en raison de la pénurie de tampon.
En outre, si les mémoires tampon sont utilisées aussi rapidement qu'elles sont créées, le RP peut être forcé de passer plus de temps sur la création de mémoire tampon que sur le traitement des paquets.
Cela peut faire que le RP commence à abandonner les paquets si rapidement que les performances se dégradent et que les sessions sont perdues.
Heureusement, comme nous l'expliquons dans ce document, les problèmes de défaillance de tampon ne sont pas difficiles à identifier et à résoudre. Cette sortie de commande show buffers montre l'état actuel des pools de tampons du routeur :
dspu-7k#show buffers Buffer elements: 500 in free list (500 max allowed) 2370 hits, 0 misses, 0 created Public buffer pools: Small buffers, 104 bytes (total 16, permanent 10): 11 in free list (0 min, 10 max allowed) 1770 hits, 33 misses, 22 trims, 28 created 9 failures (0 no memory) Middle buffers, 600 bytes (total 90, permanent 90): 89 in free list (10 min, 200 max allowed) 590 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Big buffers, 1524 bytes (total 90, permanent 90): 90 in free list (5 min, 300 max allowed) 126 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 10, permanent 10): 10 in free list (0 min, 300 max allowed) 50 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 10, permanent 10): 10 in free list (0 min, 30 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 2, permanent 0): 0 in free list (0 min, 13 max allowed) 2 hits, 2 misses, 0 trims, 2 created 0 failures (0 no memory)
Dans la sortie show buffers :
Total identifie le nombre total de mémoires tampon dans le pool, qui incluent les mémoires tampon utilisées et inutilisées.
Permanent identifie le nombre permanent de tampons alloués dans le pool. Ces tampons sont toujours dans le pool et ne peuvent pas être éliminés.
Dans la liste libre identifie le nombre de tampons actuellement dans le pool qui sont disponibles pour utilisation.
Min identifie le nombre minimal de mémoires tampon que le RP doit tenter de conserver dans la liste libre :
Le paramètre min est utilisé pour anticiper la demande de tampons du pool à un moment donné.
Si le nombre de mémoires tampon dans la liste libre est inférieur à la valeur min, le RP tente de créer plus de mémoires tampon pour ce pool.
Max-allowed identifie le nombre maximal de mémoires tampon autorisées dans la liste libre :
Le paramètre max-allowed empêche un pool de monopoliser des tampons dont il n'a plus besoin. Il libère également cette mémoire au système pour une utilisation ultérieure.
Si le nombre de tampons dans la liste libre est supérieur à la valeur max-allowed, le RP doit tenter de réduire les tampons à partir du pool.
Les résultats indiquent le nombre de mémoires tampon qui ont été demandées au pool. Le compteur de résultats fournit un mécanisme permettant de déterminer quel pool doit répondre à la demande la plus élevée pour les tampons.
Les échecs identifient le nombre de fois où une mémoire tampon a été demandée et le RP détecté dans lequel des mémoires tampon supplémentaires du pool étaient nécessaires. En d'autres termes, le nombre de tampons dans la liste libre a chuté sous le niveau min. Le compteur manquant représente le nombre de fois où le RP a été forcé de créer des mémoires tampon supplémentaires.
Trims identifie le nombre de tampons que le RP a coupé à partir du pool, lorsque le nombre de tampons dans la liste libre a dépassé le nombre de tampons max-allowed.
Créé identifie le nombre de mémoires tampon créées dans le pool. Le RP crée des tampons dans les situations suivantes :
Lorsque la demande de tampons a augmenté jusqu'à ce que le nombre de tampons dans la liste libre soit inférieur à la min buffers.
Une erreur se produit parce qu'il n'y a aucune mémoire tampon dans la liste libre.
Les deux situations précédentes.
Les échecs identifient quand IOS ne parvient pas à obtenir un petit tampon, il ne supprime pas le paquet. Il incrémente le compteur défaillant et passe à la mémoire tampon de niveau suivant, qui est la mémoire tampon du milieu et demande une mémoire tampon à cet endroit. S'il ne parvient pas à obtenir un tampon intermédiaire, il demande le tampon de niveau suivant, qui est un tampon Big. Ce processus se poursuit jusqu'à ce qu'il atteigne le pool de tampons Huge. S'il ne parvient pas à obtenir un tampon énorme, alors il abandonne le paquet.
Aucune mémoire n'identifie le nombre de pannes causées par une mémoire insuffisante pour créer des mémoires tampon supplémentaires.
Vous pouvez examiner les caractéristiques de chaque pool pour déterminer quels pools (s'il y en a) rencontrent des problèmes. Les paramètres d'un pool peuvent être réglés pour permettre au routeur d'être mieux préparé à gérer la charge, si le pool semble présenter les caractéristiques suivantes :
Nombre d'échecs et crée un incrément à un taux élevé (en pourcentage des résultats).
Il y a un nombre constamment faible de mémoires tampon dans la liste libre.
Nombre d'échecs ou d'incréments de mémoire.
Avec la commande de configuration buffers, vous pouvez régler ces paramètres pour chaque pool de tampons :
initial : tampons temporaires alloués au rechargement du système.
max-free : nombre maximal de mémoires tampon libres.
min-free : nombre minimum de mémoires tampon libres.
permanent : nombre de tampons permanents.
Régler les tampons initiaux pour tenir compte de la rafale du trafic d'établissement de session après le rechargement du routeur.
buffers small initial 250
Ces mémoires tampon sont finalement “ ajustées ” et retournées au système.
Les tampons initiaux sont conçus pour gérer l'établissement de la session, qui est toujours commuté par processus.
Lors de l’établissement de la session, le cache de commutation rapide (utilisé par d’autres protocoles de route) est rempli ; les mémoires tampon commutées par processus ne sont plus nécessaires et peuvent être retournées au système.
Régler les mémoires tampon initiales n'est peut-être pas la solution appropriée pour l'ensemble de fonctionnalités IBM, car presque tous les paquets (après l'établissement de la session) sont commutés par processus et nécessitent de toute façon la mise en mémoire tampon supplémentaire.
Remarque : Pour les fonctionnalités commutées par processus IBM, vous devez régler les tampons permanents plutôt que les tampons initiaux temporaires.
Régler les tampons max-free de sorte que la valeur soit égale ou supérieure aux tampons permanents. Si toutes les mémoires tampon permanentes figurent dans la liste libre, le RP ne doit pas essayer de réduire les mémoires tampon permanentes. Max-free peut être utilisé pour s'assurer que les mémoires tampon inutilisées créées lors de rafales irrégulières sont retournées à la mémoire système.
buffers small max-free 175 buffers small permanent 125
Régler les tampons min-free de sorte que la valeur représente le nombre minimum estimé de tampons requis à tout moment. Min-free peut être utilisé pour anticiper les conditions de pénurie de mémoire tampon et pour s'assurer qu'un nombre minimum de mémoires tampon est toujours disponible.
buffers small min-free 50
Régler les tampons permanents de sorte que la valeur représente le nombre estimé de tampons requis pour le traitement normal.
buffers small permanent 125
Les tampons permanents sont utilisés pour répondre aux exigences normales de la mémoire tampon (y compris les rafales fréquentes) du routeur. La détermination des exigences normales de mémoire tampon est un processus interactif, où la sortie show buffer doit afficher le total des mémoires tampon utilisées dans un pool à un moment donné. Les tampons permanents doivent être réglés en fonction des tampons « totaux » cohérents requis. Lorsque vous réglez les tampons permanents, vous devez vous concentrer sur la réduction des créations et l'élimination des échecs et des échecs.
Il existe deux autres commandes show que vous pouvez utiliser pour identifier les problèmes d'allocation de tampon :
show interfaces interface-identifier
show source-bridge
Cet exemple de sortie de commande show interfaces interface-identifier inclut un compteur pour no buffer :
dspu-7k#show interfaces channel 4/2 Channel4/2 is up, line protocol is up Hardware is cxBus IBM Channel MTU 4472 bytes, BW 98304 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation CHANNEL, loopback not set, keepalive not set Virtual interface Last input 0:00:04, output 0:00:04, output hang never Last clearing of "show interface" counters never Output queue 0/40, 0 drops; input queue 0/75, 8 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 646 packets input, 27760 bytes, 8 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 328 packets output, 16959 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets, 0 restarts 0 output buffer failures, 0 output buffers swapped out
Dans le résultat de la commande show interfaces interface-identifier :
Le compteur no buffer s'incrémente lorsque l'interface n'obtient pas de tampon pour un paquet entrant.
Les compteurs no buffer et drops (file d'attente d'entrée) s'incrémentent lorsque l'interface n'obtient pas de tampon pour un paquet entrant.
Un compteur sans tampon qui s'incrémente dans la sortie show interfaces est corrélé au compteur manquant qui s'incrémente dans la sortie show buffers. Le pool de tampons approprié peut être réglé.
Cet exemple de sortie de commande show source-bridge inclut un compteur d'interface pour les restrictions, lorsque le pontage source-route (SRB) est configuré pour l'interface :
dspu-7k#show source-bridge Local Interfaces: receive transmit srn bn trn r p s n max hops cnt:bytes cnt:bytes drops Ch4/2 666 1 99 * f 7 7 7 652:26020 6:266 0 Global RSRB Parameters: TCP Queue Length maximum: 100 Ring Group 99: This TCP peer: 150.10.20.2 Maximum output TCP queue length, per peer: 100 Peers: state bg lv pkts_rx pkts_tx expl_gn drops TCP TCP 150.10.20.1 open *3 261 266 0 0 0 TCP 150.10.20.2 - *3 0 0 0 0 0 Rings: bn: 1 rn: 888 locvrt ma: 4000.7000.fff1 Buff Ring888 fwd: 0 bn: 1 RN: 666 local ma: 4000.0c48.2e80 Channel4/2 fwd: 261 bn: 1 RN: 88 remote ma: 4000.4000.fff1 TCP 150.10.20.1 fwd: 322 bn: 1 RN: 250 remote ma: 4000.300f.7c09 TCP 150.10.20.1 fwd: 0 Explorers: ------- input ------- ------- output ------- spanning all-rings total spanning all-rings total Ch4/2 0 0 0 0 1 1 Local: fastswitched 0 flushed 0 max Bps 256000 rings inputs bursts throttles output drops Ch4/2 0 0 8 0
Dans la sortie de commande show source-bridge :
Le compteur de régulation s'incrémente lorsque l'interface n'obtient pas de tampon pour un paquet entrant.
Le compteur de restrictions qui s'incrémente dans la sortie de la commande show interfaces est corrélé à un compteur de pertes qui s'incrémente dans la sortie de la commande show buffers. Le pool de tampons approprié peut être réglé.