Sobre a migração em tempo real

A migração em tempo real permite controlar o anúncio do BGP dos prefixos delegados públicos regionais v1. A migração em tempo real não está disponível por padrão. Para solicitar acesso, entre em contato com o engenheiro de clientes do Google Cloud.

Para novas configurações, recomendamos criar um prefixo público anunciado v2, que permite criar prefixos delegados públicos regionais que são provisionados mais rapidamente e oferecem melhores sobre o aviso do BGP.

Para mais informações sobre a diferença entre os prefixos delegados públicos v1 e v2, consulte Usar suas próprias configurações de IP.

Migração em tempo real

A migração em tempo real é um recurso eficiente que requer planejamento e execução detalhados.

Use a migração em tempo real para importar um prefixo BYOIP quando qualquer parte do prefixo já for anunciada publicamente. Importar um prefixo anunciado sem usar a migração em tempo real pode causar roteamento inesperado e perda de pacotes.

A migração em tempo real tem disponibilidade limitada. Entre em contato com seu Engenheiro de clientes do Google Cloud para ter acesso antes de criar um prefixo de delegação público com a migração em tempo real ativada.

Você ativa a migração em tempo real ao criar um prefixo delegado público. Para impedir que o Google divulgue o prefixo público anunciado para os pares, você precisa garantir o seguinte:

  • Todos os prefixos delegados públicos no prefixo público público são configurados com escopo regional, não escopo global. Consulte as recomendações de migração em tempo real para mais informações.

  • Nenhum endereço IP no intervalo do prefixo público público é atribuído aos recursos.

A Figura 2 exibe o mesmo projeto com configurações diferentes. Uma delas impede que o prefixo seja divulgado e duas que fazem com que o prefixo público divulgado seja anunciado.

Figura 2. Divulgação de prefixo público durante a migração em tempo real (clique para ampliar).

A Figura 2 ilustra os seguintes cenários:

  • No primeiro exemplo de projeto, todos os prefixos públicos delegados no prefixo público divulgado são configurados com a migração em tempo real ativada. Nenhuma VM é configurada com endereços IP desse prefixo.

    Resultado: o prefixo público divulgado não é divulgado.

  • No segundo exemplo de projeto, todos os prefixos públicos delegados no prefixo público divulgado são configurados com a migração em tempo real ativada. Uma VM é configurada com um endereço IP desse prefixo.

    Resultado: o prefixo público divulgado é divulgado.

  • No terceiro exemplo de projeto, um prefixo público delegado dentro do prefixo público divulgado não é configurado com a migração em tempo real ativada. Nenhuma VM é configurada com endereços IP desse prefixo.

    Resultado: o prefixo público divulgado é divulgado.

Você controla quando a divulgação começa atribuindo endereços IP do seu prefixo delegado público aos recursos do Google Cloud. Para mais informações, consulte Usar a migração em tempo real.

Depois que a migração em tempo real for concluída, entre em contato com seu Engenheiro de clientes do Google Cloud para que ele possa desativar a migração em tempo real para seu prefixo. Por padrão, a migração em tempo real é desativada 30 dias após o início da divulgação do prefixo anunciado público. Se você precisar disponibilizar a opção de migração em tempo real por mais de 30 dias, entre em contato com o engenheiro de clientes.

Limitações da migração em tempo real

Ao planejar uma migração em tempo real, é importante que você entenda os seguintes requisitos e limitações:

  • Não será possível criar um prefixo de delegação público com a migração em tempo real ativada se o escopo estiver definido como global. Para mais informações sobre como gerenciar a migração em tempo real de recursos globais, consulte recomendações de migração em tempo real.

  • O prefixo mais longo que pode ser migrado é um /24 porque /24 é o tamanho máximo do prefixo roteável na Internet.

  • Não suponha que todos os colegas do Google respeitem o prefixo mais longo entre dois sites. Talvez alguns pares não tenham tabelas de roteamento completas. Como resultado, um prefixo menor anunciado pelo Google para esses pares é o único prefixo (e, portanto, o mais longo) que o peer vê. Como resultado, a existência de qualquer prefixo do Google tem precedência, mesmo que você esteja anunciando uma rota mais específica do seu local.

    Exemplo:

    Um cliente tem um /23 que é ativamente roteado do local onde está. O cliente planeja desagregar o /23 em dois prefixos /24 e anunciar as rotas mais específicas do local local. Depois da desagregação, eles planejam configurar um prefixo público de /23 divulgado para BYOIP. Elas presumem que as rotas mais específicas do local no local têm precedência sobre o prefixo mais curto de BYOIP e que o tráfego continua roteando para os prefixos locais mais específicos.

    Infelizmente, este plano só funciona parcialmente:

    • Os pares do Google que têm tabelas de roteamento completas preferem os prefixos locais /24 mais específicos.

    • Os pares do Google que não têm tabelas de roteamento completas preferem o prefixo divulgado publicamente do Google, já que as tabelas de roteamento deles não incluem os prefixos mais específicos.

  • Seu tráfego não será entregue se o Google receber tráfego para um prefixo público anunciado válido para o qual você não provisionou serviços, mesmo que haja um anúncio local ativo para o prefixo.

    Exemplo:

    Um cliente tem uma rede local com dois prefixos /24. O prefixo anunciado público é o /23 agregado.

    O cliente migra um único /24 para o Google e remove o prefixo local, mas deixa o outro /24 ativo no local.

    Essa configuração resulta em parte do roteamento de tráfego para o Google por todo o prefixo /23, mesmo que ainda haja um prefixo /24 mais específico anunciado do local local. É difícil diagnosticar esse cenário, porque vários sistemas autônomos enviam tráfego ao seu local, mas outros passam ao Google e, nesse caso, o tráfego é descartado.

Recomendações de migração em tempo real

Como prática recomendada, siga estas recomendações ao usar a migração em tempo real.

  • Divida todos os prefixos de migração em tempo real nos prefixos mais longos que reflitam como você quer anunciar esses prefixos durante a migração. Nos exemplos anteriores, o /23 precisa ser desagregado em dois prefixos /24 e anunciado como no local local antes de criar o prefixo público anunciado.

  • Crie solicitações de ROA de tamanho de prefixo exato e não dependa do parâmetro de tamanho máximo a ser respeitado.

  • Certifique-se de que as solicitações ROA RPKI existem para ASN de origem local e ASN de origem do Google. Se não houver ROA para o prefixo local, a criação de uma ROA de origem do Google poderá fazer com que os ISPs de terceiros filtrem esses prefixos locais, caso estejam usando a filtragem de RPKI automática.

  • Crie prefixos públicos anunciados separados para recursos globais e recursos regionais se você precisar usar a migração em tempo real. Quando você ativa a migração em tempo real em um prefixo de delegação pública, precisa especificar uma região para o escopo. A especificação do escopo global para um prefixo de delegação pública com a migração em tempo real ativada não é compatível. Se você criar um prefixo delegado público com escopo global e migração em tempo real ativada, o prefixo será imediatamente anunciado.

    Ter prefixos regionais em um prefixo divulgado público e prefixos globais em outro prefixo anunciado permite que você os gerencie separadamente. É possível gerenciar a migração em tempo real dos recursos regionais e entrar em contato com seu Engenheiro de clientes do Google Cloud para gerenciar a migração em tempo real dos recursos globais.

A seguir