Acerca de la migración en vivo
La migración en vivo te permite controlar el anuncio de BGP de los prefijos públicos delegados regionales v1. La migración en vivo no está disponible de forma predeterminada. Para solicitar acceso, comunícate con tu Ingeniero de Atención al cliente de Google Cloud.
Para las configuraciones nuevas, te recomendamos que crees un prefijo anunciado público v2, que te permita crear prefijos públicos delegados regionales que aprovisionen más rápido y te ayuden mejor control sobre el anuncio de BGP.
Para obtener más información sobre la diferencia entre los prefijos delegados públicos v1 y v2, consulta Usa tus propias configuraciones de IP.
Migración en vivo
La migración en vivo es una función potente que requiere una planificación y una ejecución detalladas.
Usa la migración en vivo para importar un prefijo BYOIP cuando alguna parte del prefijo ya se anuncia de forma pública. La importación de un prefijo anunciado sin usar la migración en vivo puede provocar un enrutamiento inesperado y una pérdida de paquetes.
La migración en vivo tiene disponibilidad limitada. Comunícate con tu Ingeniero de Atención al cliente de Google Cloud para obtener acceso antes de crear un prefijo público delegado con la migración en vivo habilitada.
Habilita la migración en vivo cuando creas un prefijo delegado público. Para evitar que Google anuncie el prefijo anunciado público a sus pares, debes asegurarte de lo siguiente:
Todos los prefijos delegados públicos dentro del prefijo público anunciado se configuran con un alcance regional, no con un alcance global. Consulta las recomendaciones de la migración en vivo para obtener más información.
No se asignan direcciones IP en el rango del prefijo anunciado público a los recursos.
En la Figura 2, se muestra el mismo proyecto con diferentes configuraciones, una de las cuales evita que se anuncie el prefijo, y otras dos que hacen que se anuncie el prefijo anunciado público.
En la figura 2, se ilustran las siguientes situaciones:
En el primer ejemplo de proyecto, todos los prefijos delegados públicos del prefijo público anunciado se configuran con la migración en vivo habilitada. No se configuró ninguna VM con direcciones IP de este prefijo.
Resultado: El prefijo público anunciado no se anunció.
En el segundo ejemplo de proyecto, todos los prefijos delegados públicos del prefijo público anunciado se configuran con la migración en vivo habilitada. Una VM se configuró con una dirección IP de este prefijo.
Resultado: El prefijo público anunciado se anunció.
En el tercer ejemplo de proyecto, un prefijo delegado público dentro del prefijo público anunciado no se configuró con la migración en vivo habilitada. No se configuró ninguna VM con direcciones IP de este prefijo.
Resultado: El prefijo público anunciado se anunció.
Puedes controlar cuándo comienza el anuncio si asignas direcciones IP del prefijo delegado público a los recursos de Google Cloud. Para obtener más información, consulta Usa la migración en vivo.
Después de completar la migración en vivo, comunícate con tu Ingeniero de Atención al cliente de Google Cloud para que pueda inhabilitar la migración en vivo para tu prefijo. De forma predeterminada, la migración en vivo se inhabilita 30 días después de que comiences a anunciar el prefijo público anunciado. Si necesitas que la opción de migración en vivo esté disponible durante más de 30 días, comunícate con tu Ingeniero de Atención al cliente.
Limitaciones de la migración en vivo
Cuando planificas una migración en vivo, es importante que comprendas los siguientes requisitos y limitaciones:
La creación de un prefijo público delegado con la migración en vivo habilitada no es compatible si el alcance está configurado como global. Consulta Recomendaciones para la migración en vivo para obtener información sobre cómo administrar la migración en vivo para recursos globales.
El prefijo más largo que se puede migrar es un
/24porque/24es la longitud máxima del prefijo enrutable en Internet.No supongas que todos los intercambios de tráfico de Google respetan el prefijo más largo entre dos sitios. Es posible que algunos intercambios de tráfico no tengan tablas de enrutamiento completo. Como resultado, un prefijo más corto que Google anuncia en estos intercambios de tráfico es el único prefijo (y, por lo tanto, el más largo) que el intercambio de tráfico considera. Como resultado, la existencia de cualquier prefijo de Google tiene prioridad, incluso si anuncias una ruta más específica desde tu ubicación local.
Por ejemplo:
Un cliente tiene un
/23que se enruta de forma activa desde su ubicación local. El cliente planea dividir/23en dos prefijos/24y anunciar las rutas más específicas desde su ubicación local. Después de la separación, planean configurar un prefijo público anunciado/23para BYOIP. Suponemos que las rutas más específicas de su ubicación local tienen prioridad sobre el prefijo BYOIP más corto y que el tráfico continúa enrutando a los prefijos locales más específicos.Lamentablemente, este plan funciona solo de forma parcial:
Los intercambios de tráfico de Google que tienen tablas de enrutamiento completas prefieren los prefijos locales
/24más específicos.Los pares de Google que no tienen tablas de enrutamiento completas prefieren el prefijo anunciado público, anunciado desde Google, ya que sus tablas de enrutamiento no incluyen los prefijos más específicos.
Tu tráfico no se entrega si Google recibe tráfico para un prefijo anunciado público para el que no aprovisionaste servicios, incluso si hay un anuncio local activo para el prefijo.
Por ejemplo:
Un cliente tiene una red local que consta de dos prefijos
/24. Su prefijo público anunciado es el/23agregado.El cliente migra un solo
/24a Google y retira el prefijo local, pero deja el otro/24activo en la ubicación local.Esta configuración da como resultado que parte del tráfico se enrute a Google para todo el prefijo
/23, aunque aún haya un prefijo/24más específico anunciado desde la ubicación local. Esta situación es difícil de diagnosticar, ya que varios sistemas autónomos usan el tráfico hacia tu ubicación local, pero otros entregan a Google, en cuyo caso el tráfico se descarta.
Recomendaciones para la migración en vivo
Como práctica recomendada, sigue estas recomendaciones cuando uses la migración en vivo.
Desagrega todos los prefijos de migración en vivo en los prefijos más largos que reflejan cómo deseas anunciar estos prefijos durante la migración. En los ejemplos anteriores, el
/23debe estar desagregado en dos prefijos/24y debe anunciarse como su ubicación local antes de crear el prefijo anunciado público.Crea solicitudes ROA con una longitud exacta del prefijo y no confíes en el parámetro de longitud máxima que se debe respetar.
Asegúrate de que existen las solicitudes ROA de RPKI para el ASN de origen local y el ASN de origen de Google. Si no hay ROA para el prefijo local, la creación de un ROA de origen de Google puede provocar que los ISP de terceros filtren esos prefijos locales si usan el filtrado RPKI automático.
Crea prefijos anunciados públicos para recursos globales y recursos regionales si necesitas usar la migración en vivo. Cuando habilitas la migración en vivo en un prefijo delegado público, debes especificar una región para el permiso. No se admite la especificación de permiso global para un prefijo delegado público que tenga habilitada la migración en vivo. Si creas un prefijo anunciado público con permiso global y migración en vivo habilitada, el prefijo se anuncia de inmediato.
Tener prefijos regionales en un prefijo anunciado público y prefijos globales en otro prefijo anunciado público te permite administrarlos por separado. Puedes administrar la migración en vivo de los recursos regionales y comunicarte con tu Ingeniero de Atención al cliente de Google Cloud para administrar la migración en vivo de los recursos globales.