El workaround no tapaba solo el fallo: tapaba la falta de evidencia

Hay incidentes que te enseñan algo técnico.

Y luego están los otros: los que te enseñan algo bastante más profundo sobre cómo pensamos cuando un sistema empieza a fallar a ratos.

Durante entre un año y un año y medio convivimos con un problema intermitente en varios puntos de acceso Ubiquiti. No era una caída permanente ni una avería limpia de las que te dejan un rastro nítido. Aparecía después de cambios de versión, tras actualizaciones o después de algún corte no planificado. De vez en cuando, algún AP se quedaba fuera.

La respuesta histórica era siempre la misma: reiniciar el equipo, esperar unos segundos y dar por cerrado el caso si volvía a registrarse.

Y claro, cuando algo “se arregla” así, el cerebro hace lo que mejor sabe hacer en mitad del barro: pasar al siguiente incendio.

Un sistema no está sano porque un reinicio lo devuelva al servicio; a veces estás borrando la pista que te habría permitido entender qué estaba roto de verdad.

El problema no era solo que los APs cayesen. El problema era que el reinicio borraba justo la evidencia que necesitábamos para entender por qué.

1. Cuando restaurar servicio no equivale a entender el sistema

La red no era precisamente de juguete. Había un par de OPNsense en configuración master-backup, una Dream Machine, switches Cisco montados en diseño en anillo y unos 20 APs mezclando modelos AC-Mesh y U6 Pro.

Además, la segmentación estaba pensada para evitar sustos clásicos. No se usaba la VLAN 1 como red funcional. La WiFi trabajaba con su VLAN de gestión, su VLAN corporativa y su VLAN de invitados o externa. Ese detalle importa porque la Dream Machine no permitía desactivar o reetiquetar VLAN 1 como nos habría gustado, así que se le asignó una IP no enrutable, inútil a efectos prácticos, para evitar que interfiriese o se convirtiera en un punto débil por descuido.

Sobre el papel, la arquitectura tenía sentido.

En la práctica, llevábamos demasiado tiempo aceptando una pauta peligrosa: si un AP caía tras una actualización, se reiniciaba, volvía, y todos contentos.

Eso reducía la urgencia, sí. Pero sobre todo reducía la posibilidad de capturar evidencia antes de alterar el estado del equipo.

2. El día que la incidencia fue demasiado grande para esconderse

Esta semana, después de una actualización, la cosa escaló de verdad. De unos 20 APs, aproximadamente 15 se quedaron abajo y solo 5 siguieron arriba.

Ahí ya no estás hablando de “bueno, reinicia ese y vemos”. Ahí ya tienes personal en sitio reseteando equipos, zonas críticas con riesgo real de perder servicio y la sensación bastante desagradable de que, como te equivoques en la hipótesis inicial, vas a perder tiempo del caro.

La primera sospecha fue casi automática: si caen tantos a la vez, esto huele a problema de red.

Y no era una hipótesis absurda. Con esa cantidad de APs afectados al mismo tiempo, lo razonable era mirar primero a la capa común: switching, routing, redundancia, anuncios, algo compartido.

Pero las hipótesis razonables también pueden ser falsas.

3. El momento en que la red dejó de ser la principal sospechosa

Lo que rompió la primera hipótesis fue un detalle simple: los APs seguían respondiendo a ping. No estaban muertos ni completamente aislados; tenían conectividad básica, pero no completaban bien la adopción. Ese matiz cambiaba el diagnóstico.

Y entonces apareció el patrón que de verdad empezó a ordenar el incidente.

Los APs afectados entraban en un bucle bastante feo, pero muy informativo:

• Offline
• pasaban a Adopting
• unos 60 segundos después volvían a Offline
• unos 15 segundos después regresaban a Adopting

Una y otra vez.

Ese patrón encajaba mejor con un problema de registro o adopción que con una caída general de red. Dicho de otro modo: el síntoma ya no apuntaba a ausencia de conectividad, sino a una conectividad que llevaba a un destino de gestión incorrecto.

4. La pista buena: no era que no hablasen, era que hablaban con quien no debían

La hipótesis que mejor encajaba con lo observado era una IP de Inform incorrecta.

Aquí es donde un incidente deja de ser una pelea a ciegas y empieza a parecer un diagnóstico de verdad. No porque tengas la respuesta final, sino porque de repente puedes contrastar una hipótesis concreta contra evidencia concreta.

Y la evidencia apareció por dos sitios distintos.

4.1. Un AP sano enseñó la referencia errónea

Uno de los APs que seguían funcionando mostraba en su estado un objetivo de inform que no cuadraba con lo esperado.

Ese detalle por sí solo ya era inquietante. Si un equipo operativo estaba apuntando a un destino incorrecto, la pregunta dejaba de ser “por qué fallan esos APs” y pasaba a ser “cuánto hace que tenemos aquí una referencia mala circulando sin darnos cuenta”.

4.2. Los logs del firewall pusieron el resto

La segunda evidencia vino del sitio donde suelen aparecer las verdades incómodas: los logs.

El firewall mostraba peticiones HTTP saliendo desde los APs que estaban fallando hacia esa IP incorrecta de la Dream Machine, sin respuesta útil al otro lado.

Ahí cambió el tono del incidente.

No era una intuición. No era una teoría bonita. Era un patrón observable: los APs estaban vivos, intentaban adoptar, pero lo hacían contra un destino incorrecto. Fallaban, esperaban y repetían.

La evidencia apuntaba menos a un fallo general de red y más a un problema de registro contra un destino de gestión erróneo.

5. La parte incómoda: el reinicio no solo calmaba el síntoma

Lo más interesante de todo esto no es el detalle concreto de Ubiquiti. Lo verdaderamente útil, al menos para cualquiera que lleve años bajando al barro en sistemas, es la lección de fondo.

Lo incómodo no es que el reinicio funcionara. Lo incómodo es que funcionara lo suficiente como para dificultar justo la captura de la evidencia necesaria. Cada recuperación rápida cerraba el caso antes de que pudiéramos observarlo en crudo.

Ese es el tipo de trampa que castiga a los equipos con experiencia, precisamente porque saben apagar fuegos deprisa.

Si cada vez que un AP caía lo reiniciabas y volvía, el sistema te estaba entrenando para cerrar el caso demasiado pronto. Esta vez, en cambio, el fallo fue tan masivo que ni siquiera después de reiniciar varios de los APs el comportamiento volvió a la normalidad. Y ahí, por fin, el parche rápido dejó de servir para diagnosticar.

6. Lo que sí sabíamos, lo que no, y por qué esa diferencia importa

Conviene ser muy preciso aquí, porque en incidentes reales es fácil rellenar huecos con confianza excesiva.

Esto es lo que teníamos:

• Observado: el comportamiento anómalo apareció esta semana después de una actualización.
• Observado: dos meses antes, el valor mostrado era la IP de gestión correcta.
• Observado: los APs respondían a ping, caían en bucle entre Offline y Adopting, y el firewall veía tráfico HTTP hacia una IP incorrecta.
• Inferido con bastante confianza: los APs seguían intentando registrarse contra un destino de gestión erróneo.
• No demostrado: qué actualización exacta introdujo o volvió a anunciar esa IP incorrecta.

Ese corte importa. No porque quede más elegante en un post-mortem, sino porque evita otra mala costumbre de la profesión: resolver el incidente y escribir después una historia demasiado limpia para haber sido verdad.

7. La corrección fue pequeña; el valor real estuvo en el enfoque

La corrección que estabilizó este entorno no fue épica. Ni siquiera fue especialmente vistosa.

Consistió en definir la entrada DNS unifi apuntando a la IP correcta de inform, una medida que además aparece recomendada en hilos de soporte de Ubiquiti para casos similares.

Y aquí suele haber una señal bastante útil de que ibas bien encaminado: el sistema deja de pelearse contigo casi de inmediato.

En el siguiente ciclo del bucle, tras unos 30 segundos aproximadamente, los APs empezaron a pasar a Online. Y en cosa de otros 30 segundos más, el conjunto volvió a estar arriba.

Más importante aún: la estabilidad se mantuvo a través de dos actualizaciones posteriores, una de ellas de la Dream Machine y la otra, de los APs caídos.

Eso no demuestra causalidad absoluta, pero operativamente pesa. No solo saliste del incidente; saliste con una corrección coherente con la hipótesis y que aguantó cambios posteriores sin reabrir la herida.

8. La lección útil para cualquiera que mantenga sistemas de verdad

No me interesa vender esto como “el truco para arreglar Ubiquiti”, porque esa no es la parte valiosa del caso.

La parte valiosa es otra: hay workarounds que restauran servicio y, al mismo tiempo, destruyen capacidad de diagnóstico.

Eso no significa que no debas usarlos nunca. A veces hay negocio, usuarios o una planta entera esperando, y devolver el servicio manda. Faltaría más.

Pero sí significa que conviene hacerse una pregunta incómoda cuando un apaño funciona demasiadas veces seguidas:

¿estoy resolviendo el problema o estoy reiniciando la escena del crimen antes de levantar huellas?

8.1. Cuándo un workaround sigue siendo sano

Un workaround tiene sentido cuando:

• te compra tiempo sin borrar los indicadores clave,
• puedes capturar evidencia antes de aplicarlo,
• y existe un plan real para volver después al análisis de causa.

8.2. Cuándo empieza a ser un problema

Empieza a ser peligroso cuando:

• se convierte en reflejo automático,
• reduce la curiosidad técnica del equipo,
• o deja el sistema “aparentemente bien” pero sin una explicación convincente.

En ese punto, el workaround deja de ser una mitigación. Pasa a ser una forma elegante de convivir con algo que todavía no entiendes.

Y eso, en redes y sistemas, suele salir caro tarde o temprano.

9. Lo que me llevo de este incidente

Si tuviera que resumir la lección en una sola idea, sería esta: los reinicios tienen muy mala fama y, aun así, a veces tienen una reputación demasiado buena.

Porque sí, un reinicio puede devolverte un servicio crítico en minutos. Todos lo hemos hecho. Todos lo seguiremos haciendo. Esto no va de purismo ni de postureo de laboratorio.

Va de recordar que restaurar servicio y entender la avería no son la misma cosa.

Y cuando ambos objetivos entran en tensión, lo mínimo exigible es ser consciente del precio que pagas al priorizar uno sobre el otro.

En este caso, el reinicio no tapaba solo el fallo. Tapaba la falta de evidencia. Y en sistemas, eso suele salir más caro que la avería inicial.

Nos leemos en el siguiente post.