IBM Cloud Docs
Sobre as tabelas de roteamento e rotas

Sobre as tabelas de roteamento e rotas

A IBM Cloud® Virtual Private Cloud (VPC) gera automaticamente uma tabela de roteamento padrão para a VPC gerenciar o tráfego na zona. Por padrão, essa tabela de roteamento está vazia. É possível incluir rotas na tabela de roteamento padrão ou criar uma ou mais tabelas de roteamento customizadas e, em seguida, incluir rotas. Por exemplo, para ter uma política de roteamento especializada para uma sub-rede específica, é possível criar uma tabela de roteamento e associá-la a uma ou mais sub-redes. No entanto, se você quiser alterar a política de roteamento padrão que afeta todas as sub-redes que usam a tabela de roteamento padrão, deverá adicionar rotas à tabela de roteamento padrão.

A tabela de roteamento padrão funciona da mesma forma que outras tabelas de roteamento, mas é criada automaticamente e usada quando você cria uma sub-rede sem especificar uma tabela de roteamento.

É possível definir rotas dentro de qualquer tabela de roteamento para formar o tráfego do jeito que você desejar. Cada sub-rede é atribuída a uma tabela de roteamento, responsável por gerenciar o tráfego da sub-rede. É possível mudar a tabela de roteamento que um sub-rede usa para gerenciar seu tráfego de egresso a qualquer momento.

Este serviço também permite o uso de Network Functions Virtualization (NFV) para serviços avançados de rede, como roteamento de terceiros, firewalls, balanceamento de carga local/global, firewalls de aplicativo da web e muito mais. As tabelas de roteamento customizado também estão sendo integradas atualmente em serviços da IBM Cloud.

Roteamento de egresso e ingresso

  • As rotas de saída controlam o tráfego, que se origina em uma sub-rede e viaja para a Internet pública ou para outra VM na mesma zona ou em uma zona diferente.

  • As rotas de entrada permitem que você personalize as rotas no tráfego de entrada para uma VPC a partir de fontes de tráfego externas à zona de disponibilidade da VPC ( IBM Cloud Direct Link, IBM Cloud Transit Gateway, outra zona de disponibilidade na mesma VPC ou a Internet pública).

    Apenas uma tabela de roteamento customizado pode ser associada a uma origem de tráfego de ingresso específica. No entanto, é possível usar tabelas de roteamento diferentes para diferentes origens de tráfego. Por exemplo, a tabela de roteamento A pode usar Transit Gateway e VPC Zone, enquanto a tabela de roteamento B usa Direct Link.

Definindo a tabela de roteamento implícito do sistema

Não é possível configurar uma tabela de roteamento para usar a tabela de roteamento implícita no sistema; ela é preenchida automaticamente. A tabela de roteamento implícita do sistema é usada quando nenhuma rota correspondente é encontrada na tabela de roteamento personalizada associada à sub-rede para a qual o tráfego está saindo. Se nenhuma correspondência for encontrada, o pacote será eliminado.

Uma tabela de roteamento implícita no sistema é mantida para cada VPC. Uma VPC pode estar presente em várias zonas, e a tabela de roteamento implícito no sistema da VPC é diferente em cada zona. Para o roteamento de entrada, a tabela de roteamento implícito do sistema contém apenas rotas para cada interface de rede na zona da VPC.

Esse comportamento pode ser evitado com uma rota padrão da tabela de roteamento personalizada com uma ação de drop.

A tabela de roteamento implícito do sistema contém:

  • Rotas para o CIDR de cada sub-rede na VPC

  • Rotas para sub-redes dentro da zona (mantida estaticamente)

  • Rotas para sub-redes em outras zonas que são aprendidas por meio do BGP

  • Rotas dinâmicas aprendidas por meio do BGP (por exemplo, Direct Link e Transit Gateway )

  • A rota padrão para tráfego da Internet (usada quando um gateway público ou IP flutuante é associado à VPC)

  • Rotas para os CIDRs de rede de serviço de infraestrutura clássica (usados quando um gateway de serviço está associado ao VPC), por exemplo:

    10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15 e 10.254.0.0/16 são CIDRs de rede de serviço de infraestrutura clássica.

Determinando a preferência de rota

Você pode designar a prioridade da rota (0-4 ) de rotas VPC para determinar quais rotas têm prioridade mais alta quando existem várias rotas para um destino específico. Rotas existentes e novas rotas, que são criadas sem um valor de prioridade, são automaticamente definidas para a prioridade padrão (2 ).

A prioridade da rota é considerada apenas em destinos idênticos e é semelhante a qualquer rota aprendida dinamicamente

Configurando exemplos de prioridade de rota

  • Se você tiver uma rota com um prefixo /32 e uma prioridade de 1 e uma rota com destino de /31 e prioridade 0, então /32 será usado primeiro (correspondência de prefixo mais longa). Em outras palavras, a prioridade só importa quando há mais de uma rota com o mesmo prefixo.
  • Se você tiver três rotas com 0.0.0.0/0 (rota padrão), somente a rota com a prioridade mais alta será usada.. Se a rota selecionada for removida (por exemplo, através da automação), a prioridade mais alta das duas rotas restantes será selecionada.
  • Se a tabela de roteamento personalizada tiver apenas uma rota com um prefixo específico, essa rota será sempre usada, independentemente de sua prioridade. A seleção da melhor rota é realizada para cada prefixo específico e escolhe a rota com maior prioridade.

O roteamento ECMP (Equal-Cost Multi-Path) é usado quando duas rotas têm o mesmo destino e prioridade (estendendo o comportamento atual em que o ECMP é usado para duas rotas com o mesmo destino). No máximo, duas rotas em uma tabela de roteamento têm permissão para ter o mesmo destino e prioridade. Por exemplo, se a tabela de roteamento customizado tiver três rotas com o mesmo destino, uma rota com prioridade 1 e as outras duas rotas com prioridade 4 (ECMP), a rota com prioridade 1 será selecionada e as rotas ECMP serão ignoradas (sem ECMP). Agora, se as duas rotas com o mesmo destino e prioridade tiverem a prioridade mais alta, o sistema selecionará essas duas rotas e executará ECMP. Então, se uma dessas rotas for excluída, a rota que ainda existe será selecionada e o ECMP não será executado.

Para limitações de prioridade de rota, consulte Limitações e diretrizes.

Rotas de publicidade

No passado, os prefixos de endereço dentro do prefixo de endereço raiz do VPC foram anunciadas para o Direct Link e o Transit Gateway No entanto, não foi possível anunciar seus prefixos do endereço fora do prefixo do endereço raiz do VPC A propaganda de rota inclui esse recurso Por exemplo, a Figura 1 divulga a rota 0.0.0.0/0 em todas as zonas para um próximo hop específico da zona

de uso do firewall de proxy de
de publicidade*

Para mais informações, veja Criando uma tabela de roteamento e Atualizando uma tabela de roteamento.

Considerações sobre rota de publicidade

Esteja ciente das seguintes considerações ao anunciar rotas:

  • Você pode anunciar rotas fora do prefixo de endereço raiz atribuído à VPC, para poder anunciar suas redes externas ou redes residentes fora da VPC para um Direct Link ou Transit Gateway.

  • Se vários Transit Gateways ou Direct Links estiverem conectados à sua VPC, você poderá usar a filtragem de rotas em Transit Gateway ou Direct Link conexões para ajustar quais rotas são anunciadas para quais conexões.

  • Se múltiplas rotas forem anunciadas para um prefixo de destino com prioridades diferentes, a rota com maior prioridade (menor valor de prioridade) será usada como primária e a rota com menor prioridade (maior valor de prioridade) será usada como backup.

  • Se você anunciar duas rotas diferentes, como 172.16.0.0/31 através 10.1.1.0 e 172.16.0.0/32 através 10.1.2.0, o percurso com /32 prefixo sempre tem precedência sobre a rota com um /31 prefixo. Isso é consistente com o conjunto de regras "Correspondência de prefixo mais longo". Um prefixo mais longo para um destino de host é sempre preferível a um prefixo mais estreito.

  • Atualmente, não há mecanismo para sinalizar rotas duplicadas de um Transit Gateway ou Direct Link. O Transit Gateway seleciona o melhor caminho usando o prefixo mais específico e o caminho AS mais curto, conforme preferido. Caso contrário, o Transit Gateway seleciona a rota que recebeu primeiro. Essa rota pode não ser a rota mais antiga no lado da VPC e poderá mudar se as rotas para o Transit Gateway são atualizados internamente.

Casos de uso

Os casos de uso a seguir ilustram diferentes cenários de roteamento.

Caso de uso 1: firewall de proxy de borda

Caso de uso do firewall de proxy de
de uso do firewall de proxy de

Tabela de roteamento de saída do firewall de proxy de borda
Destino Ação Próximo hop Local
10.10.0.0/16 Delegar Dallas DC 1
10.11.0.0/16 Delegar Dallas DC 1
0.0.0.0/0 Entregar 10.10.1.5 Dallas DC 1

Objetivo: firewall de proxy de borda

Fluxos seguro para a Internet pública por detrás de um gateway, proxy ou dispositivo de firewall definido pelo cliente, enquanto também permite que os recursos nas outras sub-redes fluam por meio do gateway público gerenciado pelo VPC.

Ao usar as rotas personalizadas da VPC com roteamento de saída por sub-rede, você pode criar uma tabela para substituir o roteamento implícito no sistema dentro da rede da VPC. Neste exemplo, a tabela padrão que foi criada pelo sistema, na qual todas as sub-redes são atribuídas na criação, permanece inalterada. Também é criada uma tabela para direcionar o tráfego da sub-rede 10.10.1.0/24 por meio de um proxy de borda (NFV Proxy).

Como o destino dos fluxos proxy é a Internet pública e, normalmente, segue a rota padrão (0.0.0.0/0), você deve primeiro isentar os fluxos para redes privadas acessíveis internamente usando a função Delegate das rotas personalizadas. Os recursos na sub-rede 10.10.3.0/24 continuam a usar o gateway público que está anexado a essa sub-rede.

Enquanto as instâncias que usam o proxy compartilham uma sub-rede comum com o proxy neste exemplo, você não é obrigado a fazer isso. Com rotas personalizadas, você pode especificar um IP de próximo salto de uma instância conectada a uma sub-rede diferente. Ao fazer isso, você pode escalar horizontalmente sem se preocupar com o tamanho da sub-rede dos serviços do Edge. Por exemplo, uma tabela de roteamento de proxy pode ser anexada à sub-rede 10.10.3.0/24 e direciona todos os fluxos públicos para o proxy NFV.

Funções usadas em um firewall de proxy de borda

Este caso de uso usa as funções a seguir de firewalls de proxy de borda:

  • Desativar a verificação de spoofing de IP nas interfaces 10.10.0.5 e 10.10.1.5 para ativar a preservação de endereço de origem. Essa ação requer permissões elevadas do IAM na instância.
  • Um gateway público para fluxos de saída com recursos que não são direcionados por meio do proxy NFV.
  • O IP flutuante conectado à interface 10.10.0.5 para ativar fluxos públicos de entrada e saída diretamente para o proxy NFV.
  • Incluindo grupos de segurança stateful e listas de controle de acesso à rede (ACLs) nas interfaces de instâncias e sub-redes VPC, respectivamente, para fornecer recursos de isolamento adicionais dentro do VPC.

Caso de uso 2: balanceador de carga público

Caso de uso do balanceador de carga público
Caso de uso do balanceador de carga público

Balanceador de carga público Tabela de roteamento de saída da Web
Destino Ação Próximo hop Local
10.10.0.0/16 Delegar Dallas DC 1
10.11.0.0/16 Delegar Dallas DC 1
161.26.0.0/16 * Delegar Dallas DC 1
166.8.0.0/14 * Delegar Dallas DC 1
0.0.0.0/0 Entregar 10.10.1.5 Dallas DC 1

Objetivo: balanceador de carga público

Hospedagem de aplicativos da Web que usam um aplicativo definido pelo cliente ou um balanceador de carga de rede.

Ao utilizar as rotas personalizadas da VPC com roteamento de saída por sub-rede, você pode criar uma tabela para substituir o roteamento implícito do sistema com a rede VPC sem atualizar as informações de roteamento em cada instância. Neste exemplo, o IP de origem dos usuários da Internet para a camada da web é preservado. As camadas web-para-aplicativo e aplicativo-para-db se comunicam usando o roteamento VPC implícito e continuam a usar o gateway público para saída da Internet.

A delegação de rotas é necessária para redes internas/privadas dentro das redes de serviços da VPC e da IBM sobre o backbone privado. Para evitar a necessidade de delegação, os servidores da camada da web podem ser conectados à sub-rede da camada de aplicativo e o roteamento mudado nas instâncias da web para usar o gateway de sub-rede do aplicativo como o próximo hop para as redes internas de serviços de VPC e de nuvem.

Funções usadas em balanceadores de carga públicos

Este caso de uso utiliza as funções a seguir de balanceadores de carga públicos:

  • Desativar a verificação de spoofing de IP nas interfaces 10.10.0.5 e 10.10.1.5 para ativar a preservação de endereço de origem. Essa ação requer permissões elevadas do IAM na instância.
  • Um gateway público para fluxos de saída para recursos que não são direcionados por meio do proxy NFV.
  • O IP flutuante conectado à interface 10.10.0.5 para ativar fluxos públicos de entrada e saída diretamente para o balanceador de carga NFV.
  • Incluindo grupos de segurança stateful e listas de controle de acesso à rede (ACLs) nas interfaces de instâncias e sub-redes VPC, respectivamente, para fornecer recursos de isolamento adicionais dentro do VPC.

Caso de uso 3: VPN

Para ter um gateway VPN como o próximo hop em uma tabela de roteamento VPC, o gateway é criado em uma sub-rede dedicada. Esta sub-rede é usada apenas para o gateway VPN e associada à sub-rede de gateway VPN com uma tabela de roteamento diferente quando há uma rota 0.0.0.0/0 e o próximo hop é uma conexão VPN.

Por exemplo:

  • A sub-rede A é usada para hospedar os servidores virtuais e está associada à tabela de roteamento padrão. Há uma rota 0.0.0.0/0, e o próximo hop é uma conexão VPN.
  • A sub-rede B é usada para hospedar o gateway VPN e cria uma nova tabela de roteamento (tabela de roteamento B). Ele associa a sub-rede B com a tabela de roteamento B. Por padrão, você não precisa de rotas na tabela de roteamento B.

Para ter conectividade entre sub-redes quando se tem a rota 0.0.0.0/0 e o próximo hop é uma conexão VPN, como acima, é possível incluir as rotas delegadas a seguir:

destination CIDR==zone3 VPC prefix, action==delegate, location==zone1
destination CIDR==zone1 VPC prefix, action==delegate, location==zone3

Limitações e diretrizes

As limitações e diretrizes a seguir aplicam-se às rotas customizadas da IBM Cloud para VPC.

Limitações gerais

  • Atualmente, não é possível usar uma tabela de roteamento customizado para o tráfego de ingresso (anexado a uma origem de tráfego) e de egresso (anexado a um sub-rede). Além disso, a tabela de roteamento customizado padrão não pode ser associada a uma origem de tráfego de ingresso.
  • Atualmente, o tráfego de retorno pode falhar devido a roteamento assimétrico. Esse problema afeta todos os serviços que dependem de rotas estáticas ECMP. Por exemplo, suponha que você crie duas rotas ECMP no VPC A com o destino sendo 10.134.39.64/26 e os próximos hops sejam 192.168.2.4 e 192.168.2.5 respectivamente. Esses próximos hops são endereços IP do dispositivo NFV.. Quando você envia tráfego da instância A na VPC, o pacote é roteado aleatoriamente para um dos próximos saltos e não há garantia de que o tráfego de retorno siga o mesmo caminho que o tráfego de encaminhamento devido ao algoritmo de hash ECMP no outro lado . Este fenômeno é conhecido como roteamento assimétrico. Quando ocorre o roteamento assimétrico, o problema não está no roteamento em si, mas no grupo de segurança descarta o tráfego mesmo que as regras do grupo de segurança permitam esse tráfego porque o grupo de segurança vê o tráfego em apenas um caminho. Em geral, é aconselhável evitar o uso de rotas ECMP.
  • A capacidade de atingir um próximo endereço IP de hop em uma rota customizada não é um fator determinante para saber se a rota é usada para o tráfego de encaminhamento. Isso pode causar problemas quando várias rotas com o mesmo prefixo (mas endereços IP de próximo hop diferentes) são usadas, uma vez que o tráfego para endereços IP de próximo hop inacessíveis pode não ser entregue.
  • O IBM Cloud VPC permite o uso de espaços de endereço IPv4 registrados pelo RFC-1918 e pelo IANA de maneira privada dentro do seu VPC, com algumas exceções nos intervalos de propósito especial do IANA, e intervalos selecionados designados aos serviços da IBM Cloud. Ao usar os intervalos registrados por IANA dentro de sua empresa, e dentro de VPCs em conjunto com o IBM Cloud Transit Gateway ou o IBM Cloud Direct Link, as rotas customizadas devem ser instaladas em cada zona. Para obter mais informações, consulte Considerações de roteamento para designações de IP registradas pela IANA.
  • No caso de existirem 2 rotas diferentes anunciadas para o mesmo destino, aplicam-se as seguintes limitações:
    • Quando o próximo salto para ambas as rotas estiver na mesma zona, a rota com maior prioridade (ou seja, um valor menor para priority ) é usado como caminho primário e a rota com menor prioridade (ou seja, um valor mais alto para priority ) é usado como caminho de backup. Se a prioridade para ambas as rotas for a mesma, o ECMP será usado para rotear o tráfego igualmente nas duas rotas.
    • Quando o próximo hop para ambas as rotas estiver em zonas diferentes, o roteador Transit Gateway ou Direct Link escolherá a melhor rota. Neste caso, essa é a rota mais antiga anunciada.

Prioridade da rota

Se existirem várias rotas com o mesmo CIDR/prefixo de destino, a rota com o valor de prioridade mais alto será usada.. Rotas com o mesmo CIDR/prefixo de destino e prioridade usam roteamento ECMP.

Rotas de egresso

Para rotas customizadas de egresso, ao incluir uma rota de destino, deve-se selecionar uma zona. No entanto, o próximo hop não precisa estar na mesma zona. Para rotas customizadas de ingresso, o próximo hop deve estar na mesma zona.

Caminhos múltiplos de custo igual (ECMP)

O roteador implícito executa roteamento de ECMP (várias rotas com o mesmo destino, mas diferentes endereços de próximo hop) com as limitações a seguir:

  • Isso só se aplica a rotas com uma ação de deliver.
  • Apenas duas rotas de destino idênticas são permitidas por zona e cada uma deve ter diferentes endereços de próximo hop.
  • Quando o ECMP é usado, o caminho de retorno não pode tomar o mesmo caminho.
  • O ECMP suporta apenas um tipo de próximo salto de endereço IP.

Rotas de ingresso

  • Atualmente, o roteamento de entrada pública (public internet traffic choice) está disponível apenas no console. CLI e API estão próximas.
  • Cada tipo de origem de ingresso pode ser associado a até uma tabela de roteamento de ingresso por VPC, no entanto, uma VPC pode ter várias tabelas de roteamento de ingressos e cada tabela de roteamento de ingressos pode ter um ou mais tipos de ingressos associados.
  • O tráfego de ingresso por meio de uma determinada origem de tráfego é roteado usando as rotas na tabela de roteamento customizado que está associada a essa origem de tráfego.
  • Rotas customizadas em uma tabela de roteamento customizada associada a uma origem de tráfego de ingresso, e com uma ação de deliver, devem ter um próximo IP de hop contido por um dos prefixos de endereço do VPC na zona de disponibilidade em que a rota é incluída. Além disso, o próximo IP de hop deve ser configurado em uma interface de servidor virtual na VPC e na zona de disponibilidade na qual a rota é direcionada.
  • O tráfego de ingresso por meio de uma determinada origem de tráfego é roteado usando as rotas na tabela de roteamento customizado que está associada a essa origem de tráfego. Se nenhuma rota de correspondência for localizada em uma tabela de roteamento customizado, o roteamento continuará usando a tabela de roteamento do sistema de VPC. É possível evitar esse comportamento com uma rota padrão da tabela de roteamento customizada com uma ação descartar.
  • Uma tabela de roteamento personalizado de ingresso contendo quaisquer rotas personalizadas com IP de destino (FIP) deve ser definida na mesma zona que a instância do servidor virtual que um FIP está associado.
  • IPs flutuantes que estão vinculados a um gateway IBM Cloud VPN não podem ser usados como um destino para uma rota personalizada em uma tabela de roteamento de entrada quando o tipo de origem Internet pública route_internet_ingress) está ativado.

Comprimentos de prefixo exclusivos

É possível usar um máximo de 14 comprimentos de prefixo exclusivos por tabela de roteamento customizado. É possível ter várias rotas com o mesmo prefixo que contam como apenas um prefixo exclusivo. Por exemplo, é possível que você tenha várias rotas com um prefixo /28. Isso conta como um prefixo exclusivo.

VPN

  • Ao criar uma rota para uma conexão VPN estática e baseada em rota, é necessário inserir o ID da conexão VPN para o próximo salto. O gateway VPN deve estar na mesma zona que a sub-rede à qual a tabela de roteamento está associada. Não é recomendável que você defina um gateway VPN como o próximo hop em uma zona diferente da sub-rede que está associada à tabela de roteamento.
  • Uma rota com uma conexão VPN como o próximo hop entra em vigor apenas quando a conexão VPN está ativa. Esta rota será ignorada durante a consulta de roteamento se a conexão VPN estiver desativada.
  • Uma tabela de roteamento customizado que contém rotas customizadas com um próximo hop que está associado a uma conexão VPN não pode ser associada a uma origem de tráfego de ingresso.
  • As rotas personalizadas são suportadas apenas em VPNs baseados em rotas. Se você estiver usando VPNs baseadas em política, as rotas serão criadas automaticamente pelo serviço VPN na tabela de roteamento padrão.