Resumen

  • Una ponencia de NANOG 98 relata cómo se trasladó un servicio TCP a la nube puerto por puerto, mientras el sitio antiguo seguía anunciando la misma IP.
  • El ponente informa de 3.000 puertos movidos en seis meses, dos reversiones por problemas de aplicación y ninguna transacción perdida. RFC 8955 no estandariza el redirect-nh de las diapositivas.

La IP del servicio no podía cambiar. Por eso tampoco bastaba con tocar DNS. En NANOG 98, el arquitecto de infraestructura Hervé Hildenbrand presentó un servicio que usaba una IP fijada en el código de sus clientes y TCP directo. No había un proxy que la aplicación pudiera aceptar ni una actualización de firmware al alcance del equipo.

Mover todo el /32 de una vez habría trasladado más de 3.000 puertos juntos. Mantener el mismo anuncio desde dos sitios podía partir sesiones activas. El equipo necesitaba una migración gradual, pero sin cambiar la dirección que veían los clientes.

La presentación de NANOG muestra la solución. El tráfico normal seguía en el sitio antiguo. FlowSpec desviaba solo las combinaciones elegidas de dirección de destino, protocolo y puerto. Las reglas enviaban ese tráfico a un punto Anycast de la nueva nube. MPLS conectaba ambos sitios. Se movía un puerto cuando estaba listo; los demás seguían por la ruta anterior.

Al terminar, el equipo anunciaba el /32 desde el nuevo extremo, retiraba el anuncio del antiguo y eliminaba las reglas FlowSpec. Así cerraba el desvío temporal sin cambiar la IP del servicio.

El detalle delicado está en el siguiente salto. «FlowSpec» define cómo expresar y distribuir coincidencias por BGP. No garantiza cualquier acción de encaminamiento. La RFC 8955 permite coincidencias por prefijo, protocolo y puerto. También dice que se ignora el siguiente salto incluido en el NLRI de FlowSpec. La acción estándar de redirección conduce el tráfico a una VRF identificada por una route target.

Las diapositivas muestran otra acción: redirect-nh hacia una dirección Anycast. RFC 8955 permite añadir acciones mediante otra norma o mediante una implementación concreta. No convierte esa acción en una función portátil. Hildenbrand no identifica el equipo ni incluye la codificación de redirect-nh en el cable.

También había controles operativos. Las reglas vivían en Git/Terraform. La validación de CI/CD revisaba direcciones, rangos de puertos y siguientes saltos permitidos. Los routers tenían filtros para rechazar destinos no autorizados. Era una barrera importante: una regla equivocada puede afectar tráfico a velocidad de reenvío.

El ponente informa de 3.000 puertos TCP trasladados en seis meses, convergencia inferior a un segundo, dos reversiones por problemas de aplicación y cero transacciones perdidas. Son cifras de su presentación, no registros de servicio auditados de forma independiente. La dirección 192.0.2.50 del diagrama está reservada para documentación por la RFC 5737. 10.100.0.254 pertenece al espacio privado de la RFC 1918. No son direcciones reales de un cliente.

La historia no demuestra que cualquier red pueda repetir el mismo desvío. Sí deja una decisión concreta: comprobar qué acción ejecuta cada equipo, limitar quién autoriza los destinos y conservar una reversión probada. El equipo pudo mover los puertos por separado porque mantuvo el resto del servicio en su sitio.

Fuentes: sesión de NANOG 98; diapositivas de Hervé Hildenbrand; RFC 8955; RFC 5737; RFC 1918.