Cloud Enterprise Network:Roteamento baseado em políticas

Cenário A: Roteamento de tráfego por IP de origem

• Pré-requisito: Duas sub-redes no mesmo vSwitch precisam enviar tráfego para o mesmo IDC de destino em 10.1.0.0/16, mas por meio de Virtual Border Routers (VBRs) diferentes: VBR-A e VBR-B.

• Configuração: Para este cenário, crie duas regras de PBR. Cada regra corresponde ao CIDR de origem de uma sub-rede e direciona seu tráfego para a tabela de rotas associada ao VBR correspondente.

• Avançado: Ao usar ECMP em conexões privadas duplas, utilize o atributo AsPathPrepend em uma política de rotas (RouteMap) do Cloud Enterprise Network (CEN) para garantir caminhos de retorno simétricos.

Cenário B: Caminhos ativo-em espera no nível da sub-rede

• Pré-requisito: Uma única VPC contém duas sub-redes. Duas conexões privadas, A e B, estão conectadas a um Transit Router (TR). A sub-rede A deve usar a conexão privada A como caminho principal e a B como espera, enquanto a sub-rede B deve usar a B como principal e a A como espera.

• Configuração: Em seguida, crie duas tabelas de rotas, vtb-a-primary e vtb-b-primary. Em cada tabela de rotas, use um RouteMap para reduzir a prioridade da rota que aponta para o VBR oposto. Em seguida, use o PBR para direcionar o tráfego de cada sub-rede para sua respectiva tabela de rotas principal.

• Avançado: Se o link principal falhar, o BGP converge automaticamente para o caminho em espera. O tráfego de retorno simétrico depende de RouteMaps bidirecionais.

Cenário C: Inserção de service para tráfego entre VPCs

• Pré-requisito: Um Cloud Firewall está conectado ao TR como um attachment e possui sua própria tabela de rotas dedicada, vtb-firewall.

• Configuração: No attachment da VPC de origem, vincule uma tabela de rotas de políticas. Para isso, crie uma regra com as condições de correspondência SourceCidr=10.0.1.0/24, DestinationCidr=10.0.0.0/8 e defina o destino como vtb-firewall. O tráfego que não corresponder a essa regra segue a tabela de rotas padrão.

• Nota: Como o firewall é stateful, o tráfego de retorno também precisa passar por ele. Para isso, vincule uma tabela de rotas de políticas semelhante ao attachment par ou associe o attachment par a uma tabela de rotas que direcione o tráfego pelo firewall.

Cenário D: Isolamento de caminho para múltiplos tenants

• Pré-requisito: Vários tenants compartilham a mesma VPC e o mesmo vSwitch. Cada tenant precisa acessar seu próprio IDC por meio de um túnel IPsec dedicado.

• Configuração: Associe o attachment IPsec de cada tenant a uma tabela de rotas separada. Use o PBR para mapear o tráfego do segmento de rede de origem de cada tenant para a tabela de rotas correspondente.

Cenário E: Egresso zonal para arquiteturas ativo-ativo

• Pré-requisito: Sub-redes em diferentes zonas de disponibilidade (AZs) e seus respectivos pontos de egresso de conexão privada local estão configurados como attachments separados. Por exemplo, 10.1.1.0/24 → att-vbr-az1 e 10.1.2.0/24 → att-vbr-az2.

• Configuração: Atribua uma tabela de rotas separada para o ponto de egresso de cada AZ. Use o PBR para mapear o tráfego da sub-rede de cada AZ para sua tabela de rotas de egresso correspondente. Isso impede que o ECMP faça o balanceamento de carga do tráfego entre diferentes AZs.

• Avançado: Para failover, você pode pré-configurar rotas de fallback entre AZs em uma tabela de rotas em espera. Isso mantém a disponibilidade do service durante uma interrupção, ainda que com desempenho potencialmente degradado.

Cenário F: Canal dedicado para auditoria de conformidade

• Pré-requisito: O tráfego de saída da sub-rede DMZ 10.2.0.0/24 deve ser roteado por um canal de auditoria. O appliance de auditoria está conectado como um attachment e associado à tabela de rotas vtb-audit.

• Configuração: Para isso, crie uma regra de PBR que corresponda ao segmento de rede de origem da DMZ e encaminhe seu tráfego para a tabela de rotas vtb-audit. O tráfego de outras sub-redes sem uma política vinculada ou uma regra correspondente é encaminhado de acordo com a tabela de rotas padrão.

• Nota: A auditoria inline é semelhante a um firewall stateful e exige roteamento simétrico. A auditoria espelhada (out-of-band) tem impacto mínimo no tráfego de retorno.

Cenário G: Coloração de tráfego para canary releases

• Pré-requisito: Uma sub-rede canary (10.3.100.0/24) e uma sub-rede de produção compartilham a mesma VPC. O cluster de backend para o ambiente canary se conecta por meio de um attachment separado, associado à tabela de rotas vtb-gray.

• Configuração: Primeiro, crie uma regra de PBR: SourceCidr=10.3.100.0/24 → vtb-gray. Defina sua prioridade como inferior à de quaisquer regras de segurança ou conformidade.

• Nota: A camada de rede apenas determina o caminho do tráfego. A lógica no nível da aplicação ainda precisa gerenciar a troca de versões e rollbacks.

Processo de correspondência de tráfego

Quando o tráfego entra em um attachment, o sistema o avalia em relação à tabela de rotas de políticas antes de consultar uma tabela de rotas para encaminhamento:

1. Um pacote entra em um attachment.

2. O sistema verifica se uma tabela de rotas de políticas está vinculada ao attachment.

   • Se sim, prossiga para a etapa 3.

   • Se não, pule para a etapa 6.

3. O sistema avalia o pacote em relação às regras na tabela de rotas de políticas em ordem de prioridade.

4. O sistema verifica se o pacote corresponde a uma regra.

   • Se sim, prossiga para a etapa 5.

   • Se não, pule para a etapa 6.

5. O sistema consulta o destino na tabela de rotas do TR de destino especificada pela regra e, em seguida, pula para a etapa 7.

6. O sistema consulta o destino na tabela de rotas do TR vinculada por Associated forwarding.

7. O pacote é encaminhado para o próximo salto.

Princípios principais:

• Avaliação baseada em prioridade: As regras são avaliadas em ordem de prioridade (valor menor = prioridade maior). A primeira regra correspondente é aplicada e a avaliação é interrompida.

• Correspondência e encaminhamento desacoplados: Uma tabela de rotas de políticas apenas determina qual tabela de rotas usar. A tabela de rotas selecionada resolve o próximo salto.

• Controle de ingresso: Uma tabela de rotas de políticas é vinculada a um attachment e afeta apenas o tráfego que entra no TR por meio desse attachment específico.

Campos de correspondência de regras

Cada regra contém os seguintes campos:

Siga estas três etapas:

1. Primeiro, crie uma Policy-Based Routing Table.

   Clique no ID do TR e acesse sua página de detalhes. Mude para a aba Policy-Based Routing Table e clique em Create Policy-Based Routing Table.

2. Adicione Policy-Based Routes.

   1. Na coluna Actions da tabela de rotas de políticas que você acabou de criar, clique em View Rules e visualize as regras.

   2. No painel Policy-Based Routing Table Details, na aba Policy-Based Routes, clique em Add Policy Routing Rule.

   3. Na caixa de diálogo Add Policy Routing Rule, configure as seguintes definições:

      • Match Condition: Configure conforme listado em Rule matching fields.

      • Priority: 1 a 100. Um valor menor indica maior prioridade.

      • Forwarding Target Route Table: A tabela de rotas a ser usada se o tráfego corresponder à regra.

   Você pode adicionar várias regras a uma tabela.

3. Vincule a Policy-Based Routing Table a um Network Instances:.

   1. Na coluna Actions da tabela de rotas de políticas, clique em Manage.

   2. No painel Policy-Based Routing Table Details, na aba Associate Network Instance Connection, conclua a vinculação.

Após vincular a tabela, o sistema primeiro avalia o tráfego que entra no attachment em relação às Policy-Based Routes:

• Se o tráfego corresponder a uma regra, o sistema o encaminha com base na tabela de rotas de destino especificada.

• Se o tráfego não corresponder a nenhuma regra, o sistema o encaminha com base na tabela de rotas configurada para Associated forwarding.

Cotas e limites

Cotas:

Métricas de monitoramento

As seguintes métricas do CloudMonitor usam a dimensão PolicyBasedRouteId:

FAQ

Por que minha regra não está surtindo efeito?

Para solucionar, verifique estes itens em ordem:

① Primeiro, verifique se a tabela de rotas de políticas está vinculada ao attachment de ingresso. Você pode verificar isso na aba Intra-Region Connections da página de detalhes do TR, na coluna Associate with Route Table do attachment de destino.

② Por favor, confirme se a regra está configurada corretamente e se o tráfego ativo corresponde às suas condições.

③ Além disso, verifique se uma regra de prioridade mais alta (com um valor de prioridade menor) está correspondendo ao tráfego primeiro.

④ Por fim, verifique a direção do tráfego. O roteamento baseado em políticas aplica-se apenas ao tráfego que flui para dentro do TR. Você pode usar a métrica de monitoramento PolicyBasedRouteHitCount no CloudMonitor para verificar se os pacotes estão correspondendo à regra.