Analizando pérdida de pings contra un switch HP 1920

Fecha: 2 al 4 de abril del 2020 (durante la cuarentena)

 

Escenario

 

Realizando un test de confiabilidad de fibra, se reiniciaron contadores y envió una cierta cantidad

de paquetes a un equipo en el otro extremo para contabilizar errores de CRC.

 

Al ver el resultado de las pruebas, notamos un patrón ciclico de pérdidas de paquetes, lo que llevó

a realizar este análisis luego de determinar que siempre se pierde el paquete #362.

 

 

---resumido---

 

1.- Inicialmente se analizó la interface en busca de errores:

 

Catalyst6500#sh int gi1/3 | inc CRC

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored (no hay errores detectados)

Catalyst6500#

 

2.- Conteo de paquetes recibidos:

 

3.- Verificación:

 

 

4.- Pruebas con otro switch similar:

 

Repetimos las mismas pruebas con un equipo similar pero en una diferente zona de la red y con

diferente carga de tráfico y los resultados fueron los mismos.

 

 

5.- Pruebas con un switch HP 1920S:

 

Este es un modelo mas nuevo, digamos una “versión 2” del 1920, aunque mucho mas limitada, por ejemplo

no tiene línea de comando, el control de broadcast es rudimentario, etc, tiene mas potencia de hardware.

 

Podemos notar que al sobrepasar la cuenta de 361 no se pierden paquetes, se verificó hasta con 5000.

 

 

HPE OfficeConnect 1920 24G Switch (JG924A)

24 RJ-45 autosensing 10/100/1000 ports + 4 SFP 100/1000 Mbps slots

Memory and processor MIPS @ 500 MHz, 32 MB flash, 128 MB SDRAM, packet buffer size: 512 KB

 

HPE OfficeConnect 1920S 24G 2SFP Switch (JL381A)

24 RJ-45 autosensing 10/100/1000 ports + 2 SFP 100/1000 Mb/s slots

Memory and processor ARM Cortex-A9 @ 400 MHz, 64 MB flash, 256 MB SDRAM, packet buffer: 1.5 MB

 

Fuente: support.hpe.com

 

6.- Pruebas con paquetes de menor tamaño:

 

Para descartar que fuese un tema de capacidad de buffers, repetimo las prueba pero con un payload

mucho menor y ocupar menos espacio en algún buffer y poder alojar mas paquetes, pero los resultados

fueron exactamente los mismos, perdimos el paquete #362.

 

 

7.- Pruebas de envío simultáneo desde dos switches diferentes:

 

En esta prueba “atacamos” el switch desde dos equipos diferentes y logramos el mismo resultado,

entre la suma de paquetes de ambos equipos (280+81) perdemos el paquete #362.

 

 

 

8.- Envío de pings desde un equipo no Cisco:

 

Tratándose siempre de que los que envían pings son equipos Cisco, ahora probamos desde un equipo

Mikrotik en la misma subred, obteniendo nuevamente los mismos resultados: perdemos el #362.

 

 

9.- Simulación y captura del envío:

Esta prueba es de laboratorio, sin equipos en producción y como lo único que tengo en es un router

Mikrotik similar al de la prueba anterior, envío la secuencia de pings a una PC con Wireshark para analizar

ventanas de tiempos, volúmen de tráfico, etc.., y buscar alguna pista.

 

 

 

Podemos ver que la secuencia es normal, se envían los 362 paquetes en 0.21 segundos con una transferencia

de 511 Kbytes, lo que se podría asociar con el buffer de 512 Kbytes pero analizamos antes que con paquetes

de menor tamaño la falla también se repite.

 

El resultado de 361 pings, 510Kbytes en 0.21 segundos con algunas milésimas de diferencia a la prueba anterior.

10.- Accediendo por browser y realizando ping al mismo tiempo:

 

Al abrir una sesión de administración del switch por browser en simultáneo con los pings, sucede que estos por

momentos se ralentiza pero sin llegar al timeout (lo que daría un paquete perdido), supongo que dando tiempo

a que el buffer se vacíe (es una suposición) y permita el ingreso de mas paquetes, llegando a la cuenta de 391 en

lugar de los 361 de todas las otras pruebas.

Una vez que el browser cargó la página los pings siguieron con su cadencia de 361 (aqui omitido para simplificar).

 

 

 

11.- Corolario:

 

361 es múltiplo de 19 (de hecho es 19^2), no tiene relación alguna con los números potencia de 2 a los que nos

son familiares cuando trabajamos con redes.

 

Se transfirieron mediante ping alredeor de 512 Kbytes, lo que nos acerca a un posible tamaño de buffer, que

descartamos porque la pérdida del ping #362 también ocurre con payloads mas pequeños.

 

No hay practicamente diferencia entre el envío de 361 y 362 pings.

 

Si se envían pings desde dos equipos simultaneamente, cuando la suma de ambos pings da 362 el paquete se

pierde, lo que nos indica que no es por cantidad de paquetes por IP de origen sino por el total.

 

Si durante los pings, al mismo tiempo se accede vía web también se pierden paquetes, pero no con un patrón

definido, esto último deberé probarlo on-site con una captura de Wireshark cuando se levante la cuarentena.

 

(2020) Combining prime numbers is inbreeding ?

Rosario, Argentina