Comment savoir si un commutateur Cisco gère bien le trafic?

Je viens de lire la question de Jeremy sur le 2960-S et la gestion du trafic iSCSI , ce qui m'a poussé à poser cette question: nous avons tous beaucoup de commutateurs déployés dans des infrastructures distinctes, comment savoir que le trafic est bien traité?

Je vérifie généralement le CPU, la RAM et les journaux système, mais je ne pense pas aux tampons.

J'ai utilisé des échecs de show buffers et voici un exemple des données:

show buffers failures 
Caller       Pool          Size      When
0x1279AE0   Middle           445    3d19h
0x1279AE0   Middle           446    3d19h
0x1279AE0   Middle           444    3d19h

Comment savoir sur quelle interface cela s'est produit?

Y a-t-il d'autres mesures de performance qui devraient être examinées?

Cela dépend du modèle de commutateur que vous avez et ce n'est pas si simple.

Les commutateurs Catalyst plus petits utilisent généralement au moins deux formes de tampon - il y a généralement un tampon de niveau interface, sur le plus petit Catalyst (2k / 3k) visible dans 'show buffers' sous la section intitulée 'Pools de tampons d'interface:':

Interface buffer pools:
Syslog ED Pool buffers, 600 bytes (total 132, permanent 132):
   100 in free list (132 min, 132 max allowed)
   11151 hits, 0 misses
RxQ1 buffers, 2040 bytes (total 128, permanent 128):
   4 in free list (0 min, 128 max allowed)
   244594209 hits, 4559839 fallbacks
RxQ2 buffers, 2040 bytes (total 128, permanent 128):
   1 in free list (0 min, 128 max allowed)
   202559241 hits, 1582494 fallbacks, 0 trims, 0 created
   1582494 failures (0 no memory)
...

... et il y a une zone "publique", où le CPU utilise les tampons car ils sont dirigés vers lui et ont besoin de maintenance. Les tampons de niveau "Rx" font partie du tampon partagé pour desservir toutes les interfaces (sur les anciens commutateurs hérités comme 2950 ou les plus récents 2960S / 3560X / etc ) ou un sous-ensemble d'interfaces, appartenant à un port ASIC spécifique (comme 2960 ou 3560 / 3750 / 3560E / 3750E ).

Sur les 4500 et 6500 en particulier, cela devient compliqué, car il y a un certain nombre de pools que le paquet peut traverser - tampon d'interface d'entrée (ASIC), le pool au niveau de la carte de ligne (sur le 6500 à DFC), au niveau de la matrice de commutation et à la fin le tampon au niveau du superviseur. Ils ne doivent pas nécessairement être des pools de mémoire physiquement séparés, mais sont souvent mappés dans des commandes différentes à des noms différents pour faciliter le processus de dépannage (à quelle étape de la procédure de traitement des paquets le paquet a-t-il été abandonné par exemple).

Jusqu'à présent, vous avez d'excellentes réponses.

Comme Lukasz le dit, la configuration du tampon est un peu complexe sur les commutateurs Catalyst. Il existe un pool à partir duquel vous affectez des tampons pour les 4 files d'attente de sortie. Vous pouvez choisir de réserver une certaine quantité de tampons et de laisser le reste dans une piscine et de l'utiliser au besoin. Les tampons réservés ne peuvent pas être touchés par d'autres files d'attente / seuils.

Pour voir les baisses sur différentes files d'attente / seuils, utilisez cette commande:

show platform port-asic stats drop gix/x

Si vous obtenez des échecs de tampon, j'utiliserais une commande comme celle-ci:

afficher l'interface | i (protocole de ligne | pas de tampon)

Vous devrez trier manuellement un peu la sortie, mais vous recherchez des lignes si vous n'avez plus de 0 aucune erreur de tampon comme celle-ci:

FasttEthernet0/24 is up, line protocol is up (connected)
     1557332164 packets input, 3733280910 bytes, 6718 no buffer