9.4. Pruebas de Carga de Tráfico (Stress Testing)

UF1794 | Evaluando el rendimiento bajo condiciones extremas

graph TD subgraph Normal_Traffic ["Tráfico Normal (Validación Básica)"] PLC1["PLC Control"] <-->|"Ping / IO Data (5%)"| SW1["Switch"] end subgraph Stress_Test ["Prueba de Estrés (95% de Carga)"] Gen["Generador de Tráfico
(Iperf / Ostinato)"] =="Inyección Masiva (UDP/TCP)"==> SW2["Switch"] SW2 == "Tráfico de fondo" ==> PLC2["PLC Control"] end Normal_Traffic -. "Validado OK" .-> Stress_Test style Gen fill:#e74c3c,color:white style SW2 fill:#f39c12,color:white style PLC1 fill:#2ecc71,color:white style PLC2 fill:#2ecc71,color:white

1. ¿Por qué hacer pruebas de carga (Stress Testing)?

Hacer un "ping" a un PLC y que responda es un buen comienzo, pero una planta de producción real no vive de pings aislados. En plena producción, el SCADA estará extrayendo miles de variables, un ingeniero estará descargando un programa pesado en el TIA Portal, las cámaras de visión artificial enviarán imágenes por FTP, y los variadores exigirán respuestas de milisegundos. Todo al mismo tiempo.

Las pruebas de carga o Stress Testing sirven para simular el "peor escenario posible" (Worst Case Scenario) inyectando tráfico masivo en la red para ver si el hardware o la configuración de QoS fallan bajo presión. Para un técnico de UF1794, esta es la validación definitiva de que el diseño de red es sólido.



2. Herramientas de Inyección de Tráfico

Para saturar un enlace Gigabit no basta con abrir el navegador web. Los ingenieros utilizan herramientas de software o hardware específicas:

  • Iperf / Iperf3: Es la herramienta estándar de código abierto para medir el ancho de banda máximo alcanzable en redes IP. Funciona en modelo cliente/servidor y permite inyectar ráfagas masivas de tráfico TCP o UDP a la velocidad exacta que le ordenes (ej. 900 Mbps sostenidos).
  • Ostinato / Scapy: Permiten crear paquetes a medida (ej. tramas con direcciones MAC o IPs específicas) y enviarlas en bucle para estresar el procesamiento de las tablas ARP de los switches.
  • Testadores Físicos (Hardware): Equipos como IxNetwork que pueden generar tráfico de línea (Line-Rate) sin que la CPU del ordenador limite la prueba.


3. Qué Monitorizar durante la Prueba de Estrés

El objetivo no es romper la red, sino observar cómo se comporta al borde del límite. Durante la inyección de tráfico, el técnico debe monitorizar tres parámetros críticos:

  • Eficacia del QoS (Calidad de Servicio): Si saturas la red al 99% con tráfico de "descarga FTP" (baja prioridad), la comunicación PROFINET RT (alta prioridad) entre el PLC y sus esclavos debe mantenerse impecable. Si el PLC reporta un fallo de Watchdog, significa que las colas de prioridad del switch están mal configuradas.
  • Carga de CPU en los Nodos: Los PLCs antiguos y la periferia de bajo coste a veces procesan la red con su CPU principal. Un torrente de tráfico (incluso si no va dirigido a ellos, como el Broadcast) puede saturar la CPU al 100%, parando la ejecución del código lógico de la máquina.
  • Jitter (Variación del Retardo): En redes EtherNet/IP (CIP Sync), el tráfico pesado puede introducir retardos variables que destruyen la sincronización de los servomotores.


4. La Regla de Oro: Nunca en Producción

El Stress Testing es un arma de doble filo. Inyectar 1 Gigabit de tráfico en un entorno IT corporativo moderno causará un poco de lentitud. Inyectarlo en una red de control industrial "viva" puede causar una Parada de Emergencia, daños en la maquinaria e incluso poner en peligro vidas humanas al bloquear paquetes de Safety.

Las pruebas de estrés deben realizarse exclusivamente durante la fase FAT (en el taller del integrador), durante el SAT en la planta pero con los actuadores en "Modo Simulación" (sin movimiento físico), o en ventanas de mantenimiento programadas (Downtimes) extremadamente controladas.

Infografía mostrando un ordenador inyectando un torrente de datos masivo hacia un switch y un PLC protegido por QoS.
Figura 1: El concepto de Stress Testing. Al saturar los enlaces troncales de la fábrica al 90% o más de su capacidad con herramientas de generación de tráfico, los ingenieros pueden validar empíricamente si las configuraciones de Calidad de Servicio (QoS) y las VLANs logran proteger el ciclo de E/S crítico frente al "ruido" masivo de fondo.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Pruebas bajo Presión

1. ¿Cuál es el objetivo principal de realizar un Stress Test (Prueba de carga) en una red de automatización industrial?

2. Durante una prueba de estrés inyectando 800 Mbps de tráfico TCP, la comunicación del PLC con sus esclavos IO (PROFINET RT) empieza a perderse provocando fallos en las máquinas. Sabiendo que los enlaces físicos son de 1 Gigabit, ¿qué configuración lógica de la red ha fallado muy probablemente?

3. ¿Cuál es el riesgo y la regla de oro respecto al momento de ejecución de un "Stress Test" en el entorno OT (Operational Technology)?

🤖 Ejercicio Práctico 9: Simulador de Inyección UDP

Objetivo: Entender a nivel de código cómo herramientas de prueba son capaces de saturar una red enviando un torrente masivo de datos sin esperar respuesta (UDP).

Copia el siguiente *prompt* y pégalo en un modelo de IA (como ChatGPT, Gemini o Claude).

Actúa como un desarrollador de herramientas de auditoría de redes. Escribe un script en Python utilizando la librería estándar `socket` para simular un "Generador de Tráfico UDP" básico para un Stress Test educativo en localhost. El script debe: 1. Pedir al usuario una IP de destino y un Puerto. 2. Crear un socket UDP (`SOCK_DGRAM`). 3. Generar un payload (carga útil) de 1024 bytes de datos aleatorios. 4. Entrar en un bucle infinito que envíe continuamente este payload a la IP y Puerto especificados, contando cuántos paquetes se han enviado. 5. Usar un bloque `try. except KeyboardInterrupt` para capturar cuando el usuario pulse Ctrl+C, deteniendo la prueba y mostrando en pantalla el "Total de Paquetes Enviados" y el "Total de Megabytes inyectados". Comenta el código explicando que, en el mundo real, herramientas optimizadas en C++ como `iperf3` hacen exactamente esto, pero a velocidades suficientes para ahogar una red Gigabit.