Redundancia de canales de comunicación: Parte 4 — Acceso a Internet: BGP, failover de DNS y CDN

Para un sitio, tienda online o API, el riesgo principal es la pérdida de conexión a Internet: los clientes dejan de ver el servicio. Para una oficina, eso significa la parada del trabajo con servicios en la nube. El diseño de la redundancia de acceso a Internet varía según lo que haya que proteger: el acceso saliente de los empleados o las conexiones entrantes de los clientes a sus servidores.

Dos proveedores sin BGP

El esquema más asequible: dos proveedores, cada uno con su propia dirección, y un enrutador con conmutación automática.

El enrutador no comprueba solo la existencia del enlace al proveedor, sino la disponibilidad de Internet detrás de él. Para ello se hace ping a una dirección externa accesible únicamente a través de ese proveedor concreto. En MikroTik RouterOS esto se hace con rutas recursivas:

/ip route
add dst-address=8.8.8.8/32 gateway=203.0.113.1 scope=10
add dst-address=0.0.0.0/0 gateway=8.8.8.8 target-scope=11 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2

La primera línea envía la dirección de comprobación solo a través del proveedor principal (203.0.113.1). La ruta por defecto con distance=1 apunta a esa dirección y se comprueba con ping: RouterOS envía la comprobación cada 10 segundos y tras dos respuestas fallidas considera el gateway no disponible. Entonces el tráfico pasa a la ruta a través del proveedor de respaldo (distance=2). Detalles — en la documentación de MikroTik, sección Failover (WAN Backup).

Limitaciones del esquema:

• La conmutación tarda decenas de segundos, y las conexiones abiertas se cortan: el segundo proveedor tiene otra dirección exterior.
• Las conexiones entrantes funcionan con dos direcciones distintas. Las respuestas deben salir por el mismo proveedor por el que llegó la solicitud — véase «MikroTik: devolución del tráfico por la misma puerta de enlace». Para que los clientes encuentren el servicio ante la caída de un proveedor, se necesita DNS con comprobaciones (más abajo).

Para una oficina normalmente esto es suficiente. Para servicios públicos — no siempre.

BGP multihoming: mismas direcciones a través de dos proveedores

Para que sus direcciones sigan siendo accesibles ante la caída de cualquiera de los proveedores, hace falta un sistema autónomo propio (AS) y un bloque de direcciones propio, que anuncie a ambos proveedores mediante BGP. Internet verá dos rutas hacia su red y, ante la caída de una, usará la otra.

Qué se necesita

• Número de sistema autónomo (AS). En la región de RIPE NCC (Europa, Oriente Medio, Rusia) la política exige que la red esté conectada al menos a dos proveedores y tenga su propia política de enrutamiento. El número se obtiene mediante la membresía en RIPE NCC o a través de un LIR patrocinador — una organización intermediaria, por ejemplo un proveedor.
• Bloque de direcciones IPv4. Los IPv4 libres de RIPE NCC se han agotado. Los nuevos miembros que antes no recibieron IPv4 pueden entrar en una lista de espera para un bloque /24 (256 direcciones); la espera dura más de un año. Las solicitudes se verifican según las listas de sanciones de la UE. En la práctica, las direcciones se alquilan o compran en el mercado secundario, o se obtiene un bloque de uno de los proveedores con su consentimiento para anunciarlo a través del segundo — esto se negocia con los proveedores de antemano.
• Router con soporte BGP y un acuerdo con ambos proveedores para la sesión BGP.

Qué tan rápido conmuta BGP

Un error común es creer que «BGP conmuta en segundos». Si la falla no es visible a nivel de enlace (por ejemplo, falló un equipo más allá del punto de interconexión), BGP se entera por el timer de hold. RFC 4271 propone 90 segundos por defecto, y algunos fabricantes usan valores aún mayores. Además, los cambios deben propagarse por Internet.

Acelerar la detección de fallos permite BFD (RFC 5880): un protocolo ligero que intercambia paquetes con intervalos de cientos de milisegundos y notifica a BGP casi de inmediato. Hay que acordarlo con el proveedor. En su extremo se pueden reducir los timers de BGP, pero valores demasiado agresivos provocan falsos positivos.

Conmutación DNS (DNS failover)

Si hay varios servidores (o un servidor con dos proveedores y direcciones distintas), la conmutación se puede hacer a nivel DNS: un servicio DNS comprueba la disponibilidad de las direcciones y devuelve a los clientes solo las que funcionan.

• Se necesitan comprobaciones reales. Repartir varias A records en round robin no detecta fallos: parte de los clientes seguirá recibiendo la dirección del servidor que no funciona.
• TTL corto (60–300 segundos), de lo contrario los clientes mantendrán la dirección antigua hasta que caduque el caché. Algunos resolvers y navegadores cachean más tiempo, por lo que la conmutación no es instantánea.
• El propio DNS también se debe redundar: la zona la sirven varios servidores en redes distintas.

DNS failover no requiere su propio AS y es apropiado cuando se toleran minutos de conmutación.

CDN

La red de entrega de contenido almacena copias de archivos estáticos (y a veces páginas) en servidores por todo el mundo y los sirve a los usuarios desde el nodo más cercano. Ante una indisponibilidad breve del servidor de origen, la CDN puede seguir sirviendo contenidos cacheados y además absorbe parte de los ataques DDoS.

Para la audiencia rusa hay una limitación importante. Desde el 9 de junio de 2025 los proveedores rusos, incluidos Rostelecom, MegaFon, Beeline y MTS, limitan el tráfico hacia sitios detrás de Cloudflare: a los usuarios solo se les cargan los primeros 16 KB de cada recurso, y los sitios dejan de funcionar. Cloudflare lo confirmó y comunicó que no puede evitar la limitación desde su lado. Si su audiencia está en Rusia, elija una CDN con nodos en Rusia.

Nubes y múltiples ubicaciones

Para servicios con altos requisitos se reserva no solo el canal, sino también los propios servidores: copias de la aplicación funcionan en diferentes zonas de disponibilidad de la nube o en distintos centros de datos, y el tráfico entre ellos lo reparte un balanceador o DNS. Esto ya es una cuestión de arquitectura de la aplicación y replicación de datos, no solo de conectividad.

Qué elegir

Errores típicos

• Comprobar el enlace en lugar de la disponibilidad de Internet. El enlace al proveedor existe, pero Internet detrás no, y el enrutador no conmuta.
• Round robin DNS en lugar de failover.
• TTL largo en los registros de un servicio que necesita conmutación rápida.
• BGP sin BFD confiando en conmutación instantánea.
• CDN inaccesible para la audiencia objetivo.
• Canal de respaldo sin monitorización: su fallo se detecta el día de la avería del canal principal.