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.
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.