Qu'est-ce qui cause les baisses de sortie totales sur une interface de commutateur Cisco?

J'ai un châssis de lame HP c7000 qui contient des commutateurs Cisco 3120X et Cisco 3120G exécutant ios 12.2 (58) SE1. Les lames elles-mêmes sont très légèrement chargées, mais de nombreuses interfaces sur différents commutateurs de lames dans le châssis affichent un nombre assez élevé de chutes de sortie. Si je vérifie le nombre de chutes de sortie à plusieurs reprises, je vois non seulement le compteur augmenter mais parfois il diminue. Les nombres ne correspondent pas aux paquets enregistrés sur l'interface. Les paramètres de QoS sont par défaut pour la plateforme.

Les échantillons suivants ont tous été prélevés dans un délai de 30 secondes:

bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 902220
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 1353330
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | je laisse tomber
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 451490

bc1019-3120-stack> sh int gi2 / 0/7 | i débit de sortie
  Débit de sortie de 5 minutes 301000 bits / sec, 119 paquets / sec

1) Y a-t-il autre chose qui peut provoquer des baisses de sortie en plus du serveur nic ne recevant pas les trames assez rapidement?

2) Quel est le nombre maximal de chutes de sortie que le compteur d'interface peut enregistrer? Retourne-t-il quand il atteint le maximum?

3) Qu'est-ce qui serait considéré comme un taux sain de baisse de production?

À moins que quelqu'un n'efface les compteurs, vous ne devriez jamais voir les compteurs de type odomètre (ceux qui incrémentent en fonction d'une action de paquet) diminuer, ils devraient toujours augmenter. Cette partie ressemble à un bug.

En ce qui concerne en particulier les baisses de sortie, il y a tellement de causes différentes qu'il est très difficile de les identifier exactement. Parfois, il y a un encombrement à l'intérieur du fond de panier du commutateur et ceux-ci peuvent apparaître lorsque la sortie diminue sur l'interface sortante. Dans de rares circonstances, vous pouvez également obtenir des microrafales qui n'apparaissent pas lorsqu'elles sont interrogées à des intervalles de 1 minute qui surchargent rapidement l'interface, mais redescendent très rapidement. Je suggérerais de saisir l'OID SNMP pour les pertes de sortie, puis de représenter graphiquement cela et de voir comment cela correspond au compteur CLI.

D'une manière générale, vous ne voulez pas de pertes de sortie car elles indiquent un paquet qui n'est pas arrivé à destination. Mais, si vous exécutez vos liens à chaud (ce que vous dites que vous n'êtes pas), ils sont inévitables dans une certaine mesure, principalement en raison de la mise en mémoire tampon des commutateurs intérieurs, etc.

Ma première pensée est l'inondation unicast, surtout si les compteurs augmentent à l'unisson sur un certain nombre de ports du même vlan. Je suis d'accord avec Aaron que la décroissance du compteur ressemble à un bug. Le compteur roulera probablement à 2 ^ 64, mais cela ne se produira pas en quelques secondes. Je considérerais qu'un taux sain de chutes de sortie est nul, mais ce n'est pas réaliste - même dans le centre de données. Faites-vous des liaisons montantes 10G?

Il semble que vous rencontriez le bogue CSCtq86186. Ce bogue a été détecté sur les 3750 et 2960, mais il peut également affecter les commutateurs de lame.

Si vous rencontrez une inondation unicast, l'exécution de wirehark sur l'un des hôtes ou sur l'un des ports devrait le montrer assez rapidement.

On dirait que vous avez des cœurs redondants dans une topologie carrée? Si oui, essayez d'ajouter cette commande à votre interface vlan:

arp timeout 300

Les tables CAM conservent les entrées pendant 5 minutes tandis que les tables ARP sont conservées pendant quatre heures (par défaut). La définition de l'ARP pour correspondre à la CAM peut éliminer l'inondation unicast au détriment d'une légère augmentation du CPU. Dépannage des problèmes de table ARP ou CAM des commutateurs Catalyst 6500/6000

Les baisses de sortie sont plutôt courantes sur les commutateurs plus petits avec de petits tampons car toute rafale épuisera le tampon. Je ne connais pas vraiment le 3120, je ne peux donc pas parler de la taille de son tampon, mais au moins c'est une raison courante jusqu'à ce que l'on puisse obtenir des baisses de sortie.

Les raisons spécifiques sont le blocage de tête de ligne (HOLB), où plusieurs ports source envoient vers une destination et nous obtenons donc une congestion. Une autre raison courante consiste à passer d'une vitesse de port supérieure à une vitesse inférieure, c'est-à-dire 10G à 1G ou 40G à 10G.

Je vous recommande d'exécuter show controllers ethernet-controller X où X est votre port. Vous devriez obtenir des informations sur les pertes de sortie, comme si quelque chose tente de sortir sur de grandes trames, ce qui pourrait se produire si vous n'avez pas de MTU cohérente sur votre réseau.