Qué es un BGP anycast y por qué los CDNs (Cloudflare, Akamai) lo usan para que tu data center sea más rápido

Por qué tu sitio web se siente igual desde Monterrey que desde Madrid

Cada vez que un usuario en Guadalajara abre Netflix, Cloudflare, Spotify o Mercado Libre, su dispositivo hace una pregunta aparentemente simple: ¿a qué servidor me conecto? La respuesta, en milisegundos, sale de una decisión de ruteo que el usuario nunca ve: el servidor más cercano topológicamente. La técnica que hace posible esa decisión se llama BGP anycast, y es la razón por la que un data center en Querétaro puede sentirse rápido para un usuario en Tokio sin tener un espejo ahí.

Qué es anycast y por qué importa

En una red convencional, una dirección IP vive en un solo lugar. Si un usuario envía un paquete a 1.2.3.4, los routers de Internet lo llevan, por caminos distintos, al mismo destino. Es lo que se llama unicast. Cualquiercast — anycast — rompe esa regla: la misma dirección IP se anuncia desde múltiples ubicaciones físicas, y los routers a lo largo del camino eligen, para cada paquete, el anuncio topológicamente más cercano. El usuario no sabe — ni necesita saber — cuál instancia atendió su solicitud.

El ruteo anycast depende del protocolo BGP, Border Gateway Protocol, que es el sistema de ruteo entre sistemas autónomos de Internet. Cada prefijo IP — por ejemplo `1.1.1.0/24` — se anuncia desde uno o más autonomous systems (AS). Cuando un AS anuncia el mismo prefijo desde dos sitios diferentes, los routers vecinos ven dos caminos al mismo destino y eligen el de menor costo. El criterio dominante es la longitud del AS-path: el camino con menos saltos inter-AS gana Fuente: semicolony.dev, Anycast simulator, 2026].

El resultado, desde el punto de vista del usuario, es transparente. Escribes `1.1.1.1` en tu cliente DNS y terminas en el Point of Presence (PoP) de Cloudflare más cercano a tu red — usualmente el mismo continente, frecuentemente la misma ciudad. La medición interna de Cloudflare reporta latencia mediana de resolución bajo 15 ms a nivel global Fuente: semicolony.dev, citando Cloudflare disclosure].

Cómo lo usan los CDN: el caso de Cloudflare, Akamai y Fastly

Una red de distribución de contenido — Content Delivery Network, CDN — existe para acercar el contenido al usuario. Antes del anycast, los CDN usaban GeoDNS: el servidor DNS autoritativo devolvía una IP distinta según el país o la región del cliente. El método funcionaba, pero con tres problemas estructurales:

1. La decisión de ruteo se hacía en el resolver DNS, no en la red. Un usuario español detrás de un resolver corporativo en Texas era enviado al PoP de Texas, no al de Madrid. La geolocalización por IP del resolver es aproximada, no exacta, y muchos usuarios quedan enrutados a un PoP subóptimo.

2. El failover dependía del TTL del DNS. Si un PoP caía, los usuarios seguían apuntando al IP viejo durante el TTL — 60 a 300 segundos en la mayoría de las configuraciones. Cinco minutos de servicio degradado.

3. La gestión de muchos IPs distintos para muchos PoPs sumaba complejidad operativa y abría vectores de ataque.

Cloudflare, Fastly y Google Cloud CDN adoptaron anycast desde el inicio o migraron a él. Cloudflare opera la mayor huella individual: más de 330 ciudades en más de 125 países, todas anunciando el mismo bloque `1.1.1.0/24` desde el AS 13335 Fuente: hld.handbook.academy, CDNs curriculum, 2026]. Akamai opera un modelo distinto por razones históricas — nació como red de appliances embedded dentro de ISPs — pero también usa anycast para sus edges; su huella combinada supera los 4,200 nodos Fuente: crosscheck.cloud, How CDNs work, 2026].

El resultado para el usuario: un paquete que sale de una laptop en São Paulo hacia `cualquier-cdn.com` llega al PoP de Cloudflare o Fastly en São Paulo — probablemente a menos de 20 ms de RTT. La latencia de un round-trip transcontinental, que fácilmente pasa de 100 ms, se reduce a una fracción. Sin que el usuario cambie nada. Sin que el desarrollador del sitio cambie nada.

El resultado para el operador del data center: cualquier PoP puede manejar la solicitud, y si uno falla, BGP lo retira del ruteo en segundos. La convergencia interna de Cloudflare usando BGP add-path y BFD es sub-segundo; la convergencia entre ASes externos está en el rango de 5 a 30 segundos dependiendo de la agresividad de los timers de los peers Fuente: semicolony.dev, Anycast simulator, 2026].

Cómo lo aprovechan los root DNS servers — la versión más extrema

Los 13 servidores raíz de DNS — las máquinas que sirven la punta de la jerarquía `.` — son cada uno una nube anycast de decenas a cientos de servidores físicos distribuidos globalmente. Las 13 direcciones IP (`a.root-servers.net` a `m.root-servers.net`) son anuncios anycast. La raíz K, por ejemplo, opera docenas de instancias en todos los continentes, y publica una cobertura que va más allá de los 200 puntos de presencia Fuente: hld.handbook.academy, 2026].

El sistema raíz maneja unos cuantos cientos de miles de millones de consultas por día [Fuente: hld.handbook, citing ICANN RSSAC y disclosure de operadores root server]. Sin anycast, eso significaría 13 datacenters recibiendo la carga entera del planeta — y derritiéndose. Con anycast, la carga se reparte por topología: una consulta desde Berlín aterriza en el PoP europeo; una consulta desde Buenos Aires aterriza en el PoP sudamericano.

Los resolvers públicos — Cloudflare `1.1.1.1`, Google `8.8.8.8`, Quad9 `9.9.9.9` — son también nubes anycast. La infraestructura es conceptualmente idéntica: una dirección IP anunciada desde N sitios, ruteo BGP eligiendo el más cercano. Cada uno sirve cientos de millones de consultas por segundo colectivamente.

Por qué un BGP anycast no es lo mismo que tener un CDN

Un punto que confunde: anycast te lleva al PoP más cercano por topología de red; el CDN decide qué hacer cuando llegas ahí. La diferencia importa porque cualquier IP puede ser anycast, pero no cualquier IP conviene ser anycast.

Las restricciones operativas están documentadas en dos RFCs canónicos:

• RFC 4786 — Operation of Anycast Services (BCP 126, diciembre 2006): todas las instancias deben ser funcionalmente idénticas. Si dos nodos anycast difieren — versión de zona DNS, certificado TLS, lista de cifras — los usuarios ven comportamiento Heisenbug dependiendo del ruteo.
• RFC 7094 — Architectural Considerations of IP Anycast (IAB, enero 2014): la entrega del servicio debe estar tightly coupled con el anuncio de la ruta. Si el servicio local cae, la ruta se retira; si el servicio vuelve, la ruta se re-anuncia.

El resultado práctico: stateful protocols sobre anycast son problemáticos. Una conexión TCP de larga duración — un websocket abierto 20 minutos, una sesión gRPC sostenida — puede romperse si el camino BGP cambia mid-flujo. En la práctica, las mediciones de RFC 7094 §3 y de Verisign muestran que la tasa de fallas de flujo por flap BGP es menor a 1 en 10,000 conexiones-hora Fuente: hivebook.wiki, Anycast one-IP-many-servers, 2026]. Pero la defensa es arquitectónica: tratar el anycast como best-effort y reconectar limpio, o terminar TLS en el edge anycast y usar un back-end unicast para sesiones largas. La mayoría de los CDN hacen lo segundo.

DDoS absorption: el caso de uso que justifica la inversión

El ataque DDoS más grande registrado públicamente a la fecha — 3.8 Tbps, mitigado por Cloudflare en 2024 — fue posible de absorber precisamente porque la dirección atacada estaba anunciada desde cientos de PoPs Fuente: labhub.hopto.org, CDN Edge Computing Deep Dive, 2026]. Cada PoP recibió una fracción del ataque proporcional a su anuncio BGP. Sin anycast, los 3.8 Tbps habrían golpeado un solo origen.

El mecanismo es matemáticamente simple. Un ataque de 10 Gbps desde un botnet, distribuido entre 20 PoPs por ruteo anycast, deja 500 Mbps por PoP. Cada PoP tiene capacidad de scrubbing local; ningún PoP individual se ahoga. Si un PoP se sobrecarga, BGP retira su anuncio y el tráfico se redistribuye al siguiente más cercano en segundos.

Por eso los CDN importantes operan sus propios ASN y sus propios prefijos IP portables. Cloudflare es AS13335; Akamai opera múltiples ASes por razones históricas; Fastly, AWS (CloudFront) y Google Cloud CDN operan los suyos. La propiedad del ASN y del bloque IP no es un lujo técnico — es el prerrequisito para hacer anycast a escala.

Qué significa esto para tu data center

Un data center corporativo en Monterrey, Querétaro o CDMX no necesita operar su propio anycast para servir a usuarios distribuidos globalmente. Lo que necesita es saber contratarlo:

1. Para servir usuarios globales desde una sola región, necesitas un CDN con anycast (Cloudflare, Fastly, Akamai, CloudFront). Cada peso que pongas en infraestructura propia multi-región sin CDN es dinero perdido — el PoP del CDN ya está a 20 ms del usuario.

2. Para que tu DNS sea rápido y resistente a DDoS, usa resolvers anycast (`1.1.1.1`, `8.8.8.8`, `9.9.9.9`) en lugar de un DNS autoritativo propio hosted en una sola región.

3. Si tu servicio sí es multi-regio y stateful — bases de datos con replicación, sesiones largas, websockets — diseña sabiendo que el edge puede ser anycast pero el estado vive detrás. El edge hace TLS termination; el origen es unicast.

4. Para absorber DDoS volumétrico, el anycast no es opcional. Una defensa on-premises con scrubbing local no escala contra 3 Tbps. Necesitas una red con la huella de anuncios para diluir el ataque antes de que llegue a tu rack.

La métrica que separa un proveedor de CDN de un proveedor de hosting con marketing bonito es el ASN y la huella de PoPs anycast. Si tu proveedor de “edge” no opera su propio AS y su propio bloque IP portable, no está haciendo anycast. Está haciendo GeoDNS con un nombre distinto — y hereda todas las limitaciones del GeoDNS, incluido el failover de minutos.

Fuentes

1. RFC 4786 — Operation of Anycast Services (BCP 126), IETF, diciembre 2006
2. RFC 7094 — Architectural Considerations of IP Anycast, IAB, enero 2014
3. Cloudflare — Network and anycast footprint disclosure, publicado 2026
4. Akamai — State of the Internet / CDN footprint disclosure, 2026
5. Verisign — The Anycast TCP Saga, mediciones de estabilidad de TCP sobre anycast