Por qué capturar tráfico para diagnosticar una red OT
El diagnóstico de redes OT permite investigar fallos de comunicación que pueden afectar a la continuidad de la producción. En las redes de Tecnología Operacional (OT), la prioridad siempre ha sido mantener el proceso en funcionamiento. Una breve interrupción en una red IT puede representar una molestia; en una planta industrial puede significar pérdida de producción, parada de una máquina, equipos afectados o varias horas de trabajo hasta recuperar el proceso.
A medida que las redes OT se vuelven más complejas y aumenta su convergencia con las infraestructuras IT, disponer de visibilidad fiable sobre lo que realmente está ocurriendo en la red se ha convertido en una necesidad para mantenimiento, automatización y ciberseguridad.
Capturar tráfico permite investigar errores intermitentes, comprobar si los dispositivos se están comportando según lo previsto, supervisar la salud de la red a largo plazo y detectar degradaciones antes de que terminen provocando una parada.
Pero no todos los protocolos industriales se comportan igual.
Protocolos como PROFINET IRT y determinadas aplicaciones basadas en TSN (Time-Sensitive Networking) trabajan con requisitos temporales deterministas muy estrictos. Otros, como Modbus TCP o PROFINET RT, admiten mayores variaciones temporales.
Esta diferencia condiciona dónde podemos capturar el tráfico, qué hardware podemos introducir en el enlace y cómo debemos interpretar posteriormente los paquetes obtenidos.
En esta guía de diagnóstico de redes OT analizamos un flujo de trabajo práctico utilizando Network TAPs de cobre, Profitap IOTA, ProfiShark y Wireshark, y estudiamos tres escenarios especialmente representativos: Modbus TCP, PROFINET RT/IRT y TSN.
TAP o puerto SPAN: cómo acceder al tráfico OT
Antes de analizar paquetes tenemos que obtenerlos.
Una posibilidad habitual es utilizar un puerto SPAN o Port Mirror del switch. El switch replica el tráfico seleccionado y lo envía hacia un puerto donde conectamos nuestra herramienta de análisis.
Es una solución válida en muchas aplicaciones, especialmente para diagnósticos puntuales, pero la captura depende de las capacidades y configuración del propio switch.
Cuando queremos disponer de un punto dedicado de acceso al tráfico podemos utilizar un Network TAP.
El TAP se coloca en el enlace entre dos dispositivos y proporciona una copia del tráfico hacia la herramienta de monitorización sin necesidad de configurar una sesión Mirror en el switch.
Esto resulta especialmente interesante cuando necesitamos analizar tráfico full-duplex, realizar capturas prolongadas o investigar problemas en los que el comportamiento temporal de la comunicación es relevante.
Sin embargo, existe un detalle fundamental: un TAP también introduce una pequeña latencia física en el enlace.
En protocolos soft real-time esta diferencia normalmente tiene poca importancia. En aplicaciones hard real-time, donde los tiempos están estrictamente controlados, puede llegar a ser relevante.
Por ello, seleccionar un TAP no consiste únicamente en comprobar si la red trabaja a 100 Mbit/s o 1 Gbit/s. También debemos conocer el protocolo y el presupuesto temporal de la aplicación.
¿Estamos midiendo tiempo o tráfico?
Antes de realizar una captura conviene hacerse una pregunta sencilla:
¿Estamos investigando un problema de temporización o un problema relacionado con el tráfico?
No es lo mismo analizar latencia y jitter que investigar saturación, retransmisiones, respuestas incorrectas o un dispositivo que deja de comunicarse.
En el diagnóstico de redes OT, esta diferencia determinará tanto la infraestructura de captura como las variables que tendremos que observar posteriormente.
IOTA: captura, timestamping y análisis
Profitap IOTA puede conectarse al puerto de monitorización de un TAP para registrar el tráfico de ambos sentidos y aplicar timestamping hardware de 8 ns a cada trama.
Esta precisión es especialmente importante cuando queremos analizar retardos, jitter o el comportamiento temporal de protocolos industriales deterministas.
Un timestamp generado por software en un sistema operativo convencional introduce su propia variabilidad temporal. Cuando precisamente estamos intentando medir pequeñas diferencias de tiempo, esa incertidumbre puede condicionar el análisis.
IOTA añade además almacenamiento local, análisis integrado de protocolos y acceso remoto, lo que permite realizar capturas prolongadas sin mantener permanentemente un ordenador conectado junto a la máquina.
También puede utilizarse en determinadas configuraciones como dispositivo inline, aunque en este caso debe considerarse tanto la latencia introducida como el comportamiento ante una pérdida de alimentación.
La configuración de la red también importa
Las redes industriales atraviesan procesos de inicialización y configuración cuya exigencia depende considerablemente del protocolo.
Durante esta fase pueden comprobarse dispositivos, parámetros, tiempos de ciclo, topología y características físicas de la red.
Modbus TCP es relativamente tolerante: su funcionamiento se basa fundamentalmente en comunicaciones TCP y en tiempos de respuesta configurables.
PROFINET RT e IRT realizan comprobaciones más estrictas, especialmente en el caso de IRT, donde la topología y los retardos forman parte del comportamiento determinista esperado.
TSN, por su parte, utiliza mecanismos de sincronización y planificación temporal que permiten garantizar determinados comportamientos del tráfico.
Por eso, introducir un dispositivo de monitorización después de la puesta en marcha no tiene necesariamente el mismo efecto en todas las redes.
Modbus TCP: el escenario más sencillo para capturar y analizar
Modbus TCP es uno de los protocolos más extendidos en automatización industrial.
Funciona sobre TCP/IP —habitualmente utilizando el puerto TCP 502— y sigue una arquitectura de petición/respuesta. Un cliente, que puede ser un SCADA, HMI, PLC u otro sistema, realiza solicitudes a los dispositivos y estos responden con los datos correspondientes.
Sus ciclos pueden ir desde milisegundos hasta segundos y admite cierta variación en los tiempos de respuesta. Por ello podemos considerarlo, en este contexto, un protocolo soft real-time.
Desde el punto de vista de captura, resulta considerablemente menos exigente que PROFINET IRT.
Un TAP correctamente seleccionado puede colocarse en el enlace que queremos observar y proporcionar visibilidad sobre las peticiones y respuestas sin que exista el mismo condicionante de topología temporal que encontramos en protocolos deterministas.
¿Qué podemos buscar en una captura Modbus TCP?
El análisis puede permitirnos comprobar:
- Qué solicitudes está realizando realmente el cliente;
- A qué dispositivos se están enviando;
- Qué códigos de función se utilizan;
- Si los dispositivos responden;
- Cuánto tardan en responder;
- Si aparecen respuestas de excepción;
- Si existen retransmisiones o problemas TCP;
- Siguen las transacciones la secuencia esperada.
IOTA puede realizar directamente parte de este análisis, incluyendo la interpretación de códigos de función y respuesta, correlación de peticiones y respuestas mediante el Transaction ID y medición del tiempo transcurrido entre ambas.
En el diagnóstico de redes OT con Modbus TCP, esto permite responder rápidamente a preguntas habituales en mantenimiento:
¿El PLC está haciendo realmente la petición?
¿El dispositivo está respondiendo?
¿Está respondiendo con una excepción?
¿Ha aumentado progresivamente el tiempo de respuesta?
Profundizando con Wireshark
Cuando necesitamos analizar el contenido completo podemos exportar la captura a Wireshark.
Aplicando filtros Modbus podemos examinar registros, coils, bits, palabras, códigos de función y la secuencia completa de transacciones.
También podemos filtrar las respuestas de excepción o comparar tiempos de respuesta para localizar problemas intermitentes que quizá no aparezcan en los diagnósticos del PLC o SCADA.
PROFINET RT e IRT: cuando el tiempo empieza a ser crítico
PROFINET presenta un escenario diferente porque debemos distinguir entre PROFINET RT (Real-Time) y PROFINET IRT (Isochronous Real-Time).
PROFINET RT
PROFINET RT utiliza Ethernet para el intercambio cíclico de datos con tiempos de ciclo reducidos.
Aunque la temporización es importante, existe suficiente tolerancia para que un TAP correctamente seleccionado pueda utilizarse normalmente para observar:
- Tráfico cíclico
- Descubrimiento y configuración DCP
- Alarmas
- Diagnósticos
- Estados de dispositivos
- Problemas de comunicación
Esto permite correlacionar lo que observamos en la máquina con lo que realmente está ocurriendo en la red.
PROFINET IRT
PROFINET IRT es considerablemente más exigente.
Está diseñado para aplicaciones deterministas con ciclos por debajo del milisegundo y utiliza sincronización precisa para garantizar que determinadas comunicaciones ocurran dentro de ventanas temporales concretas.
Durante la puesta en marcha, la topología y los retardos de la red forman parte de los parámetros que permiten garantizar ese comportamiento.
Esto tiene una consecuencia directa para el diagnóstico:
introducir posteriormente un TAP añade una pequeña latencia al enlace y puede modificar las características que la red espera encontrar.
Por ello, en una red PROFINET IRT no deberíamos insertar cualquier TAP sin analizar previamente sus características y la configuración del proyecto.
100 Mbit/s frente a Gigabit en PROFINET IRT
Profitap destaca una diferencia importante entre sus TAP de 100 Mbit/s y Gigabit.
Su Industrial Fast Ethernet Copper TAP de 100 Mbit/s es completamente pasivo y añade una latencia muy reducida, aproximadamente equivalente, según el fabricante, a introducir entre 5 y 10 cm adicionales de cable.
En cambio, su Industrial Gigabit Copper TAP introduce aproximadamente 480 ns en enlaces de 1 Gbit/s y más de 780 ns trabajando a 100 Mbit/s.
En una red convencional estas cifras pueden resultar insignificantes. En PROFINET IRT pueden ser relevantes.
Por este motivo, si necesitamos monitorizar una instalación IRT de 100 Mbit/s, la selección del TAP y el margen temporal configurado en el proyecto deben estudiarse conjuntamente.
La mejor estrategia es prever los puntos de monitorización desde la fase de diseño de la máquina o instalación.
¿Qué podemos analizar en Wireshark?
Una captura PROFINET permite estudiar tráfico mediante filtros como:
pn_rtpn_dcppn_rpc
Los estados IOPS e IOCS presentes en las comunicaciones cíclicas proporcionan información sobre la calidad o validez de los datos de entrada y salida.
Las tramas de alarma y diagnóstico pueden aportar información sobre fallos a nivel de dispositivo.
Y cuando investigamos problemas temporales, añadir columnas de delta time en Wireshark ayuda a visualizar variaciones entre ciclos y detectar jitter.
En IRT, donde los ciclos pueden situarse aproximadamente entre 250 µs y 1 ms, disponer de timestamps precisos resulta especialmente relevante.
TSN: Ethernet determinista para la convergencia IT/OT
TSN (Time-Sensitive Networking) no es un único protocolo, sino un conjunto de estándares IEEE 802.1 diseñados para proporcionar comunicaciones Ethernet con características temporales deterministas.
Entre los mecanismos más importantes encontramos:
IEEE 802.1AS, utilizado para sincronización temporal mediante gPTP;
IEEE 802.1Qbv, que introduce planificación temporal del tráfico mediante Time-Aware Shaper y listas de control de puertas;
IEEE 802.1Qbu / IEEE 802.3br, relacionados con la preempción de tramas;
y IEEE 802.1CB, destinado a redundancia mediante replicación de tramas.
El interés de TSN para la automatización industrial está precisamente en permitir que tráfico industrial determinista y tráfico Ethernet convencional puedan coexistir sobre una infraestructura común, manteniendo garantías para los flujos sensibles al tiempo.
¿Qué cambia al introducir un TAP?
Al igual que PROFINET IRT, una red TSN tiene en cuenta características temporales del camino de comunicación.
Sin embargo, su comportamiento es diferente.
En lugar de depender únicamente de una topología fija configurada durante el diseño de la red, TSN puede trabajar con mecanismos que consideran las latencias del camino y verifican que las garantías temporales necesarias siguen pudiéndose cumplir.
Si introducimos un TAP, añadimos una pequeña latencia.
Mientras el nuevo retardo siga estando dentro del presupuesto temporal de la aplicación, la red puede continuar funcionando correctamente.
Esto hace que TSN pueda resultar más tolerante a la introducción posterior de elementos de monitorización que una arquitectura IRT estrictamente configurada, aunque siempre debemos comprobar el diseño concreto.
¿Qué podemos analizar en una red TSN?
Una de las características interesantes de TSN es la diversidad del tráfico.
En la misma infraestructura podemos encontrar:
- Tráfico industrial programado
- Sincronización temporal
- Tráfico IP convencional
- IPv6
- DHCP
- DNS
- VLAN
- Otras comunicaciones de aplicación
Una captura realizada desde un TAP puede proporcionar visibilidad simultánea sobre estos diferentes flujos.
Analizando gPTP con Wireshark
Wireshark permite estudiar la sincronización gPTP mediante filtros PTP y observar mensajes como:
Sync → Follow_Up → Delay_Req → Delay_Resp
Esta secuencia permite investigar problemas relacionados con la sincronización de los relojes.
Los timestamps hardware pueden utilizarse también para comparar cuándo llegan determinadas tramas respecto a las ventanas de transmisión configuradas.
La información IEEE 802.1Q, incluyendo prioridades y asignaciones VLAN, puede observarse en las cabeceras Ethernet.
De este modo, una captura TSN no sirve únicamente para saber qué dispositivos están comunicando, sino también para estudiar cuándo están comunicando y con qué prioridad.
Una buena práctica: prever la monitorización desde el diseño
Una de las conclusiones más interesantes del análisis de estos tres protocolos es que el mejor momento para pensar en la monitorización de una red OT no es cuando aparece el problema.
Es durante el diseño.
Si durante la planificación de la instalación definimos previamente:
- Dónde podrían ser necesarios puntos de captura
- Qué protocolos existen en cada segmento
- Qué márgenes temporales debemos mantener
- Qué enlaces podrían necesitar monitorización permanente
- Cómo accederemos al tráfico posteriormente
el diagnóstico futuro será considerablemente más sencillo.
Esto es especialmente importante en PROFINET IRT, donde introducir posteriormente un elemento en el enlace puede requerir revisar los márgenes configurados en el proyecto.
Diagnóstico de redes OT: flujo práctico de captura y análisis
Podemos resumir el proceso de diagnóstico en seis pasos:
ProfiShark para diagnóstico portátil
No todas las intervenciones de diagnóstico de redes OT necesitan una plataforma de captura permanente.
Cuando un técnico necesita desplazarse hasta una máquina y realizar una captura directamente sobre el enlace, la familia Profitap ProfiShark proporciona una solución portátil para llevar el tráfico hasta un ordenador de análisis.
Existen diferentes modelos según velocidad y prestaciones, desde redes Fast Ethernet hasta enlaces de mayor velocidad.
La clave no es solamente la herramienta: es conocer el protocolo
Modbus TCP, PROFINET y TSN muestran claramente por qué el diagnóstico de redes OT requiere adaptar la estrategia de captura al protocolo.
Modbus TCP es relativamente tolerante: podemos introducir un punto de captura y comenzar a analizar peticiones y respuestas.
PROFINET RT introduce mayores requisitos temporales, pero sigue permitiendo una monitorización relativamente sencilla.
PROFINET IRT exige conocer muy bien los retardos y la topología antes de modificar físicamente el enlace.
TSN incorpora mecanismos de sincronización y planificación que hacen del tiempo una parte fundamental del propio comportamiento de la red.
Por tanto, antes de conectar una herramienta de análisis deberíamos preguntarnos:
¿Qué protocolo estamos analizando, qué queremos medir y qué efecto tendrá nuestro propio sistema de captura sobre aquello que queremos observar?
Esa pregunta puede marcar la diferencia entre encontrar la causa de una incidencia y modificar involuntariamente las condiciones que la producen.
Soluciones para el diagnóstico de redes OT
En Garma Electrónica trabajamos con soluciones Profitap para acceso, captura y análisis de tráfico Ethernet, desde Network TAPs y ProfiShark hasta plataformas IOTA y arquitecturas de visibilidad de red.
¿Qué necesitas hacer?
| Necesidad | Solución a valorar |
|---|---|
| Realizar una captura puntual para diagnosticar una máquina o enlace | ProfiShark → Ver y comparar modelos |
| Investigar fallos intermitentes durante periodos prolongados | IOTA → Captura, almacenamiento y análisis |
| Obtener una copia del tráfico desde un enlace de red | Network TAP → Ver soluciones para cobre y fibra |
| Monitorizar varios enlaces o distribuir tráfico hacia varias herramientas | Network Packet Broker (NPB) → Ver soluciones de visibilidad |
| No sabes dónde o cómo realizar la captura | Consultar a Garma → Te ayudamos a definir el punto y método de captura |
Si necesitas abordar el diagnóstico de redes OT y no tienes claro qué arquitectura de captura utilizar, indícanos el protocolo, velocidad, medio físico, equipos implicados y qué problema estás intentando diagnosticar. Podemos ayudarte a determinar dónde capturar el tráfico y qué solución utilizar.
Artículo adaptado a partir del contenido técnico publicado por Profitap: “Capturing and Analyzing OT Network Traffic Workflow”.
Demostraciones Profitap en WeAR Bilbao, febrero de 2027
Garma Electrónica participará en la feria WeAR de Bilbao en febrero de 2027, donde realizaremos demostraciones de las soluciones Profitap. Será una oportunidad para conocer su aplicación al diagnóstico de redes industriales y comentar necesidades de mantenimiento, comunicaciones IT/OT y ciberseguridad.
Para más información.
