¿Por qué tenemos una alta fluctuación en la medición de ancho de banda Cacti graph?

Estábamos en una prueba de redundancia de Etherchannel y Routing en nuestra red. Durante esta intervención hicimos algunas mediciones. Nuestra herramienta de monitoreo es Cacti for graph. El equipo monitoreado es un 4500-X en VSS. Cada enlace está en un chasis físico diferente.

Esquema:

Cronología de prueba:
[t0] El enlace en el puerto te1 / 1/14 se eliminó físicamente. Te2 / 1/14 está activo. Po1 está operativo.
[t0 + 15] El enlace en el puerto Te1 / 1/14 volvió al servicio y verificó que el puerto de vuelta en el canal de ethernet Po1
[t0 + 20] El enlace en el puerto te1 / 1/14 se eliminó físicamente. Te2 / 1/14 está activo. Po1 está operativo.
[t0 + 35] El enlace en el puerto Te1 / 1/14 volvió al servicio y verificó que el puerto volviera a estar en el canal de ethernet Po1

En nuestras pruebas, monitoreamos el tráfico del canal de ethernet Po1 a través de Cacti (gráfico a continuación) y notamos un cambio significativo en el valor del flujo cuando deshabilitamos el enlace te1 / 1/14 (enlace te2 / 1/14 activos) bastante estable durante el reverso . También verificamos los contadores en int Po1 y estos se mantuvieron bastante estables.

Dos interfaces de 10G están agrupadas en Etherchannels con LACP configurado. Dentro del etherchannel hay 2 vlans. Uno para tráfico de multidifusión y otro para Internet / todo el tráfico.

¿Conoces una posible causa de este comportamiento?

Para extender el comentario de ytti.

Su intervalo de encuesta parece muy pequeño, cada 10 segundos si estoy leyendo bien. Hay algunas razones por las que podrías obtener ese resultado.

Lado del equipo:

• Mala elección de contadores, si está utilizando contadores de 32 bits, podrían pasar cada ~ 3.4 segundos si está ejecutando una interfaz de 10 g a velocidad de línea
• Actualización de contadores, muchos dispositivos más grandes solo actualizan contadores dos o tres veces por minuto, y nunca se puede confiar en que estén sincronizados. Cada 30 segundos es tan bajo como me molestaría en las encuestas, e incluso entonces siempre querría al menos dos puntos antes de activar cualquier alerta o tomar medidas
• Puede haber un problema, ya que los paquetes enviados para el procesamiento de la CPU (quizás el flujo de red) pueden contarse de inmediato frente a los que no van a RE en lotes (lo han visto en Juniper MX)

Lado del encuestador:

• ¿El encuestador realiza el sondeo con precisión en el intervalo y, si no, está inyectando su resultado con el tiempo de sondeo real (p. Ej., X bits en yz segundos) para que se pueda calcular una tasa razonable
• Qué sucede cuando los contadores se reinician, o no se responde a SNMP GET, diferentes herramientas responden a estos de diferentes maneras

Su problema es como tal, que el muestreo de su enrutador y su propio sondeo no están llegando al mismo momento. Es decir, a pesar de que el intervalo de sondeo es estático, los intervalos de sondeo contienen diferentes cantidades de muestras, lo que su matemática no tiene en cuenta.
Considere que ha sondeado t1, t2, t3 pero el enrutador no ha muestreado nada en t1, t2 intervalo, por lo que todo el tráfico entre t1, t3 terminó en t2, t3 valor sondeado. Causando que su tasa sea 0 en t1, t2 y sobre velocidad de línea en t2, t3

Ahora voy a sugerir una solución, pero verifíquelo con alguien que tenga una comprensión superficial de las matemáticas.

Primero descubra la interfaz que le interesa (si es ge-1/1/1):

snmpbulkwalk SWITCH ifDescr | grep ge-1/1/1

Luego verá su número ifIndex, supongamos que es '42'.

Luego haz algo como:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Ahora analice los resultados para determinar con qué frecuencia, en promedio, los contadores se actualizan realmente. (Puedo producir script para el análisis si es necesario)

Luego viene la parte donde necesitaríamos matemáticas, pero sugeriré una solución ingenua.

Si su intervalo de actualización es de 10 segundos, marque la casilla cada 5 segundos, es decir, el doble de veces que se actualiza. Entonces tus muestras serían

t0, t5, t10, t15, t20, t25, t30

Ahora, estos serían sus datos sin procesar, que no usaría, pero preferiría recuperar muestras reales de esta manera

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

La razón aquí es que queremos filtrar los límites para reducir el efecto de intervalos de sondeo imprecisos en su interruptor.

Luego trazaría el s1, s2, s3 y debería tener un resultado mucho más suave / preciso que el que está viendo ahora.

Sin embargo, estoy seguro de que este no es un problema nuevo y estoy seguro de que hay una solución formal para recuperar la precisión óptima, desafortunadamente, producir esa solución está fuera de mi conjunto de habilidades. Algo que las personas de intercambio matemático de pila estarían mejor equipadas para hacer frente.

Como está sondeando a la misma velocidad que se actualizan los contadores, es probable que no esté sincronizado.

Configurando

snmp-server hc poll <<hundredths of a second>>

puede reducir el intervalo en el que los contadores SNMP se actualizan a algo así como 1 segundo. Esto debería dar como resultado un valor más preciso para el rendimiento cuando está sondeando cada 10 segundos.

FYI, este es un comando oculto.