Estoy depurando un caso de paquetes UDP perdidos en un conmutador gigabit de almacenamiento y reenvío y quería visualizar lo que sucede dentro del conmutador para comprender mejor la esencia del problema.
El escenario es simple: dos flujos de datos en ráfagas llegan a través de 2 puertos dentro del conmutador y ambos quieren salir a través de un tercer puerto (común a ambos). Por lo tanto, el conmutador necesita retener algunos datos en el búfer de paquetes durante un tiempo.
El problema es: según mis cálculos simples, los buffers deberían ser lo suficientemente grandes para manejar el caso que estoy examinando. Un flujo de datos envía ráfagas de 25 kB (divididos en paquetes de 1514 B) cada 1,56 ms, el otro envía ráfagas de 60 kB cada 1 ms. Ahora, incluso un conmutador Soho como Netgear GS105E tiene un búfer de 128 kB. Entonces, las matemáticas simples (25+60 < 128) indican que debería funcionar incluso si las transmisiones ingresan al mismo tiempo (dado que no hay otro tráfico sustancial).
Las pruebas reales muestran que muchos paquetes de ambos flujos se pierden en algunos conmutadores (parece estar vinculado al tamaño del búfer, pero no solo a él). En mi simulación, no puedo hacer que el búfer se sobrellene cuando lo configuré en 128 kB.
Grabé esta animación para un búfer de 24 kB donde está el sobrellenado. Sin embargo, puede ver fácilmente que aumentar el búfer solo unos pocos bytes resolvería el problema y todos los paquetes pasarían.
Hice algunas simplificaciones en esta simulación. Todos los paquetes tienen la misma QoS (esto también ocurre en el caso real). Así que omití las colas de QoS de la simulación y trato todo el tráfico como igualmente importante. A continuación, omití la gestión de la memoria del búfer. Me imagino que es una parte importante del problema, pero me sorprendería que mi simplificación con asignaciones perfectas estuviera equivocada en más de un 10% con respecto al caso real. También pretendo que el conmutador conozca la longitud de la trama cuando recibe sus primeros bytes para reservar toda la memoria necesaria al principio. Como no pude encontrar ninguna documentación sobre el tamaño de las colas de entrada/salida de los puertos, supongo que todos están ubicados en el búfer de paquetes compartido y pueden tomar la mayor parte del búfer según sea necesario (aunque creo que el culpable puede ser en algun lugar aqui). Establecí el retraso de procesamiento de cada paquete en 512 ns (el retraso de propagación de un paquete de 64 B).
No estoy seguro de si influye, pero las transmisiones consisten en paquetes UDP fragmentados (es decir, la ráfaga de 25 kB es un único paquete UDP fragmentado en 17 fragmentos de IP). El segundo flujo crea la ráfaga como 2 o 3 paquetes UDP de 20 kB, cada uno fragmentado en 14 fragmentos de IP.
Los comandos de Iperf 3.7 para replicar flujos similares a los reales son:
iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000
¿Tienes alguna idea de qué más se me olvidó tener en cuenta que podría hacer que la simulación esté tan alejada de la realidad? ¡Gracias por ayudar!
El código fuente de la animación está enhttps://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21.
Aquí está mi tabla de resultados de los experimentos reales. El flujo de datos uno es fijo: 128 Mbps en paquetes UDP de 25 kB cada 1,56 ms. Estaba cambiando los parámetros de la segunda secuencia tratando de encontrar el límite donde el conmutador comenzará a perder los paquetes de la primera secuencia. Estaba cambiando el -lparámetro (longitud) que especifica el tamaño del paquete UDP y el -bparámetro (ancho de banda) que especifica qué ancho de banda deberían generar estos paquetes. --pacing-timersiempre estuvo establecido en 1000 para la segunda transmisión. Puede ver que D-Link y Netgear GS105 no pueden soportar las ráfagas de 60 kB en absoluto. GS108 funciona mucho mejor que GS105, aunque tiene casi el mismo chip de conmutación (la misma "familia", solo diferente número de puertos y un búfer un poco más grande).
| Cambiar | Tamaño del búfer [kB] | Tráfico máximo: ráfaga de 1,5 kB | Tráfico máximo: ráfaga de 20 kB | Tráfico máximo: ráfaga de 60 kB |
|---|---|---|---|---|
| Gigablox resistente (VSC7512) | 220 | 825Mbps | 825Mbps | 825Mbps |
| Gigablox (RTL8367N-VB-CG) | 250 | 730Mbps | 750Mbps | 790Mbps |
| D-Link DIS-100G-5W (QCA8337N-AL3C) | 128 | 110Mbps | 1Mbps | cada ráfaga pierde paquetes |
| Zyxel XGS 1210-12 (RTL9302B) | 1500 | 800Mbps | 830Mbps | 830Mbps |
| Netgear GS310-TP (RTL8380M) | 520 | 830Mbps | 830Mbps | 835Mbps |
| Netgear GS308T (RTL8380M) | 520 | 830Mbps | 835Mbps | 835Mbps |
| Netgear GS108 v3 (BCM53118) | 192 | 630Mbps | 660Mbps | 710Mbps |
| Netgear GS105E (BCM53114) | 128 | 120Mbps | 1Mbps | cada ráfaga pierde paquetes |
| Renkforce RF-4270245 | ? | 740Mbps | 760Mbps | 800Mbps |
| Microtik RB260GS (AR8327) | 128 | 835Mbps | 835Mbps | 835Mbps |
| Enebro EX2300 | ¿4 GB? | 800Mbps | 830Mbps | 830Mbps |
(Esta pregunta ha sido migrada dehttps://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switchdonde fue marcado como fuera de tema).