¿Qué causa la caída total de la salida en una interfaz de switch de Cisco?

Tengo un chasis HP c7000 blade que contiene los switches Cisco 3120X y Cisco 3120G con ios 12.2 (58) SE1. Los blades en sí mismos están muy cargados, pero muchas interfaces en diferentes conmutadores blade en el chasis muestran un número bastante alto de caídas de salida. Si compruebo el número de salidas caídas repetidamente, no solo veo que el contador aumenta, sino que a veces disminuye. Los números no se correlacionan con los paquetes / s registrados en la interfaz. La configuración de QoS es predeterminada para la plataforma.

Las siguientes muestras fueron tomadas en un período de 30 segundos:

bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); Caídas totales de salida: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); Caídas totales de salida: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 902220
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 1353330
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | salgo caídas
  Cola de entrada: 0/75/0/0 (tamaño / máx. / Gotas / descargas); La producción total cae: 451490

bc1019-3120-stack> sh int gi2 / 0/7 | i tasa de salida
  Velocidad de salida de 5 minutos 301000 bits / seg, 119 paquetes / seg.

1) ¿Hay algo más que pueda causar caídas de salida además de que el servidor no reciba las tramas lo suficientemente rápido?

2) ¿Cuál es el número máximo de caídas de salida que puede registrar el contador de interfaz? ¿Se vuelca cuando alcanza el máximo?

3) ¿Qué se consideraría una tasa saludable de caídas de producción?

A menos que alguien esté limpiando contadores, nunca debería ver una disminución de los contadores tipo odómetro (aquellos que se incrementan en función de una acción de paquete), siempre deben aumentar. Esa parte suena como un error.

En cuanto a lo que causa la caída de la producción en particular, hay tantas causas diferentes que es muy difícil precisarlo exactamente. A veces hay congestión dentro del plano posterior del conmutador y estos pueden aparecer a medida que la salida cae en la interfaz saliente. En raras circunstancias, también puede obtener microbursts que no se muestran cuando se sondea a intervalos de 1 minuto que sobrecargan rápidamente la interfaz, pero luego vuelven a caer muy rápidamente. Sugeriría tomar el OID de SNMP para las caídas de salida y luego graficar eso y ver cómo corresponde al contador CLI.

En términos generales, no desea que se caiga ninguna salida, ya que indican un paquete que no llegó a su destino. Pero, si está ejecutando sus enlaces en caliente (lo que dice que no), son inevitables hasta cierto punto, principalmente debido al almacenamiento en búfer del interruptor interior, etc.

Mi primer pensamiento es la inundación de unidifusión, especialmente si los contadores se incrementan al unísono a través de varios puertos en el mismo vlan. Estoy de acuerdo con Aaron en que la disminución del contador suena como un error. El contador probablemente pasará a 2 ^ 64, pero eso no sucederá en segundos. Consideraría que una tasa saludable de caídas de salida es cero, pero esto no es realista, incluso en el centro de datos. ¿Estás haciendo enlaces ascendentes 10G?

Parece que estás golpeando el error CSCtq86186. Este error se ha encontrado en 3750s, 2960s, pero también puede estar afectando a los interruptores de la cuchilla.

Si está experimentando una inundación de unidifusión, ejecutar cables de conexión en uno de los hosts o atravesar uno de los puertos debería mostrarlo con bastante rapidez.

¿Parece que tiene núcleos redundantes en una topología cuadrada? Si es así, intente agregar este comando a su interfaz vlan:

arp timeout 300

Las tablas CAM contienen entradas durante 5 minutos, mientras que las tablas ARP se mantienen durante cuatro horas (valores predeterminados). Configurar el ARP para que coincida con el CAM puede eliminar la inundación de unidifusión a expensas de un ligero aumento en la CPU. Catalyst 6500/6000 Switches Problemas de la tabla ARP o CAM Resolución de problemas

Las caídas de salida son bastante comunes en conmutadores más pequeños con memorias intermedias pequeñas, ya que cualquier ráfaga agotará la memoria intermedia. No estoy realmente familiarizado con el 3120, por lo que no puedo hablar por el tamaño de su búfer, pero al menos esa es una razón común hasta por qué uno podría obtener caídas de salida.

Los motivos específicos son el bloqueo de cabeza de línea (HOLB), donde se envían múltiples puertos de origen a un destino, por lo que tenemos congestión. Otra razón común es cuando se pasa de una velocidad de puerto más alta a una más baja, es decir, 10G a 1G o 40G a 10G.

Le recomiendo que ejecute show controllers ethernet-controller X donde X es su puerto. Debería obtener información sobre las caídas de salida, como si algo está tratando de salir a tramas grandes, lo que podría suceder si no tiene una MTU constante en su red.