6.5. Port Mirroring (SPAN) en Switches Gestionables

UF1794 | La técnica esencial para capturar tráfico ajeno

graph TD subgraph Switch_Gestionable ["Switch Gestionable"] P1["Puerto 1"] P2["Puerto 2"] P8["Puerto 8 (Mirror)"] end subgraph Dispositivos PLC["PLC"] VFD["Variador"] PC["PC con Wireshark"] end PLC <--> P1 VFD <--> P2 PC <--> P8 subgraph Trafico Trama["Trama PLC <-> VFD"] Copia["Copia de la Trama"] end P1 -- Trama --> P2 P2 -- Trama --> P1 P1 -- Copia --> P8 P2 -- Copia --> P8 style P8 fill:#f39c12,color:white style PC fill:#f39c12,color:white style Trama fill:#27ae60,color:white style Copia fill:#e67e22,color:white

1. El Problema: El Switch Inteligente pero "Ciego"

Como hemos visto, un switch moderno no es un hub. Un hub es un dispositivo "tonto" de Capa 1 que repite cualquier señal eléctrica que le llega por todos sus puertos. Un switch, en cambio, es un dispositivo "inteligente" de Capa 2 que aprende qué dirección MAC vive en cada puerto. Cuando recibe una trama unicast, la envía únicamente al puerto de destino, no al resto. Esto es fantástico para la eficiencia, pero un desastre para el diagnóstico.

Si un técnico de UF1794 conecta su portátil con Wireshark al puerto 8 de un switch, y el PLC (en el puerto 1) está hablando con un variador (en el puerto 2), el técnico no verá ni un solo paquete de esa conversación. Para poder "espiar" conversaciones ajenas, necesitamos una función especial de los switches gestionables.



2. La Solución: Port Mirroring / SPAN

Port Mirroring (término genérico) o SPAN (Switched Port Analyzer, término de Cisco) es una función que permite instruir al switch para que haga una copia de todo el tráfico que pasa por un puerto (o varios) y la envíe a un puerto de destino específico donde tenemos conectado nuestro equipo de análisis.

La configuración es sencilla y se basa en tres conceptos:

  • Puerto(s) de Origen (Source Port): Son los puertos que queremos monitorizar. Podemos seleccionar uno o varios. Por ejemplo, los puertos 1 y 2 donde están el PLC y el variador.
  • Puerto de Destino (Destination/Mirror Port): Es el puerto donde conectaremos nuestro portátil con Wireshark. Es crucial entender que este puerto pierde su conectividad de red normal y se convierte en un puerto de "solo escucha".
  • Dirección del Tráfico: Podemos elegir qué tráfico copiar: solo el que entra al puerto (Ingress/Rx), solo el que sale (Egress/Tx), o ambos (Both). Para un diagnóstico completo, casi siempre elegiremos "Both".


3. Riesgos y Limitaciones del Port Mirroring

Aunque es una herramienta increíblemente potente, su uso incorrecto puede llevar a diagnósticos erróneos:

  • Sobresuscripción (Oversubscription): Es el error más grave y común. Imagina que quieres monitorizar la comunicación entre dos servidores que se intercambian datos a 1 Gbps. El tráfico total en esos puertos es de 2 Gbps (1 Gbps de envío y 1 Gbps de recepción en cada uno). Si configuras el mirroring de ambos puertos a un puerto de destino que también es de 1 Gbps, estás intentando meter 2 Gbps de tráfico en un "tubo" de 1 Gbps. El switch, al verse desbordado, descartará paquetes en el puerto de destino. Tu captura en Wireshark será incompleta y te mostrará pérdidas de paquetes que en la red real no existen, llevándote a un diagnóstico falso.
  • Carga en la CPU del Switch: La función de mirroring no es "gratis". Obliga al ASIC y a la CPU del switch a trabajar más para duplicar el tráfico. En switches de gama baja o en redes muy cargadas, activar el mirroring puede introducir una pequeña latencia adicional.

La regla de oro para evitar la sobresuscripción es asegurarse de que la suma del ancho de banda de los puertos de origen no supere el ancho de banda del puerto de destino. Si necesitas monitorizar varios puertos de 1 Gbps, utiliza un puerto de destino de 10 Gbps.

Ilustración conceptual de Port Mirroring mostrando cómo se duplica el tráfico de un puerto hacia el puerto del analizador.
Figura 1: El concepto de Port Mirroring (SPAN). El switch duplica el tráfico de los puertos de producción (Origen) a nivel de hardware y lo redirige hacia el puerto de diagnóstico (Destino), permitiendo al ingeniero "escuchar" la red sin interrumpir físicamente los cables de las máquinas.
Fuente: Elaboración propia / Licencia: CC BY-NC 4.0.

📝 Evaluación Técnica: Captura de Tráfico

1. Conectas tu portátil al puerto 3 de un switch. Un PLC en el puerto 1 está intercambiando datos con un variador en el puerto 2. ¿Por qué no puedes ver su conversación en Wireshark por defecto?

2. En una configuración de Port Mirroring, ¿qué le ocurre al "puerto de destino" (Destination Port), donde conectas tu portátil de análisis?

3. ¿Qué es la "sobresuscripción" (oversubscription) en Port Mirroring y cuál es su peligrosa consecuencia para un diagnóstico de red?

🤖 Ejercicio Práctico 6: Simulador de Lógica de Port Mirroring

Objetivo: Entender a bajo nivel cómo un switch decide qué paquetes debe duplicar hacia el puerto de análisis.

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

Actúa como el firmware de un switch gestionable. Escribe un script en Python que simule la lógica de Port Mirroring. El script debe: 1. Definir una configuración de mirroring, especificando una lista de `source_ports` (ej. [1, 2]) y un `destination_port` (ej. 8). 2. Simular una lista de paquetes entrantes, donde cada paquete es un diccionario con `src_port`, `dst_port` y `payload`. 3. Iterar sobre los paquetes. Para cada paquete, imprimir su ruta normal (ej. "Paquete de P1 a P5"). 4. Si el `src_port` O el `dst_port` del paquete está en la lista de `source_ports`, imprimir además "COPIANDO paquete a puerto espejo P8". Comenta el código explicando cómo esta simple lógica, implementada en hardware (ASIC), permite el diagnóstico de redes sin usar hubs.