Em cenários em que um data center se conecta a uma VPC por meio de vários virtual border routers (VBRs) associados a um transit router Enterprise Edition, configure uma política de roteamento para controlar a prioridade das rotas quando os VBRs estiverem na mesma região. Isso permite estabelecer uma configuração de rota ativa/em espera. O tráfego prioriza o link ativo e executa failover automático para o link em espera caso o link ativo seja desconectado.
Informações básicas
Conforme os princípios de prioridade de rota do transit router, se duas instâncias de VBR na mesma região estiverem conectadas a um transit router Enterprise Edition e anunciarem rotas para o mesmo bloco CIDR de destino com atributos idênticos, os VBRs formarão um link ECMP (equal-cost multipath routing). Consequentemente, o tráfego da VPC para o data center será distribuído entre ambas as instâncias de VBR.
No entanto, alguns planejamentos de rede ou dispositivos de gateway on-premises não suportam ECMP e exigem uma configuração ativa/em espera para acessar VPCs na nuvem. Essa limitação pode causar roteamento assimétrico, no qual o tráfego de ida e volta da VPC segue caminhos diferentes. Para evitar esse problema, modifique os atributos das rotas do seu data center no Alibaba Cloud e defina rotas ativas e em espera. Essa medida garante que o tráfego para o data center também utilize a configuração ativa/em espera, mantendo a simetria dos caminhos.
Com base na prioridade de rota do transit router, existem vários métodos para definir rotas ativas/em espera. Este tópico descreve como usar uma política de roteamento para controlar a prioridade das rotas do data center e encaminhar o tráfego por um link de VBR ativo/em espera.
Cenário de exemplo
O data center de uma empresa conecta-se ao Alibaba Cloud por dois circuitos Express Connect na região China (Hangzhou). Um transit router Enterprise Edition fornece comunicação de rede entre o data center e uma VPC. Como o planejamento de rede da empresa não suporta ECMP para acesso à VPC, é necessário configurar um link ativo/em espera para o tráfego entre o data center e a VPC. O tráfego deve priorizar o link ativo. Se o link ativo for desconectado, o tráfego deve executar failover automático para o link em espera. Após a restauração do link ativo, o tráfego deve retornar automaticamente a ele.
Neste cenário, tanto o VBR1 quanto o VBR2 usam rotas estáticas.
Pré-requisitos
Antes de começar, verifique se o data center está conectado ao Alibaba Cloud e se há comunicação entre o data center e a VPC. A tabela a seguir descreve os blocos CIDR e as configurações de rede deste cenário.
Procedimento
Etapa 1: Especificar rotas para o data center
-
Configure uma política de roteamento.
Configure uma política de roteamento para o transit router ao qual as instâncias de VBR estão associadas. Use a política para modificar atributos de rota e especificar as rotas ativas e em espera.
Faça login no console CEN (Cloud Enterprise Network). Na página CEN Instance, localize a instância CEN que contém o transit router e clique no ID da instância.
Na aba , clique no ID da instância do transit router ao qual os VBRs estão associados.
Na página de detalhes da instância do transit router, clique na aba Route Table. Na aba Route Maps, clique em Add Route Map.
-
Configure duas políticas de roteamento para especificar as rotas ativa e em espera para o data center. Mantenha os valores padrão para os demais parâmetros.
Política de roteamento 1
Política de roteamento 2
Para rotas da instância VBR1, defina a Route Priority como 10. Quanto menor o valor da Route Priority, maior a prioridade da rota.
Defina a Route Priority como 20 para rotas da instância VBR2. Isso configura as rotas do VBR2 como rotas em espera.
Policy Priority: 10.
Applied to Route Table: tabela de rotas do transit router.
Policy Direction: RegionIn.
Match Condition: Selecione Source Instance IDs e insira o ID da instância VBR1.
Policy Action: Selecione Allow.
Set Attributes: Clique em Add Action Object, selecione Route Priority e insira 10.
Policy Priority: 20.
Applied to Route Table: tabela de rotas do transit router.
Policy Direction: RegionIn.
Match Condition: Selecione Source Instance IDs e insira o ID da instância VBR2.
Policy Action: Selecione Allow.
Set Attributes: Clique em Add Action Object, selecione Route Priority e insira 20.
Após configurar as políticas de roteamento, acesse a aba Route Entry. O status das rotas da instância VBR2 mudará para Backup.
-
Configure uma verificação de integridade para as instâncias de VBR.
Para ativar o failover automático entre os links ativo e em espera, configure uma verificação de integridade para as instâncias de VBR no console CEN. Se a verificação de integridade da instância de VBR no link ativo falhar, o transit router alternará automaticamente o tráfego para o link em espera. Quando o link ativo for restaurado, o transit router retornará o tráfego automaticamente para o link ativo.
No painel de navegação à esquerda, clique em VBR Health Check.
Na página VBR Health Check, selecione a região onde as instâncias de VBR estão implantadas e clique em Add Health Check.
-
Configure verificações de integridade para o VBR1 e o VBR2. Mantenha os valores padrão para os demais parâmetros.
Verificação de integridade 1
Verificação de integridade 2
CEN Instance: Selecione a instância CEN à qual o transit router pertence.
Virtual Border Router (VBR): Selecione VBR1.
Source IP: Selecione Automatic IP Address.
Destination IP: Insira o Data Center Side IPv4 Address do VBR1.
Switch Route: Mantenha este recurso ativado.
CEN Instance: Selecione a instância CEN à qual o transit router pertence.
Virtual Border Router (VBR): Selecione VBR2.
Source IP: Selecione Automatic IP Address.
Destination IP: Insira o Data Center Side IPv4 Address do VBR2.
Switch Route: Mantenha este recurso ativado.
-
No data center, configure uma rota de retorno para a verificação de integridade do VBR.
Adicione uma entrada de rota no data center para o endereço IP de origem da verificação de integridade com máscara de sub-rede de 32 bits. O próximo salto da entrada de rota deve apontar para o circuito Express Connect correspondente. Caso contrário, os pacotes de sondagem da verificação de integridade (pings) não conseguirão retornar pelo caminho original, e o Alibaba Cloud poderá determinar incorretamente que o circuito Express Connect está indisponível.
-
(Opcional) Configure uma regra de alerta para a instância de VBR.
Quando uma verificação de integridade detecta falha de link, ela aciona automaticamente uma alternância de rota, mas não envia notificações. Recomendamos configurar também uma regra de alerta para a instância de VBR. Isso garante o recebimento de notificações caso ocorra falha em um circuito Express Connect.
Etapa 2: Especificar rotas para a VPC
O data center pode acessar a VPC pelo CPE1 ou pelo CPE2. Para garantir simetria nos caminhos de tráfego para a VPC e para o data center, especifique também rotas ativas e em espera para a VPC no data center. Configure o data center para priorizar o CPE1 no acesso à VPC. Também é necessário configurar verificações de integridade e failover de rota para assegurar que o data center use automaticamente o CPE2 para acessar a VPC se a conexão do CPE1 for desconectada. Após a restauração da conexão do CPE1, o data center deve retornar automaticamente ao uso do CPE1.
Etapa 3: Testar os links ativo/em espera
Após configurar as rotas ativa/em espera, use o recurso de simulação de falha do Express Connect para interromper o link primário e testar se os links ativo e em espera conseguem alternar automaticamente. Durante o teste, execute o comando traceroute -I <destination IP address> no cliente do data center e na instância ECS para rastrear o caminho do tráfego e verificar se a transmissão ocorre pelo caminho esperado.
O parâmetro
-Iindica que os pacotes de teste são enviados pelo protocolo ICMP. Certifique-se de que as regras de controle de acesso no data center e as regras do grupo de segurança do ECS permitam tráfego ICMP entre o segmento de rede do data center e o segmento de rede da VPC.O cliente do data center neste artigo utiliza o sistema operacional CentOS Stream 9 de 64 bits. Se o sistema operacional não suportar o comando
traceroute, instale-o antes de prosseguir.Caso o dispositivo não consiga rastrear o caminho do tráfego com o comando
traceroute, determine o caminho visualizando os gráficos de monitoramento da conexão VBR no console CEN.
Execute o comando
traceroute -I <target IP address>na instância ECS e no cliente do data center local, respectivamente, para visualizar o caminho atual de transmissão de tráfego.-
Acesse o console Express Connect e configure uma simulação de falha para desconectar o link ativo. Após o início da simulação, verifique os caminhos de tráfego na instância ECS e no cliente do data center. A tabela a seguir descreve as configurações da simulação de falha.
Region: Selecione Germany (Frankfurt).
Drill Resource: Selecione Virtual Border Router (VBR).
Instances: Selecione VBR1.
Drill Mode: Selecione Start Now.
Drill Duration: 5 minutos.
-
Após a conclusão da simulação de falha, o link ativo será restaurado automaticamente. Verifique novamente os caminhos de tráfego na instância ECS e no cliente do data center.
Os caminhos de tráfego de ida e volta para a VPC são simétricos. O tráfego prioriza o link ativo. Se o link ativo for desconectado, o tráfego executará failover automático para o link em espera. Quando o link ativo for restaurado, o tráfego retornará automaticamente ao link ativo. Pode ocorrer uma breve interrupção de tráfego durante a alternância de links.
Dispositivo
Caminho atual do tráfego
Link ativo desconectado
Link ativo restaurado
Cliente no data center
Execute o comando
tracerouteem um cliente no data center local, onde o segundo salto passa por10.99.0.2para alcançar o destino10.0.30.104:[e xxx ]$ traceroute -I 10.0.30.104 traceroute to 10.0.30.104 (10.0.30.104), 30 hops max, 60 byte packets 1 100.64.0.113 (100.64.0.113) 0.729 ms * * 2 10.99.0.2 (10.99.0.2) 0.513 ms 0.653 ms * 3 * * * 4 10.0.30.104 (10.0.30.104) 150.274 ms 150.269 ms 150.267 ms[exxxZ ~]$ traceroute -I 10.0.30.104 traceroute to 10.0.30.104 (10.0.30.104), 30 hops max, 60 byte packets 1 100.64.0.129 (100.64.0.129) 0.636 ms 0.845 ms 1.120 ms 2 10.1.0.1 (10.1.0.1) 0.526 ms 0.675 ms 0.809 ms 3 * * * 4 10.0.30.104 (10.0.30.104) 150.429 ms 150.427 ms 150.424 msApós a restauração do link primário, execute
tracerouteem um cliente no IDC local. O segundo salto passa novamente por10.99.0.2, indicando que o tráfego retornou ao link primário.[exxx ~]$ traceroute -I 10.0.30.104 traceroute to 10.0.30.104 (10.0.30.104), 30 hops max, 60 byte packets 1 100.64.0.113 (100.64.0.113) 0.765 ms 1.041 ms 1.220 ms 2 10.99.0.2 (10.99.0.2) 0.524 ms 0.804 ms 0.961 ms 3 * * * 4 10.0.30.104 (10.0.30.104) 150.156 ms 150.153 ms 150.150 msInstância ECS
Ao executar o comando traceroute em uma instância ECS para testar o link, o quarto salto mostra um endereço de próximo salto de
10.99.0.1, o que indica que o tráfego passa por este nó para alcançar o endereço de destino.~]$ traceroute -I 192.168.10.135 traceroute to 192.168.10.135 (192.168.10.135), 30 hops max, 60 byte packets 1 * * * 2 100.64.0.145 (100.64.0.145) 150.614 ms 150.947 ms 151.166 ms 3 100.64.0.145 (100.64.0.145) 151.386 ms 151.658 ms 151.894 ms 4 10.99.0.1 (10.99.0.1) 150.482 ms 150.563 ms 150.657 ms 5 192.168.10.135 (192.168.10.135) 150.399 ms 150.396 ms 150.393 msExecute o comando traceroute na instância ECS. O endereço do quarto salto muda para
10.1.0.2, indicando que o tráfego executou failover para o link em espera.~]$ traceroute -I 192.168.10.135 traceroute to 192.168.10.135 (192.168.10.135), 30 hops max, 60 byte packets 1 * * * 2 100.64.0.225 (100.64.0.225) 151.232 ms 151.230 ms 151.529 ms 3 100.64.0.225 (100.64.0.225) 151.762 ms 151.994 ms 152.374 ms 4 10.1.0.2 (10.1.0.2) 150.702 ms 150.699 ms 150.696 ms 5 192.168.10.135 (192.168.10.135) 150.692 ms 150.691 ms 150.688 msApós restaurar a VPC primária, execute o comando traceroute na instância ECS. O quarto salto retorna para
10.99.0.1, o que indica que o tráfego retornou ao link primário.~]$ traceroute -I 192.168.10.135 traceroute to 192.168.10.135 (192.168.10.135), 30 hops max, 60 byte packets 1 * * * 2 100.64.0.145 (100.64.0.145) 150.959 ms 151.269 ms 151.626 ms 3 100.64.0.145 (100.64.0.145) 151.858 ms 152.054 ms 152.276 ms 4 10.99.0.1 (10.99.0.1) 150.849 ms 150.891 ms 151.028 ms 5 192.168.10.135 (192.168.10.135) 150.738 ms 150.734 ms 150.732 ms
Perguntas frequentes
Rotas ativa/em espera para transit routers Basic Edition
Também é possível seguir as etapas deste tópico para configurar rotas ativa/em espera em um transit router Basic Edition. A interface do console para um transit router Basic Edition pode diferir da interface de um transit router Enterprise Edition. Para mais informações, consulte a documentação relevante.
Se não for possível usar o comando traceroute para rastrear o caminho do tráfego, visualize os gráficos de monitoramento da instância de VBR no console Express Connect para identificar o caminho do tráfego.