Problemas de failover con Sophos XGS 5500 y ISP que puentea ambas conexiones

Un administrador de redes está atascado con una arquitectura que debería ser simple: un clúster HA Sophos XGS 5500 conectado a un switch Ruckus ICX, con un enlace de fibra como primario y un enlace de radiofrecuencia (RF) como respaldo provisto por el mismo ISP.

El ISP ha configurado ambos enlaces en modo bridge y los ha puesto en la misma VLAN. Al activar los dos puertos en el switch se produce un bucle de broadcast inmediato y un violento flapping de MAC que colapsa la red. El administrador intentó activar STP (802.1w) pero los módems del ISP descartan silenciosamente todos los BPDUs y también las sondas L2 de keep‑alive personalizadas. El switch, al no recibir BPDUs, no bloquea el puerto de respaldo.

Como segunda opción se intentó conectar directamente los dos enlaces al Sophos, pero el firewall rechaza la configuración porque los cinco IP estáticos que el ISP asignó comparten la misma puerta de enlace en ambas conexiones, lo que implica subredes superpuestas. Sophos no permite interfaces WAN con subredes que se solapan, así que la única solución provisional es mantener el puerto RF administrativamente desactivado y activarlo manualmente cuando falla la fibra.

El administrador está presionando al ISP para que le asigne un bloque de IP independiente para el enlace RF, lo que permitiría al firewall gestionar el failover de forma nativa. Mientras tanto busca una solución “zero‑touch” a nivel de switch o firewall, pero hasta ahora no ha encontrado una que funcione con la política del ISP de bloquear BPDUs.

Posibles vías de solución

• Configurar VLANs separadas para cada enlace y usar un router externo que realice el enrutamiento entre ellas, evitando que el ISP tenga que bridgear ambas.
• Implementar un protocolo de failover a nivel de capa 3, como VRRP o BGP con comunidades específicas, que no dependa de STP.
• Utilizar un dispositivo de “WAN balancer” que pueda detectar la pérdida de enlace sin necesidad de BPDUs y conmutar el tráfico en L3.
• Pedir al ISP que habilite el paso de BPDUs o que proporcione un segundo gateway para la ruta de respaldo.

En cualquier caso, la clave está en eliminar la superposición de subredes y evitar que el ISP actúe como puente único para ambas rutas. Mientras se negocia con el ISP, la única medida práctica es mantener el puerto de respaldo desactivado y documentar un proceso de activación manual rápido.

Conclusión El caso muestra que un diseño de alta disponibilidad que depende de la capa 2 puede colapsar si el proveedor no respeta los protocolos de control de bucle. La solución pasa por aislar los enlaces en VLAN distintas o migrar a una arquitectura de failover basada en capa 3, lo que permite que el firewall gestione la conmutación sin depender de STP. Queda pendiente ver si el ISP acepta asignar un bloque de IP propio o habilitar BPDUs, lo que definiría la vía más sencilla.