Resumen del caso real de un día de soporte: cómo un detalle tan pequeño como un cable puede tirar abajo toda una red, y por qué el camino hasta encontrarlo es casi tan importante como la solución.
Hace unos días recibimos una alerta que ningún técnico quiere ver en pantalla: el firewall perimetral de un cliente con más de 600 dispositivos conectados estaba con la CPU al 99 % de forma sostenida. La red se arrastraba, las aplicaciones tardaban en responder y los usuarios empezaban a notar que algo no iba bien.
A primera vista, parecía un problema gordo. Y lo era. Pero la causa raíz, como suele pasar, era ridículamente sencilla.
Primer reflejo: mirar al firewall
Cuando un firewall se satura, lo lógico es preguntarse qué está haciendo de más. Las primeras hipótesis que barajamos fueron las habituales:
- ¿Un ataque de denegación de servicio dirigido contra algún puerto o servicio expuesto, o un equipo interno comprometido generando tráfico saliente anómalo?
- ¿Alguna funcionalidad de inspección profunda (antivirus, filtrado de contenido, IDP) consumiendo más de la cuenta?
- ¿Un volumen anormal de sesiones activas?
- ¿Algún proceso interno del firmware descontrolado?
Revisamos el estado del equipo y nos llevamos la primera sorpresa: solo había 4.600 sesiones activas, frente a un máximo soportado de 1.600.000. Tampoco había tráfico sospechoso entrando desde internet ni un perfil de salida compatible con un equipo infectado. El firewall no estaba ni cerca de su capacidad y nada apuntaba a un ataque. Y sin embargo, la CPU estaba clavada en el 99 %, con la mayor parte del tiempo dedicado a procesar paquetes a bajo nivel.
Eso descartaba las hipótesis fáciles. Había que mirar más abajo.
Segundo reflejo: mirar el tráfico
El siguiente paso fue analizar qué tipo de tráfico estaba llegando al firewall. Y ahí apareció el dato que lo cambió todo:
Más de 170 millones de paquetes de broadcast entrantes en menos de una hora, creciendo a un ritmo de aproximadamente 50.000 paquetes por segundo.
Un nivel de broadcast así no es uso normal de una red. Es síntoma de algo patológico ocurriendo en capa 2, la capa más baja del modelo de red, la que conecta físicamente los dispositivos entre sí.
A partir de ahí la hipótesis se reorientó: el problema no estaba dentro del firewall, sino en la red interna del cliente, que estaba bombardeándolo con tráfico que se ve obligado a procesar por software.
El giro inesperado
Mientras seguíamos midiendo, ocurrió algo que estuvo a punto de despistarnos. Un técnico del cliente, en remoto, decidió apagar parte de los switches sin avisar.
Por un momento pensamos que estábamos perdiendo el control del diagnóstico: los datos dejaron de cuadrar, las medidas variaban sin patrón, las direcciones IP empezaban a no responder. Hasta que confirmamos lo que había pasado, estuvimos diagnosticando un sistema en estado anormal por una intervención concurrente.
Esta es una de esas lecciones que uno aprende a las malas: antes de diagnosticar, hay que confirmar que el sistema está en su estado normal y que nadie más está tocándolo. Algo tan básico como preguntar «¿hay alguna intervención en curso ahora mismo?» puede ahorrar horas de análisis.
Pero el incidente paralelo también nos dio un dato valioso: al apagar los switches, la CPU del firewall bajó inmediatamente. Eso confirmó de forma definitiva que el origen del problema estaba en la red interna, no en las líneas de internet, no en el firewall, no en un ataque externo. Algo dentro del cliente estaba generando un tráfico anómalo.
La causa raíz: un cable
Cuando los switches volvieron y la red se estabilizó, el técnico del cliente revisó el cableado físico. Y ahí estaba: un cable conectado donde no debía estar, que cerraba un bucle entre dos switches.
Un bucle a ese nivel hace algo muy concreto: cada paquete de broadcast que entra se replica indefinidamente entre los switches hasta saturar la red. Es lo que se llama una tormenta de broadcast. El firewall, como puerta de enlace de las VLAN afectadas, recibía todo ese flujo y lo procesaba con la CPU, hasta ahogarse.
La solución fue retirar el cable. Inmediato. El firewall volvió a la normalidad en segundos.
Lo que dejamos mejorado de paso
Resolver el incidente era importante, pero no suficiente. Si la red podía colapsar por un cable mal conectado, podía volver a pasar. Por eso, junto con el cliente acordamos varias mejoras: activar la protección contra bucles en los switches gestionables para que la propia red detecte y bloquee este tipo de situaciones antes de que escalen; limitar el tráfico de broadcast por puerto para que ningún dispositivo individual pueda saturar la red; documentar y etiquetar el cableado para que cualquier futura intervención se haga sabiendo exactamente qué conecta cada cable; y revisar a medio plazo la segmentación de red para que un incidente en una zona no afecte a toda la organización.
El cliente pasó de tener una red que funcionaba casi siempre a tener una red que, cuando algo va mal, lo contiene.
La capa extra: vigilancia continua
Todo lo anterior son mejoras en la infraestructura del cliente. Pero hay algo más que conviene mencionar, porque es lo que cambia la ecuación entre «nos enteramos cuando los usuarios se quejan» y «nos enteramos cuando ocurre».
En este caso concreto, la supervisión proactiva de dispositivos críticos — firewalls, servidores, switches de núcleo, cabinas de almacenamiento — habría disparado una alerta automática en cuanto la CPU del firewall superó un umbral sostenido. Eso no habría evitado el cable, pero sí habría arrancado el diagnóstico antes de que los usuarios notaran nada, reduciendo el impacto a una fracción del tiempo.
Monitorizar bien no es poner un dashboard bonito. Es saber qué métricas importan en cada equipo (CPU, sesiones, broadcasts, errores de interfaz, disponibilidad de servicios), definir umbrales razonables y, sobre todo, tener a alguien que reciba la alerta y actúe. Sin esa última pieza, la monitorización es ruido.
Qué aprendimos (y qué te puedes llevar tú)
Dos conclusiones merecen la pena de este caso, sobre todo si gestionas una red mediana o grande.
La causa más espectacular puede tener un origen muy pequeño. Un firewall ahogado, 600 usuarios afectados y una red en parálisis pueden venir de algo tan ordinario como un cable mal puesto. Eso no es excepcional, es la norma. Por eso conviene desconfiar de las primeras hipótesis «evidentes» — el ataque, el bug del fabricante, el equipo infectado — y dejar que sean los datos los que dirijan el diagnóstico.
La comunicación entre cliente y técnico es parte del diagnóstico. Saber qué intervenciones hay en curso, quién está conectado, qué se ha cambiado recientemente, es información tan valiosa como cualquier log. En este caso, no saberlo a tiempo nos hizo perder tiempo. Saberlo después nos permitió confirmar la hipótesis correcta.
En KDS llevamos años acompañando a organizaciones con redes complejas. Cuando algo se rompe, no nos limitamos a apagar el fuego: buscamos por qué pudo encenderse y dejamos el entorno mejor preparado para la próxima vez.
Si tu red ha crecido más rápido que la documentación, o si llevas tiempo conviviendo con incidentes que no terminas de entender, escríbenos. Una revisión a tiempo cuesta mucho menos que un día con 600 personas paradas.
