Migrar para um novo circuito ExpressRoute

Se quiser mudar de um circuito ExpressRoute para outro, pode fazê-lo de forma suave e com interrupções mínimas no serviço. Este documento orienta-o pelos passos para migrar o seu tráfego de produção sem causar grandes perturbações ou riscos. Este método aplica-se quer esteja a mudar para um local de peering novo quer para o mesmo local de peering.

Se tiver o seu circuito ExpressRoute através de um fornecedor de serviços de Camada 3, crie o novo circuito na sua subscrição no portal Azure. Trabalhe com o seu fornecedor de serviços para transferir o tráfego de forma fluida para o novo circuito. Depois de o fornecedor de serviços desprovisionar o seu circuito antigo, apague-o do portal do Azure.

O resto do artigo aplica-se caso tenha o seu circuito ExpressRoute através de um prestador de serviços de Camada 2 ou de portas diretas do ExpressRoute.

Passos para uma migração sem problemas do circuito ExpressRoute

Diagrama mostrando uma migração de circuito ExpressRoute do Circuito A para o Circuito B.

O diagrama anterior ilustra o processo de migração de um circuito ExpressRoute existente, referido como Circuito A, para um novo circuito ExpressRoute, denominado Circuito B. O Circuito B pode estar na mesma ou numa localização de peering diferente do Circuito A. O processo de migração consiste nos seguintes passos:

  1. Implementar o Circuito B isoladamente: Enquanto o tráfego continuar a fluir sobre o Circuito A, implemente um novo Circuito B sem afetar o ambiente de produção.

  2. Bloqueie o fluxo de tráfego de produção sobre o Circuito B: Evite que qualquer tráfego utilize o Circuito B até que este seja totalmente testado e validado.

  3. Completar e validar a conectividade de ponta a ponta do Circuito B: Garantir que o Circuito B consegue estabelecer e manter uma ligação estável e segura com todos os pontos finais necessários.

  4. Comutar o tráfego: Redirecionar o fluxo de tráfego do Circuito A para o Circuito B e bloquear o fluxo de tráfego sobre o Circuito A.

  5. Desmantelamento do Circuito A: Remover o Circuito A da rede e libertar os seus recursos.

Implantar o novo circuito isoladamente

Para uma substituição semelhante que preserve o nível de resiliência do circuito existente, selecione a opção de Resiliência Padrão e siga os passos descritos no guia Criar um circuito com o ExpressRoute para criar o seu novo circuito ExpressRoute (Circuito B) na localização de peering desejada. A resiliência padrão é uma configuração de local único e não é recomendada para cargas de trabalho empresariais ou críticas. Se estás a migrar uma carga de trabalho desse tipo, avalia antes a resiliência Alta ou Máxima. Para mais informações, consulte Concepção e arquitetura do Azure ExpressRoute para garantir resiliência. Depois, siga os passos em Configurar peering para circuito ExpressRoute para configurar os tipos de peering necessários: privado e Microsoft.

Para evitar que o tráfego de produção do peering privado utilize o Circuito B antes de o testar e validar, não ligue um gateway de rede virtual com uma implementação em produção ao Circuito B. De forma semelhante, para evitar que o tráfego de produção do peering da Microsoft utilize o Circuito B, não associe um filtro de rotas ao Circuito B.

Bloquear o fluxo de tráfego de produção sobre o circuito recém-criado

Evite o anúncio da rota através de uma ou mais novas ligações de peering nos dispositivos CE.

No Cisco IOS, pode usar um route-map e um prefix-list para filtrar as rotas anunciadas numa sessão de peering BGP. O exemplo seguinte mostra como criar e aplicar a route-map e a prefix-list para este fim:

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32

router bgp <your_AS_number>
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS out
 neighbor <neighbor_IP_address> route-map BLOCK-ADVERTISEMENTS in

Utilize a política de exportação/importação para filtrar as rotas anunciadas e recebidas na nova sessão de peering nos dispositivos Junos. O exemplo seguinte mostra como configurar a política de exportação/importação para este fim:

user@router>show configuration policy-options policy-statement BLOCK-ALL-ROUTES

term reject-all {

    the reject;
}

protocols {
    bgp {
        group <your_group_name> {
            neighbor <neighbor_IP_address> {
                export [ BLOCK-ALL-ROUTES ];
                import [ BLOCK-ALL-ROUTES ];
            }
        }
    }
}

Validar a conectividade de ponta a ponta do circuito recém-criado

Peering privado

Para ligar o novo circuito ao gateway de uma rede virtual de teste e verificar a sua conectividade privada de peering, siga os passos em Ligar uma rede virtual a um circuito ExpressRoute . Depois de associar as redes virtuais ao circuito, verifique a tabela de rotas do peering privado para se certificar de que o espaço de endereçamento da rede virtual está incluído. O exemplo seguinte mostra uma tabela de rotas do peering privado de um circuito ExpressRoute no portal de Gestão do Azure:

Captura de ecrã da tabela de rotas do elo principal do circuito ExpressRoute.

O diagrama seguinte ilustra uma VM de teste numa rede virtual de teste e um dispositivo de teste local usado para verificar a conectividade através do peering privado ExpressRoute.

Diagrama que mostra uma VM no Azure a comunicar com um dispositivo de teste local através da ligação ExpressRoute.

Modificar o mapa de rotas ou a configuração da política para filtrar as rotas anunciadas e permitir o endereço IP específico do dispositivo de teste local. De forma semelhante, permita o espaço de endereçamento da rede virtual de teste a partir do Azure.

route-map BLOCK ADVERTISEMENTS permit 5
 match ip address prefix-list PERMIT-ROUTE

route-map BLOCK ADVERTISEMENTS deny 10
 match ip address prefix-list BLOCK-ALL-PREFIXES

ip prefix-list PERMIT-ROUTE seq 10 permit 10.17.1.0/24
ip prefix-list PERMIT-ROUTE seq 20 permit 10.1.18.10/32

ip prefix-list BLOCK-ALL-PREFIXES seq 10 deny 0.0.0.0/0 le 32


Para permitir prefixos IP específicos para dispositivos de teste no Junos, configure uma lista de prefixos. Depois, configura a política de importação/exportação do BGP para permitir estes prefixos e rejeitar tudo o resto.

user@router>show configuration policy-options policy-statement BLOCK-ADVERTISEMENTS

term PERMIT-ROUTES {
    from {
        prefix-list PERMIT-ROUTE;
    }
    then accept;
}

term reject-all {
    then reject;
}

user@router>show configuration policy-options prefix-list PERMIT-ROUTE

10.1.18.10/32;
10.17.1.0/24;

Verifique a conectividade de ponta a ponta através do peering privado. Por exemplo, pode fazer ping à VM de teste no Azure a partir do seu dispositivo de teste local e verificar os resultados. Para validação detalhada passo a passo, consulte Verificação da conectividade ExpressRoute.

Microsoft Peering

A verificação do seu peering Microsoft requer um planeamento cuidadoso para evitar afetar o tráfego de produção. Siga estes passos para garantir um processo fluido:

  1. Utilize Prefixos Distintos: Configure o peering da Microsoft para o Circuito B com prefixos diferentes dos utilizados para o Circuito A, para evitar conflitos de roteamento. Consulte a criação de peering Microsoft para obter orientações.
  2. Filtros de Rota Separados: Associe o peering da Microsoft do Circuito B a um filtro de rota diferente do Circuito A. Siga os passos em configurar filtros de rota para o peering da Microsoft.
  3. Evite rotas comuns: Certifique-se de que os filtros de rotas para ambos os circuitos não partilham rotas comuns para evitar roteamentos assimétricos. Isto pode ser feito através de:
    • Selecionar um serviço ou região Azure para testar o Circuito B que não seja usado pelo tráfego de produção do Circuito A.
    • Minimizar a sobreposição entre os dois filtros de rota e permitir apenas pontos terminais públicos de teste específicos via Circuito B.

Depois de ligar um filtro de rotas, verifique as rotas anunciadas e recebidas através do peering BGP no dispositivo CE. Modificar o mapa de rotas ou a configuração da política Junos para filtrar as rotas anunciadas, permitindo apenas os prefixos on-premises do peering da Microsoft e endereços IP específicos dos endpoints públicos da Microsoft selecionados para testes.

Para testar a conectividade aos endpoints do Microsoft 365, siga os passos em Implementar o ExpressRoute para Microsoft 365 – Construa os seus procedimentos de teste. Para endpoints públicos do Azure, comece com testes básicos de conectividade, como traceroute a partir do ambiente on-premises, para garantir que os pedidos seguem através de endpoints do ExpressRoute. Para além dos endpoints ExpressRoute, as mensagens ICMP são suprimidas na rede Microsoft. Adicionalmente, testar a conectividade ao nível da aplicação. Por exemplo, se tiver uma VM Azure com um IP público a correr um servidor web, tente aceder ao IP público do servidor web a partir da sua rede local através da ligação ExpressRoute. Isto confirma que tráfego complexo, como pedidos HTTP, pode chegar aos serviços do Azure.

Peering privado

  1. Desligue o Circuito B de quaisquer gateways virtuais de rede de teste.
  2. Remova quaisquer exceções feitas à política de route-maps da Cisco ou Junos.
  3. Ligue o Circuito B ao gateway de rede virtual de produção seguindo os passos em Ligar uma rede virtual a um circuito ExpressRoute.
  4. Certifique-se de que o Circuito B está pronto para anunciar todas as rotas atualmente anunciadas através do Circuito A. Verifique se as interfaces do Circuito B estão associadas à VRF ou à instância de encaminhamento adequadas.
  5. Remover os mapas de rotas ou a política nas interfaces do Circuito B e aplicá-los às interfaces do Circuito A para bloquear anúncios de rota sobre o Circuito A, mudando o fluxo de tráfego para o Circuito B.
  6. Verifique o fluxo de tráfego no Circuito B. Se a verificação falhar, reverta as alterações e volte a mudar o fluxo de tráfego para o Circuito A.
  7. Se a verificação for bem-sucedida, elimine o Circuito A.

Microsoft Peering

  1. Remova o Circuit B de qualquer filtro de rotas do Azure de teste.
  2. Remover quaisquer exceções feitas aos mapas de rota ou à política.
  3. Certifique-se de que as interfaces do Circuito B estão associadas ao VRF ou routing-instance adequado.
  4. Valide e confirme os prefixos anunciados através do peering da Microsoft.
  5. Associe o Microsoft peering do Circuito B ao filtro de rotas do Azure atualmente associado ao Circuito A.
  6. Remover os mapas de rotas ou a política de exportação/importação nas interfaces do Circuito B e aplicá-los às interfaces do Circuito A para bloquear anúncios de rota sobre o Circuito A, mudando o fluxo de tráfego para o Circuito B.
  7. Verifique o fluxo de tráfego no Circuito B. Se a verificação falhar, reverta as alterações e volte a mudar o fluxo de tráfego para o Circuito A.
  8. Se a verificação for bem-sucedida, elimine o Circuito A.

Passo seguinte

Para mais informações sobre a configuração do router, consulte Exemplos de configuração do router para configurar e gerir o encaminhamento.