Actualización de firmware de switches sin tiempo de inactividad: estrategia de despliegue, pruebas y plan de reversión

Una actualización de firmware de switches sin tiempo de inactividad parece una promesa que en la práctica suele fallar por detalles: un uplink individual sin LACP, una ruta STP configurada erróneamente, un stack con modelos mixtos o una imagen que arranca pero activa nuevos valores por defecto. Al mismo tiempo, las actualizaciones de firmware no son un «nice to have». Cierran vulnerabilidades de seguridad, corrigen fugas de memoria, mejoran la interoperabilidad (p. ej. con LACP, BGP/EVPN o PoE) y estabilizan la operación.

Esta entrada muestra cómo planificar y desplegar actualizaciones de firmware de modo que, idealmente, usuarios y sistemas no perciban nada. El foco no está en comandos específicos de fabricante, sino en la lógica operativa: qué redundancia necesita realmente, qué comprobaciones previas son obligatorias, cómo se realiza un despliegue por fases a través de Access/Distribution/Core y cómo debe ser un plan de rollback sólido —incluyendo trampas típicas y puntos de monitorización.

Por qué «sin tiempo de inactividad» en switches a veces es cierto — y a veces no

«Sin tiempo de inactividad» suele significar en redes: ninguna interrupción perceptible para los servicios conectados. Técnicamente pueden producirse eventos breves: pérdidas de paquetes aisladas, una reconvergencia de enrutamiento, un cambio de topología STP o un enlace inestable (link-flap). Si eso cuenta como tiempo de inactividad depende de sus aplicaciones (VoIP, OT, Storage, VDI), de los timeouts y de su redundancia.

Importante: una actualización de firmware no es automáticamente «hitless». Los fabricantes ofrecen mecanismos como ISSU (In-Service Software Upgrade, actualización en servicio), «non-disruptive upgrade», «rolling upgrade» en stacks o rutas de actualización para MLAG/vPC. Estos procedimientos funcionan solo si se cumplen ciertas condiciones: revisiones de hardware compatibles, combinaciones de conjuntos de funciones soportadas, imágenes idénticas, versiones de bootloader adecuadas, un diseño correcto de Dual-Control-Plane o socios LACP estables.

Requisitos básicos para una actualización de firmware de switches sin tiempo de inactividad

Si realmente puede actualizar sin interrupciones perceptibles se decide de antemano. Compruebe estos puntos antes de descargar siquiera una imagen:

1) La redundancia no es una etiqueta, sino una prueba

«Dual-homed» solo es fiable cuando cada conexión crítica es redundante —y hasta la siguiente capa (Distribution/Core) y más allá hasta los gateways de enrutamiento. Patrones típicos:

• LACP (Link Aggregation Control Protocol): Agrupa varios enlaces físicos en un puerto lógico (port-channel). Si falla un enlace, el canal permanece activo. Requisitos: hashing correcto, misma MTU, mismos parámetros VLAN y STP en todos los puertos miembros.
• MLAG/vPC: Dos switches se presentan ante el downstream como un único socio LACP lógico. Ventaja: redundancia sin bloqueo STP en los uplinks de acceso. Riesgo: el diseño del peer-link/keepalive y la protección contra split-brain deben estar bien implementados.

Si un Access-Switch solo tiene un uplink o un servidor utiliza únicamente una NIC sin bonding/teaming, allí no es posible alcanzar «sin tiempo de inactividad». Entonces el objetivo es más bien: minimizar y controlar el tiempo de inactividad.

2) Entender el plano de control y el plano de datos

Para los operadores la separación es decisiva: la Data Plane reenvía paquetes (ASICs/encaminamiento), la Control Plane calcula tablas y vecindades (STP, OSPF/BGP, ARP/ND). Una actualización sin interrupciones (hitless Upgrade) intenta mantener el reenvío lo más estable posible mientras la Control Plane se reinicia o cambia a una segunda Supervisor/Route-Engine. Esto puede fallar si se usan funciones que no están soportadas durante ISSU (p. ej. ciertos módulos de telemetría, PBR, perfiles QoS especiales, MACsec, combinaciones VXLAN/EVPN según la versión).

3) El acceso de gestión y el Out-of-Band deben estar disponibles

Sin OOB-Management (out-of-band, red de gestión separada) un despliegue es arriesgado: si la red inband fluctúa brevemente, pierde acceso precisamente cuando lo necesita. Como mínimo se requieren: AAA consistente (RADIUS/TACACS), cuentas locales de reserva, servidores de consola accesibles o un proceso de Remote-Hands.

4) Respaldar datos de configuración y estado

Una actualización de firmware no solo cambia el software, sino a veces también: el bootloader, valores por defecto, flags de funciones, formatos de base de datos para configuración o almacenes de certificados/llaves. Por eso, respalde:

• Configuración running y startup
• Conjunto de imágenes actual (incl. imagen secundaria/de respaldo, si existe)
• Inventario: modelo, número de serie, revisión de hardware, estado de PSU/ventiladores
• Estados operativos importantes: STP root, estado MLAG/vPC, adyacencias de enrutamiento, estado de Port-Channel

Estrategia de despliegue: Cómo planificar la ruta de actualización a través de Access, Distribution y Core

La mejor estrategia de actualización se orienta por dominios de fallos y dependencias. Un principio sencillo y robusto en la práctica: primero los bordes, luego el centro —pero con cautela.

Fase 0: Readiness-Check y plan de cambio

Redacte un plan de cambio que no se limite a «realizar la actualización», sino que incluya criterios medibles: Go/No-Go, umbrales de monitorización, triggers de rollback, canales de comunicación y calendario. Si trabaja orientado a ITIL: el plan de retroceso es obligatorio, pero debe ser técnicamente ejecutable (ver más abajo).

Fase 1: Lab/Canary – un subconjunto representativo

Comience con un Canary: un switch o un par (MLAG/vPC) en un segmento representativo (mismas funciones, VLANs similares, mismas ópticas/transceptores) – pero operativamente tolerable. El objetivo no es solo que „arranque“, sino: funcione de forma estable bajo su carga y su monitorización.

Fase 2: Actualización progresiva de la capa de acceso

Los switches de acceso suelen ser numerosos, pero individualmente menos críticos. Si los dispositivos finales están dual-homed (p. ej. servidores con LACP hacia dos switches de acceso o hacia un par MLAG), puede actualizar los dispositivos de acceso de uno en uno. Si los dispositivos finales están single-homed, deje explícito allí que se permiten interrupciones breves – y planifíquelas dentro de una ventana de mantenimiento.

Fase 3: Distribución/Leaf – por pares y con comprobaciones de estado

En la distribución (o en la capa Leaf en un diseño Spine-Leaf) son más frecuentes los mecanismos MLAG/vPC/EVPN. Aquí la actualización „sin tiempo de inactividad“ se vuelve realista si actúa por pares: primero el switch A, comprobar la estabilidad, luego el switch B. Es importante que los Peer-Links y Keepalives se mantengan estables durante el proceso.

Fase 4: Core/Spine – solo con convergencia de enrutamiento asegurada

En el Core o capa Spine el impacto es mayor. Incluso si los caminos de datos son redundantes, un reinicio del plano de control puede provocar que BGP/OSPF se restablezcan. Planifique aquí con cuidado: evite cambios en las políticas de rutas, no modifique timers „on the fly“, y verifique de antemano si sus aplicaciones toleran eventos de enrutamiento breves. Para redes de almacenamiento (iSCSI/NFS): planifique de forma especialmente conservadora, ya que pérdidas de paquetes breves pueden ya afectar las sesiones.

Errores típicos que hacen que el enfoque „hitless“ falle en la práctica

Muchas fallas durante el despliegue de firmware no son bugs misteriosos, sino patrones recurrentes:

• Redundancia asimétrica: Existen dos uplinks, pero solo uno transporta VLANs o la MTU es diferente. En un failover se produce blackholing.
• Sorpresas de STP: Spanning Tree (prevención de bucles en Layer 2) reacciona a eventos de enlace. Una actualización puede desencadenar cambios de topología que provoquen bloqueos temporales – especialmente si el root está mal ubicado o si hay ajustes PortFast/Edge inconsistentes.
• MLAG/vPC-Split-Brain: El peer-keepalive circula por la misma red que el peer-link o es demasiado frágil. Si falla, puede producirse una situación dual-active.
• Stacks con generaciones mixtas: El rolling-upgrade está limitado o directamente no es posible. Un miembro se reinicia y arrastra el estado del stack.
• Compatibilidad de transceptores/ópticas: Tras la actualización, las ópticas de terceros pueden someterse a comprobaciones más estrictas o cambiar la interpretación de DOM/EEPROM. Resultado: los enlaces quedan down.
• Dependencias de bootloader/ROMMON: La nueva imagen requiere un paso de actualización del bootloader. Si se omite, el switch puede no arrancar tras el reinicio.
• Feature-Flags y valores por defecto: Cambian funciones de seguridad (p. ej. valores por defecto de cifrado SSH más estrictos, versiones de TLS, requisitos de SNMPv3). Las herramientas de gestión pierden acceso.

Comprobaciones previas: lista de verificación para inventario, compatibilidad y riesgo

Las siguientes comprobaciones están formuladas de modo que pueda incorporarlas a su runbook. Los comandos del fabricante varían; la lógica sigue siendo la misma.

Inventario y dependencias (obligatorio)

• Versión actual de firmware y versión objetivo planificada; comprobar si es necesario un paso intermedio (ruta de actualización).
• Revisiones de hardware, miembros de stack, módulos Supervisor/RE, estado de PSU/ventiladores.
• Funciones en uso: MLAG/vPC, VXLAN/EVPN, MACsec, PBR, NetFlow/sFlow, telemetría, DHCP Snooping, Dynamic ARP Inspection, 802.1X.
• Gestión: AAA, políticas SSH, SNMP (v2c/v3), Syslog, NTP, certificados.
• Sistemas dependientes: NAC, monitorización, backup de configuración, IPAM/DCIM, herramientas de automatización.

Validación de redundancia (verificación en lugar de suposición)

Pruebe el failover antes de la actualización. La prueba debe ser realista: no basta con «desconectar el enlace», sino que hay que verificar si el tráfico realmente se redirige. Pasos recomendados:

1. Registrar líneas base (latencia, pérdida de paquetes, contadores de errores de interfaz, CPU/memoria de los switches).
2. Desactivar brevemente el uplink A y observar: ¿permanecen estables las sesiones, converge STP/enrutamiento, aumenta la pérdida de paquetes?
3. Reactivar el uplink A, misma observación.
4. Repetir lo mismo para el uplink B.

Si el failover ya no funciona correctamente en condiciones normales, una actualización de firmware no resolverá el problema — solo lo hará visible.

Preparación de monitorización y registro

Para una actualización sin tiempo de inactividad necesita „ojos y oídos“: SNMP/telemetría en streaming, Syslog y, si procede, seguimiento de errores de interfaz. Preste atención a los contadores que suelen verse afectados en las actualizaciones: CRC/Alignment Errors, Input Drops, STP TCNs (Topology Change Notifications), LACP-Flaps, BGP Neighbor Down/Up.

Ejecución en producción: plan por fases con comprobaciones previas y posteriores

A continuación un plan por fases independiente del fabricante. Úselo como plantilla para su runbook; añada los comandos CLI concretos de su plataforma.

Paso 1: Comprobaciones previas justo antes del cambio

• Congelación de cambios para cambios paralelos (firewall, enrutamiento, VLAN, almacenamiento), para separar efectos.
• Copia de seguridad de la configuración (automatizada + verificada manualmente para asegurar que es legible).
• Probar acceso de gestión: OOB accesible, login OK, modo privilegiado OK.
• Chequeo de salud: no debe haber enlaces flapping, no altas tasas de errores, ni vecinos de enrutamiento inestables.

Paso 2: Gestión de imagen e integridad

No cargue imágenes desde „cualquier origen“ al switch. Use una fuente controlada (repositorio interno, descargas firmadas del proveedor) y verifique la integridad (hash) y el espacio de almacenamiento. A modo de ejemplo, una comprobación de hash en un host de administración:

# Beispiel: SHA256-Hash einer Firmware-Datei prüfen
sha256sum switch-firmware.bin
# Erwarteten Hash aus Herstellerquelle/Release-Notes gegenprüfen

Por qué es importante: las imágenes dañadas provocan boot-loops o errores extraños en tiempo de ejecución que solo aparecen tras el reinicio. La verificación de hash es una protección sencilla y económica.

Paso 3: Rolling Upgrade en pares (MLAG/vPC) – Principio

En un par de switches el principio es siempre similar, sea cual sea la denominación: mantiene un nodo en servicio mientras el otro se actualiza y reinicia. Son decisivas tres comprobaciones:

• Peer-Link/Interconnect estable: el nodo que queda debe mantener correctamente el estado del par.
• Downstream-LACP estable: los servidores/accesos deben continuar con sus agregaciones.
• Gateway/Anycast estable: si utiliza gateways Anycast, el failover debe ser limpio.

En la práctica esto significa: actualizar el nodo A, esperar hasta que esté completamente de nuevo en el clúster, con el estado sincronizado, y solo entonces el nodo B.

Paso 4: Upgrade en stacks – Particularidades

En apilamientos (stacking) los miembros frecuentemente comparten un plano de control. Algunas plataformas permiten actualizaciones „hitless/rolling“, otras reinician todo el stack como unidad. Por tanto, compruebe previamente:

• ¿Está soportada una actualización hitless/rolling para su modelo de stack y su versión?
• ¿La topología del stack es redundante (anillo en lugar de línea), de modo que el reinicio de un miembro no parta el stack?
• ¿Qué papel tiene el Master (Active) y cómo se realiza el switchover?

Si no se admite rolling, «sin downtime» solo es posible si los dispositivos finales están conectados de forma redundante fuera del stack (p. ej., Dual-Homing a dos stacks separados); de lo contrario habrá una interrupción perceptible.

Paso 5: Comprobaciones post‑cambio – no solo «el ping funciona»

Muchos equipos dan por terminado un cambio tras un login exitoso. Para garantizar estabilidad necesita más:

• Port-Channel/LACP: todos los miembros up, sin „suspended“, sin reequilibrados inusuales.
• STP: Root-Bridge según lo previsto, sin Topology-Changes inesperados, sin puertos en un estado incorrecto.
• Routing (si L3): vecinos up, rutas completas, ECMP activo, sin flaps.
• Errores de interfaz: CRC/Input Errors/Drops sin aumento.
• Gestión: SNMP/telemetry entregando, Syslog recibido, NTP sincronizado, AAA ok.

Sólo cuando estos puntos estén estables, se procede con el siguiente switch.

Plan de rollback: qué funciona realmente en caso grave

Un rollback no es «volvemos a poner la imagen antigua», sino un procedimiento mecánico que funcione incluso bajo estrés. Planifique el rollback de modo que pueda ejecutarse dentro de su ventana máxima tolerada de interrupción (RTO en la jerga operativa: Recovery Time Objective).

Definir triggers de rollback (¡antes!)

Sin triggers claros, los equipos discuten demasiado. Triggers típicos que justifican un rollback inmediato:

• Core/Distribution: inestabilidad de routing (flaps de vecinos) que no se estabilice en minutos
• MLAG/vPC: indicadores de Dual-Active/Split-Brain, Peer-Link inestable
• Errores masivos de interfaz tras el upgrade (CRC/Drops aumentan bruscamente)
• Pérdida de gestión: sin acceso por OOB e inband, solo Remote Hands
• Incompatibilidad inesperada: Optics/PoE/802.1X fallan a gran escala

Mecánicas de rollback: imagen, configuración, variables de arranque

En la práctica hay tres niveles de rollback:

1. Arranque en la imagen secundaria/de respaldo: muchos switches pueden mantener una segunda imagen. Ésta es la vía más rápida cuando la nueva imagen es, básicamente, la causa del problema.
2. Instalación de downgrade: Reinstalación de la versión anterior. Atención: algunas plataformas no permiten un downgrade directo a través de determinados Major-Releases.
3. Rollback de configuración: Si la imagen está bien, pero los valores por defecto de features o cambios en el parser interpretan la configuración de otra manera, necesita una copia de seguridad de configuración verificada y, si procede, ajustes.

Planifique explícitamente qué nivel va a tirar primero. Y: mantenga la firmware antigua disponible localmente (Repo + ruta de transferencia accesible), no solo «en Internet».

Prueba de rollback en el entorno Canary es obligatoria

El error de rollback más frecuente: nadie lo ha practicado. En el entorno Canary debería, por tanto, al menos una vez ensayar el «arranque con la imagen antigua» y la restauración de un Config-Backup. Objetivo: saber cuánto tiempo lleva y qué estados intermedios son críticos (p. ej., sincronización MLAG temporalmente ausente).

Solución de problemas durante y después de la actualización: vías rápidas de diagnóstico

Si después de la actualización algo está «raro», ayuda un camino de diagnóstico corto y estandarizado, en lugar de clicar de forma nerviosa en todas direcciones.

Síntoma: los dispositivos finales pierden brevemente la conexión

• Comprobar: ¿LACP/Port-Channel flaps? ¿Cambios en la topología STP? ¿Eventos de enlace en los uplinks?
• Por qué ocurre: un enlace miembro se reinicia, LACP se renegocia, STP recalcula. Si Edge/PortFast está mal, tarda más.
• Contramedida: configurar correctamente STP-Edge, parámetros LACP consistentes, validar rutas redundantes.

Síntoma: vecinos (OSPF/BGP) presentan flapping, aunque los enlaces estén operativos

• Comprobar: picos de CPU/memoria tras el arranque, timers/keepalive, MTU, ACLs/CoPP (Control Plane Policing).
• Por qué ocurre: la Control Plane necesita más tiempo después del upgrade; entran en vigor nuevos valores por defecto para CoPP o políticas de enrutamiento.
• Contramedida: esperar estabilidad (tiempo definido), luego comprobar los triggers de rollback; comparar políticas.

Síntoma: VLANs/servicios individuales «desaparecen»

• Comprobar: listas de VLAN permitidas en trunks, VLAN nativa, base de datos de VLAN, señalización VTP/EVPN según el diseño.
• Por qué ocurre: cambios en el parser, nuevo manejo por defecto de tramas sin tag, adopción incorrecta de plantillas.
• Contramedida: diff de configuración contra el backup, re-aplicación dirigida de secciones críticas.

Automatización y documentación: menos errores tipográficos, mejor trazabilidad

Aunque no use automatización completa: una actualización se beneficia de procedimientos estandarizados. Dos bloques pragmáticos:

• Backups de configuración y diffs: realizar copias automáticas diarias y crear antes del cambio un «Golden Backup». Los diffs ayudan a detectar efectos colaterales.
• Runbook como lista de verificación: secuencia de pasos con sellos temporales, responsables, puntos de comprobación y triggers de rollback. Suena burocrático, pero reduce errores bajo estrés.

Si ya automatiza despliegues de red: incluya Pre-/Post-Checks como tareas propias (p. ej., estado de interfaces, vecindades, contadores de errores). Para muchos equipos, un punto de entrada práctico es abordar esto mediante enfoques declarativos de automatización. En este sentido, puede ayudar una lectura más profunda de la guía sobre Automatización de red con Ansible para configuración de switches, backups y rollbacks para hacer reproducibles los runbooks de actualización.

Conclusión: las actualizaciones de firmware sin tiempo de inactividad son un tema de arquitectura y de procesos

Una actualización de firmware de switches sin tiempo de inactividad tiene éxito cuando la redundancia no solo está disponible, sino que funciona de forma demostrable, y cuando los mecanismos de actualización (ISSU, Rolling, MLAG/vPC) encajan con su topología. Decisivas son las comprobaciones previas rigurosas, un despliegue escalonado (Canary → Acceso → Distribución → Núcleo) y un plan de rollback ensayado con desencadenantes claros. Así la actualización de firmware deja de ser un evento de riesgo para convertirse en un cambio rutinario controlado — con servicios estables y operación verificable.

Para este tema también son importantes las actualizaciones de firmware en switches y las actualizaciones de apilamiento (stacking). El artículo sitúa estos aspectos de forma clara y muestra qué es importante en la operativa diaria.