Migración de bloques IPv4 entre datacenters sin downtime

Por qué la migración de bloques IPv4 es un punto crítico

Mover una migración de bloques IPv4 entre datacenters es, quizá, la operación más delicada que puede hacer un equipo de red. Suena exagerado hasta que te toca vivirlo. Un anuncio BGP mal ejecutado, un LOA con cualquier errata o un filtrado inesperado en un IXP pueden dejar servicios en producción inaccesibles durante horas. Y no hablamos solo del valor operativo del prefijo: con los precios actuales del mercado —un /24 en espacio de RIPE NCC se mueve en una horquilla de 30 a 50 USD por dirección, según procedencia y ratio de uso—, hay dinero real sobre la mesa. Esto no se improvisa.

Lo bueno es que, planificando bien, se puede mover un prefijo de un datacenter a otro sin que los usuarios noten absolutamente nada. Ni un corte. Vamos a desglosar el proceso completo.

Requisitos previos: lo que debes tener resuelto antes de mover nada

Documentación y autorizaciones en el RIR

Si el bloque está registrado en RIPE NCC, lo primero es verificar que el recurso está correctamente asignado al LIR o entidad final que conservará la titularidad tras la migración. Aunque el prefijo no cambie de dueño, tendrás que actualizar los objetos inetnum y, en su caso, el mnt-by si cambia el mantenedor técnico. ¿Compraste el bloque hace poco? Entonces asegúrate de que la transferencia está completamente cerrada en la base de datos del RIR. Intentar anunciar un prefijo con transferencia a medias es una de las causas más frecuentes de filtrado. Lo he visto más de una vez.

LOA y relaciones con los tránsitos

Cualquier proveedor de tránsito nuevo te va a exigir un LOA (Letter of Authorization) que acredite que tienes derecho a anunciar el prefijo desde su red. Prepáralo con antelación. Debe incluir el AS number origen, el prefijo exacto, los datos de contacto y la firma de la entidad titular. Ojo con los plazos: los tránsitos grandes suelen tardar entre 24 y 72 horas en validar y desbloquear el prefijo en sus filtros. No dejes el papel para el día anterior.

RPKI y ROA

Antes de migrar, revisa el ROA asociado al prefijo y actualízalo. Debe autorizar el AS origen que anunciará el bloque desde el nuevo datacenter, con una maxLength coherente (si anuncias el /24 completo, un ROA que cubra exactamente /24 con maxLength /24 es lo más limpio). Aquí no hay margen para la pereza: cada vez más redes validan RPKI de forma obligatoria. En 2024 se estima que más del 50% del espacio de enrutado visible ya se valida, y un ROA desactualizado hace que tu prefijo sea tratado como invalid y descartado en grandes volúmenes de Internet. Horas muertas garantizadas.

Estrategias de migración zero downtime

Opción 1: anuncio dual con preferencia graduada

La técnica más segura consiste en mantener el prefijo anunciado a la vez desde ambos datacenters durante la ventana de migración. ¿Cómo se haría?

1. Anuncia el prefijo desde el nuevo datacenter con el mismo AS path o uno más corto, para que el tráfico empiece a virar gradualmente.
2. Ajusta comunidades y local-preference para controlar el reparto mientras verificas conectividad, latencia y filtros. Sin prisa.
3. Cuando tengas validado que el nuevo sitio entrega el servicio correctamente, retira el anuncio del datacenter antiguo.

Un detalle importante: elige un AS de origen compatible. Si el nuevo datacenter opera con su propio ASN, necesitarás que el prefijo aparezca como originado por ese AS en el ROA y en el IRR. Si ambos sitios comparten ASN, el proceso es aún más simple. Suerte la tuya si es el caso.

Opción 2: migración por subbloques

Si el bloque es mayor de un /24 (por ejemplo, un /22), migra en unidades mínimas anunciables: un /24 cada vez. La lógica es evidente —reduce el riesgo—: si algo falla, solo afecta a una cuarta parte del espacio. Ten en cuenta que necesitarás un ROA con maxLength adecuado y que conviene confirmar que tu tránsito y los IXPs a los que te conectas aceptan prefijos /24 sin problema (lo habitual, pero mejor comprobarlo antes de asumirlo).

Verificación técnica durante y después de la migración

Comprobaciones en tiempo real

• Looking glasses y route collectors: vigila RouteViews y RIPE RIS para confirmar que el prefijo se propaga desde el nuevo origen. Sin esto, vuelas a ciegas.
• Estado RPKI: consulta RIPEstat y Routinator para verificar que el prefijo figura como valid. Si sale invalid, detente y revisa el ROA antes de seguir.
• Coherencia IRR: crea o actualiza el objeto route o route6 en la IRR correspondiente antes del anuncio. Muchos tránsitos filtran contra IRR, y un objeto desactualizado puede dejarte invisible en buena parte de Internet.
• Pruebas activas: lanza probes desde RIPE Atlas y mide visibilidad y latencia desde varios países. Lo que ves desde tu oficina no siempre coincide con lo que ve un usuario en Singapur.

Gestión del TTL y el tráfico residual

Baja los TTL de los registros DNS a 300 segundos o menos al menos 24 horas antes de la migración, siempre que también cambien registros A o AAAA. Aunque el anuncio BGP hace el trabajo pesado, los TTL bajos te permiten revertir rápido si algo falla en servicios concretos.

Y una cosa más: mantén el datacenter antiguo operativo, con capacidad real de servir tráfico, durante al menos 72 horas tras el cutover. No lo apagues a las dos horas porque “parece que todo va bien”.

Errores frecuentes que conviene evitar

• No validar filtros previamente: hay tránsitos que exigen notificación previa de prefijos. Habla con su NOC con 3-5 días de antelación; un email enviado el día del cutover llega tarde.
• ROA con maxLength demasiado abierto: un ROA que permite un /20 con maxLength /24 facilita errores de configuración y secuestros parciales. Ajusta la longitud al máximo que realmente anuncias.
• Retirar el anuncio antiguo demasiado pronto: espera a que la convergencia BGP sea completa y el tráfico sobre el prefijo antiguo sea marginal. Prudencia, siempre.
• Olvidar la geolocalización: las bases geográficas (MaxMind, IP2Location) asociarán el bloque a la ubicación del nuevo datacenter. Actualízalas si tus servicios dependen de georouting, porque puede tardar en corregirse solo.

¿Comprar, alquilar o consolidar espacio durante la migración?

A veces una migración es también una buena excusa para reordenar tu espacio de direcciones. Si necesitas un /24 adicional para el nuevo datacenter, ten en cuenta que los precios de los bloques IPv4 siguen en máximos históricos y que la oferta de calidad es limitada. Trabajar con una plataforma como IP4 Market, con vendedores verificados y precios competitivos, agiliza el proceso y reduce el riesgo de fraude en la transferencia ante el RIR.

¿Y si solo lo necesitas de forma temporal? Por ejemplo, mientras consolidas bloques fragmentados. Entonces el alquiler de IPv4 con LOA y soporte RPKI sale a cuenta: flexible y con coste predecible.

Conclusión

Una migración de bloques IPv4 sin downtime no depende de la suerte. Depende de la preparación: documentación al día en el RIR, LOA disponibles, ROA e IRR actualizados, un plan de anuncio dual con criterios objetivos de cutover y un rollback probado. La secuencia es clara —preparar autorizaciones, anunciar en paralelo, validar propagación y RPKI, retirar el origen antiguo y mantener el sitio previo operativo durante 72 horas— y si la respetas, el movimiento entre datacenters puede ser totalmente transparente para tus usuarios. Y si la migración te lleva a ampliar tu espacio de direcciones, en IP4 Market encontrarás vendedores verificados, opciones de compra y alquiler, y precios competitivos para crecer sin fricciones ni sustos.