Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Peering de rede VPC

O peering de rede VPC do Google Cloud conecta duas redes de nuvem privada virtual (VPC) para que os recursos de cada rede possam se comunicar entre si:

  • Todas as sub-redes podem se comunicar por endereços IPv4 internos.
  • As sub-redes de pilha dupla também podem se comunicar usando endereços IPv6 internos ou externos.

As redes VPC com peering podem estar no mesmo projeto, em projetos diferentes da mesma organização ou em projetos diferentes de organizações diferentes.

O peering de rede VPC oferece os seguintes benefícios:

Benefícios do peering de rede VPC

O peering de rede VPC tem os seguintes benefícios:

  • Latência de rede: a conectividade que usa apenas endereços internos fornece menor latência do que a conectividade que usa endereços externos.
  • Segurança da rede: os proprietários de serviços não precisam ter os serviços expostos à Internet pública e lidar com os riscos associados.
  • Custo da rede: o Google Cloud cobra o preço da largura de banda de saída para redes que usam endereços IP externos para se comunicarem, mesmo que o tráfego esteja dentro da mesma zona. Mas se as redes estiverem com peering, poderão usar endereços IP internos para se comunicar e economizar esses custos de saída. O preço normal da rede se aplicará a todo o tráfego.

Para mais informações sobre como criar conexões de peering, consulte Usar o Peering de redes VPC.

Especificações

O peering de rede VPC tem as seguintes especificações.

Especificações gerais:

  • O peering de rede VPC funciona com o Compute Engine, o GKE e o ambiente flexível do App Engine.
    • Por padrão, o peering de redes VPC com GKE é aceito quando usado com aliases de IP. Se você não costuma utilizar aliases de IP, exporte rotas personalizadas para que os contêineres do GKE possam ser acessados em redes com peering.
  • O Peering de redes VPC é aceito somente em redes VPC. Ele não é compatível com redes legadas.
  • O peering de rede VPC é compatível com conectividade IPv4 e IPv6. É possível configurar o peering de rede VPC em uma rede VPC que contenha sub-redes de pilha dupla. No entanto, para IPv6, apenas rotas dinâmicas são trocadas.
  • Uma determinada rede VPC pode fazer peering com várias redes VPC, mas há um limite.

Separação administrativa:

  • As redes VPC com peering permanecem separadas administrativamente. Rotas, firewalls, VPNs e outras ferramentas de gerenciamento de tráfego são administradas e aplicadas separadamente em cada uma das redes VPC.
  • Para estabelecer a conectividade de peering, um administrador de rede para cada rede VPC precisa criar uma conexão de peering com a outra rede VPC. Um administrador de rede para qualquer rede VPC pode desconectar uma conexão de peering.
  • Cada lado de uma associação por peering é configurado de modo independente. O peering estará ativo apenas quando a configuração de ambos os lados for correspondente. Qualquer um dos lados pode optar por excluir a associação a qualquer momento.
  • A criação de uma conexão de peering não concede papéis de Identity and Access Management (IAM) na outra rede VPC. Por exemplo, se tiver o papel de Administrador de rede do Compute ou de Administrador de segurança do Compute em uma rede, você não se tornará Administrador da rede ou Administrador de segurança na outra rede.

IAM:

  • As permissões do IAM para criar e excluir o peering de redes VPC estão incluídas como parte do papel de Administrador de rede do Compute (roles/compute.networkAdmin).
  • É possível usar um papel personalizado se ele incluir as seguintes permissões:
    • compute.networks.addPeering
    • compute.networks.updatePeering
    • compute.networks.removePeering
    • compute.networks.listPeeringRoutes

Troca de rotas:

  • O peering e a opção de importar e exportar rotas personalizadas podem ser configurados para uma rede VPC mesmo antes da outra rede VPC ser criada. Embora a troca de rota ocorra somente após os dois lados terem sido configurados.
  • Os peers de VPC sempre exportam rotas de sub-rede.
  • Os peers de VPC sempre importarão rotas de sub-rede se a sub-rede usar endereços IP particulares. Se a sub-rede usar endereços IP públicos utilizados de modo particular, as redes com peering precisarão importar explicitamente as rotas de sub-rede de IP público de uso particular para recebê-las de outras redes. Para mais informações sobre endereços IP particulares e endereços IP públicos utilizados de modo particular, consulte Intervalos válidos.
  • Não é possível desativar a troca de rotas de sub-rede ou escolher quais delas serão trocadas. Depois que o peering é estabelecido, todos os recursos dentro dos endereços IP de sub-rede ficam acessíveis nas redes com peering direto. O Peering de redes VPC não fornece controles de rota granulares para filtrar quais intervalos CIDR de sub-rede podem ser acessados nas redes com peering. Se for necessário, use regras de firewall para filtrar o tráfego. Os tipos de endpoints e recursos a seguir são acessíveis em qualquer rede com peering direto:
    • IPs internos da máquina virtual (VM) em todas as sub-redes
    • IPs internos com carga balanceada em todas as sub-redes
  • É possível trocar rotas personalizadas (rotas estáticas e dinâmicas), caso as configurações de peering tenham sido definidas para importar ou exportá-las. Para mais informações, consulte Como importar e exportar rotas personalizadas.
  • Rotas de sub-rede e rotas estáticas são globais. Já as rotas dinâmicas podem ser regionais ou globais, dependendo do modo de roteamento dinâmico da rede VPC.
  • Um intervalo CIDR de sub-rede em uma rede VPC com peering não pode se sobrepor a uma rota estática em outra rede com peering. Essa regra abrange rotas de sub-rede e rotas estáticas. O Google Cloud verifica se há sobreposição nas seguintes circunstâncias e gera um erro caso ela ocorra.
    • Quando você faz peering de redes VPC pela primeira vez.
    • Quando você cria uma rota estática em uma rede VPC com peering.
    • Quando você cria uma nova sub-rede em uma rede VPC com peering.
  • Uma rota dinâmica pode se sobrepor a uma rota de sub-rede em uma rede com peering. No caso de rotas dinâmicas, os intervalos de destino que se sobrepõem a uma rota de sub-rede da rede com peering são descartados de maneira silenciosa. O Google Cloud usa a rota de sub-rede.

Limitações:

  • Somente redes com peering direto podem se comunicar. O peering transitivo não é aceito. Ou seja, se a rede VPC N1 estabelecer peering com a N2 e a N3, mas a N2 e a N3 não tiverem uma conexão direta, a rede VPC N2 não poderá se comunicar com a rede VPC N3 por meio do Peering de redes VPC.
  • As regras de firewall de VPC não podem usar uma tag de rede ou conta de serviço de uma rede com peering. Veja mais detalhes em Segurança de rede.
  • Os nomes de DNS internos do Compute Engine criados em uma rede não podem ser acessados em redes com peering. Use o endereço IP para acessar as instâncias de VM na rede com peering.
  • As rotas com base na política nunca são trocadas via peering.

Como importar e exportar rotas personalizadas

Segurança de rede

O peering de rede VPC não troca nenhuma regra de firewall de VPC ou políticas hierárquicas de firewall. As regras de firewall de VPC em uma rede VPC não podem especificar destinos ou origens usando tags de rede ou contas de serviço da outra rede VPC. No entanto, a mesma tag de rede de destino pode ser usada em ambas as redes.

Toda rede VPC tem regras de firewall implícitas. Devido às regras implícitas de firewall de negação de entrada, os administradores de segurança de uma rede VPC local precisam criar regras adequadas de firewall de permissão de entrada ou políticas hierárquicas de firewall. Essas regras ou políticas permitem pacotes dos intervalos de endereços IP de origem necessários na rede VPC com peering.

Devido às regras implícitas de firewall de permissão de saída, não é preciso criar regras de firewall de permissão de saída ou políticas de firewall hierárquicas para permitir pacotes para os destinos na rede VPC com peering. No entanto, se os administradores de segurança da rede VPC local tiverem criado regras explícitas de negação de saída, será necessário criar regras ou políticas de permissão de saída.

Suporte DNS

Os recursos em uma rede VPC com peering não podem usar nomes DNS internos do Compute Engine criados por uma rede VPC local.

Uma rede VPC com peering não pode usar zonas particulares gerenciadas pelo Cloud DNS que estejam autorizadas apenas para uma rede VPC local. Para disponibilizar os nomes DNS para os recursos em uma rede VPC com peering, use uma das seguintes técnicas:

Suporte ao balanceador de carga interno

Os clientes em uma rede VPC local podem acessar balanceadores de carga TCP/UDP internos em uma rede VPC com peering. Para mais informações, consulte Como usar o peering de rede VPC para um balanceador de carga TCP/UDP interno. As redes com peering podem trocar rotas estáticas personalizadas usando balanceadores de carga TCP/UDP internos como próximos saltos. Para mais informações, consulte Opções de troca de rota.

Os clientes em uma rede VPC local podem acessar balanceadores de carga HTTP(S) internos em uma rede VPC com peering. Para mais informações, consulte Como usar peering de rede VPC para balanceamento de carga HTTP(S) interno.

Limites relacionados ao peering de redes VPC

Os limites de peering de rede VPC controlam o seguinte:

  • O número de recursos, como instâncias de máquina virtual (VM) ou regras de encaminhamento interno que podem estar presentes em um grupo de peering.
  • O número de redes às quais uma determinada rede VPC pode se conectar.

Os limites de peering de VPC dependem de um conceito chamado grupo de peering. Cada rede VPC tem o próprio grupo de peering, que consiste nela mesma e em todas as outras redes VPC conectadas a ela usando o peering de rede VPC. No cenário mais simples, se duas redes VPC, net-a e net-b, estiverem em peering entre si, haverá dois grupos de peering: um da perspectiva de net-a e outro da perspectiva de net-b.

Para mais informações, consulte Limites de peering da rede VPC.

Opções de troca de rota

Quando uma rede VPC compartilha rotas locais com uma rede VPC com peering, ela exporta as rotas. A rede VPC com peering pode importar as rotas. As rotas de sub-rede, exceto as rotas de sub-rede IPv4 que usam endereços IPv4 públicos usados de modo particular, são sempre trocadas.

A configuração de peering de rede VPC permite controlar o seguinte:

  • Se as rotas IPv6 foram trocadas.
  • Se as rotas para sub-redes que usam endereços IPv4 públicos usados de modo particular são exportadas ou importadas.
  • Se as rotas personalizadas estáticas e dinâmicas são exportadas ou importadas.

É possível atualizar a configuração antes que o peering seja estabelecido ou enquanto a conectividade de peering estiver ativa.

Opções para troca de rotas de sub-rede

A tabela a seguir descreve as opções de troca de rota para rotas de sub-rede:

Tipo de rota Condições de exportação de rota Condições de importação de rota
Rotas de sub-redes IPv4 (intervalos de sub-redes IPv4 principais e secundárias) usando intervalos de endereços IPv4 particulares Sempre exportado

Não pode ser desativado		 Sempre importado

Não pode ser desativado
Rotas de sub-redes IPv4 (intervalos de sub-redes IPv4 principais e secundárias) usando intervalos de endereços IPv4 públicos usados de modo particular Exportado por padrão

A exportação é controlada usando a sinalização --export-subnet-routes-with-public-ip 		Não importado por padrão

A importação é controlada usando a sinalização --import-subnet-routes-with-public-ip
Intervalos de sub-rede IPv6 internos
(ipv6-access-type=INTERNAL) 		Não exportado por padrão

A exportação é ativada ao configurar --stack-type=IPV4_IPV6 		Não importado por padrão

A importação é ativada ao configurar --stack-type=IPV4_IPV6
Intervalos de sub-rede IPv6 externos
(ipv6-access-type=EXTERNAL) 		Não exportado por padrão

A exportação é ativada ao configurar --stack-type=IPV4_IPV6 		Não importado por padrão

A importação é ativada ao configurar --stack-type=IPV4_IPV6

Opções para troca de rotas estáticas personalizadas

A tabela a seguir descreve as opções de troca de rota para rotas estáticas personalizadas:

Tipo de rota Condições de exportação de rota Condições de importação de rota
Rotas estáticas personalizadas com tags de rede (todos os tipos de próximo salto) Não é possível exportar Não é possível importar
Rotas estáticas personalizadas usando o próximo salto do gateway de Internet padrão Não é possível exportar Não é possível importar
Rotas estáticas IPv4 personalizadas, sem tags de rede, usando o endereço IPv4 particular de um balanceador de carga TCP/UDP interno como o próximo salto Sempre exportado (como rotas IPv4 da sub-rede)

Não pode ser desativado 		Sempre importado (como rotas IPv4 da sub-rede)

Não pode ser desativado
Rotas estáticas IPv4 personalizadas, sem tags de rede, usando o nome da regra de encaminhamento de um balanceador de carga TCP/UDP interno como o próximo salto Não exportado por padrão

A exportação é controlada usando a sinalização --export-custom-routes 		Não importado por padrão

A importação é controlada usando a sinalização --import-custom-routes
Rotas estáticas IPv4 personalizadas (sem tags de rede) usando outros tipos de próximo salto Não exportado por padrão

A exportação é controlada usando a sinalização --export-custom-routes 		Não importado por padrão

A importação é controlada usando a sinalização --import-custom-routes

Opções para troca de rotas dinâmicas

A tabela a seguir descreve as opções de troca de rota para rotas dinâmicas:

Tipo de rota Condições de exportação de rota Condições de importação de rota
Rotas IPv4 dinâmicas Não exportado por padrão

A exportação é controlada usando a sinalização --export-custom-routes 		Não importado por padrão

A importação é controlada usando a sinalização --import-custom-routes
Rotas IPv6 dinâmicas Não exportado por padrão

A exportação é controlada usando a sinalização --export-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6 		Não importado por padrão

A importação é controlada usando a sinalização --import-custom-routes quando o tipo de pilha do peering é definido como --stack-type=IPV4_IPV6

Troca de rota personalizada

Quando uma rede VPC exporta rotas personalizadas e a outra rede VPC importa rotas personalizadas, a rede de importação pode enviar pacotes diretamente para o próximo salto para cada rota personalizada importada na rede VPC com peering. As rotas dinâmicas e estáticas personalizadas são aprendidas juntas e não podem ser configuradas de forma independente. As alterações em uma rede são refletidas na outra, sujeitas a determinadas condições. Para mais informações, neste documento, consulte Rotas ignoradas, Interações de rota de sub-rede e de sub-rede de peering e Interações de sub-rede e de rota estática.

A importação de rotas personalizadas de uma rede VPC com peering pode ser útil nos seguintes cenários:

  • Se a rede VPC com peering tiver clusters do GKE baseados em rotas e você precisar enviar pacotes para os pods nesses clusters: os endereços IP do pod serão implementados como intervalos de destino para rotas estáticas personalizadas localizadas na rede VPC com peering.
  • Se a rede VPC com peering tiver rotas para recursos locais e você precisar acessar esses recursos na rede VPC local: também será preciso criar rotas para os intervalos de endereços IP de sub-rede da rede VPC local na rede local. É possível usar a divulgação de rota personalizada do Cloud Router na rede VPC com peering para atender a esse requisito adicional.

Importante: os Cloud Routers não divulgam rotas de sub-rede de peering ao usar o modo de divulgação padrão. Portanto, é preciso usar divulgações de rota personalizadas para divulgar rotas de sub-rede de peering (ou intervalos agregados de rotas de sub-rede de peering).

Rotas ignoradas

Mesmo quando uma rede VPC importa uma rota, ela pode ignorar a rota importada em situações como as seguintes:

  • Quando a rede VPC local tem uma rota com um destino idêntico ou mais específico (máscara de sub-rede mais longa), a rede VPC local sempre usa a rota local dela.

  • Quando a rede VPC local não contém a rota mais específica para o destino de um pacote, mas duas ou mais redes VPC com peering têm o mesmo destino mais específico para o pacote, o Google Cloud usa um algoritmo interno para selecionar um próximo salto de apenas uma das redes VPC com peering. Essa seleção ocorre antes de a prioridade da rota ser considerada e não é possível configurar o comportamento. Como prática recomendada, evite essa configuração porque adicionar ou remover redes VPC com peering pode levar a alterações não intencionais na ordem de roteamento.

Para mais detalhes sobre as situações anteriores, consulte Ordem de roteamento.

Para peerings de pilha dupla, se uma rede VPC local que importa rotas IPv6 não tiver sub-redes de pilha dupla, nenhuma das rotas IPv6 que ela recebe de redes VPC com peering poderá ser usada. Além disso, se a restrição da política da organização constraints/compute.disableAllIpv6 tiver sido definida, um administrador de rede talvez não consiga criar sub-redes de pilha dupla.

Interações com rotas de sub-rede e sub-rede de peering

As rotas de sub-rede IPv4 em redes VPC com peering não podem se sobrepor:

  • O peering proíbe rotas de sub-rede IPv4 idênticas. Por exemplo, duas redes VPC com peering não podem ter uma rota de sub-rede IPv4 com o destino 100.64.0.0/10.
  • O peering proíbe que uma rota de sub-rede esteja contida em uma rota de sub-rede de peering. Por exemplo, se a rede VPC local tiver uma rota de sub-rede com destino 100.64.0.0/24, nenhuma das redes VPC com peering poderá ter uma rota de sub-rede com destino 100.64.0.0/10.

O Google Cloud aplica as condições anteriores para rotas de sub-rede IPv4 nos seguintes casos:

  • Ao conectar redes VPC pela primeira vez usando peering de rede VPC.
  • Enquanto as redes estiverem com peering.
  • Quando você faz uma alteração na configuração de peering, por exemplo, ativando a importação de rotas IPv4 da sub-rede com endereços IP públicos usados de modo particular.

Enquanto você faz o peering das redes, o Google Cloud retorna um erro se alguma das operações a seguir resultar em uma sobreposição:

As rotas de sub-rede IPv6 (internas e externas) são exclusivas por definição. Nenhuma das duas redes VPC pode usar os mesmos intervalos de sub-redes IPv6 internas ou externas.

Interações de sub-rede e rotas estáticas

O Google Cloud exige que as rotas de sub-rede e as rotas de sub-rede de peering tenham os intervalos de IPv4 ou IPv6 de destino mais específicos. Em qualquer rede VPC, uma rota estática local não pode ter um destino que corresponda exatamente ou se ajuste a uma rota de sub-rede local. Para uma discussão mais detalhada sobre esse cenário, consulte Interações com rotas estáticas personalizadas.

Esse conceito é estendido para o peering de rede VPC pelas duas regras a seguir:

  • Uma rota estática local não pode ter um destino que corresponda exatamente ou se ajuste em uma rota de sub-rede com peering. Se existir uma rota estática local, o Google Cloud aplicará o seguinte:

    • Não é possível estabelecer uma nova conexão de peering com uma rede VPC que já tenha uma rota de sub-rede que corresponda exatamente ou tenha o destino da rota estática local, se a configuração de peering resultar na importação da rota de sub-rede conflitante.

      Por exemplo, se existir uma rota estática local com o destino 10.0.0.0/24, não será possível estabelecer uma nova conexão de peering com uma rede VPC com uma rota de sub-rede cujo destino corresponda exatamente a 10.0.0.0/24 ou tenha 10.0.0.0/24 (por exemplo, 10.0.0.0/8).

    • Não será possível atualizar uma conexão de peering já existente se a configuração de peering atualizada resultar na importação da rota de sub-rede conflitante.

      Por exemplo, se existir uma rota estática local com o destino 11.0.0.0/24 e existir uma rota de sub-rede com o destino 11.0.0.0/8 na rede VPC com peering, não será possível configurar a rede VPC com peering para exportar rotas de sub-rede usando endereços IPv4 públicos utilizados de modo particular e configurar a rede VPC local para importar rotas de sub-rede usando endereços IPv4 públicos utilizados de modo particular.

    • Por outro lado, se as redes VPC já estiverem conectadas usando o peering de rede VPC, não será possível realizar as seguintes operações:

      • Crie uma nova rota estática local cujo destino corresponda exatamente ou se ajuste a uma rota de sub-rede de peering importada.
      • Crie um novo intervalo de endereços de sub-rede na rede VPC com peering se esse intervalo corresponder exatamente ou tiver uma rota estática local atual.

  • Uma rota estática com peering não pode ter um destino que corresponda exatamente ou se ajuste a uma rota de sub-rede local. Se houver uma rota de sub-rede local, o Google Cloud proibirá o seguinte:

    • Não é possível estabelecer uma nova conexão de peering com uma rede VPC que já contenha uma rota estática que corresponda exatamente ou se ajuste ao destino da rota de sub-rede da rede VPC local, se a configuração de peering resultar em importação da rota personalizada do peering.

      Por exemplo, se existir uma rota de sub-rede local para 10.0.0.0/8, não será possível estabelecer uma conexão de peering com uma rede VPC com uma rota estática cujo destino corresponda exatamente a 10.0.0.0/8 ou se ajuste a 10.0.0.0/8 (por exemplo, 10.0.0.0/24).

    • Não será possível atualizar uma conexão de peering já existente se a configuração de peering atualizada resultar na importação da rota estática conflitante.

    • Por outro lado, se as redes VPC já estiverem conectadas usando o peering de rede VPC, não será possível realizar as seguintes operações:

      • Crie uma nova rota de sub-rede local com um destino que corresponda exatamente ou tenha uma rota estática de peering importada.
      • Crie uma nova rota estática na rede VPC com peering cujo destino corresponderia exatamente ou se ajustaria a uma rota de sub-rede local atual.

Efeitos do modo de roteamento dinâmico

O modo de roteamento dinâmico de uma rede VPC determina as regiões em que os prefixos aprendidos dos Cloud Routers dessa rede são aplicados como rotas dinâmicas personalizadas locais. Para mais detalhes sobre esse comportamento, consulte Efeitos do modo de roteamento dinâmico.

Este conceito é estendido para o peering de rede VPC. O modo de roteamento dinâmico da rede VPC exportadora, que contém os Cloud Routers que aprenderam os prefixos para essas rotas dinâmicas, determina as regiões em que as rotas dinâmicas com peering podem ser programadas em redes de peering:

  • Se o modo de roteamento dinâmico da rede VPC exportadora for regional, essa rede exportará rotas dinâmicas apenas na mesma região dos Cloud Routers que aprenderam os prefixos.

  • Se o modo de roteamento dinâmico da rede VPC exportadora for global, essa rede exportará rotas dinâmicas em todas as regiões.

Em ambos os casos, o modo de roteamento dinâmico da rede VPC importadora não é relevante.

Para um exemplo que ilustra esse comportamento, consulte Rede VPC local e rede VPC de peering com conectividade local.

Interações de sub-rede e rota dinâmica

Os conflitos entre rotas de sub-rede locais ou de peering e rotas dinâmicas são resolvidos conforme descrito em Interações com rotas dinâmicas personalizadas.

Exemplos de peering de rede VPC

Os exemplos a seguir demonstram dois cenários comuns de peering de rede VPC.

Rede VPC local e rede VPC de peering com conectividade local

Neste exemplo, o peering de rede a seguir está configurado:

  • network-a está em peering com network-b, e network-b está em peering com network-a.
    • network-a tem uma sub-rede cujo intervalo de endereços IPv4 principal é 10.0.0.0/24 em us-west1.
    • network-a tem uma sub-rede cujo intervalo de endereços IPv4 principal é 10.0.1.0/24 em europe-north1.
    • network-b tem uma sub-rede cujo intervalo de endereços IPv4 principal é 10.0.2.0/23 em us-west1.
  • network-b está conectado a uma rede local com túneis do Cloud VPN usando roteamento dinâmico. Os mesmos princípios se aplicam caso os túneis sejam substituídos por anexos da VLAN do Cloud Interconnect.
    • Para fornecer conectividade do local às sub-redes em network-a e network-b, o Cloud Router em network-b precisa ser configurado para usar divulgação de rota personalizada. Por exemplo, o Cloud Router anuncia apenas o prefixo personalizado 10.0.0.0/22, que inclui o intervalo de sub-rede 10.0.2.0/23 de network-b e os intervalos de sub-rede 10.0.0.0/24 e 10.0.1.0/24 de network-a.
    • O Cloud Router em us-west1 aprende o prefixo 10.0.0.0/8 de um roteador local. 10.0.0.0/8 não cria conflitos porque é mais ampla do que as rotas de sub-rede e de sub-rede de peering. Em outras palavras, 10.0.0.0/8 não corresponde exatamente e não se ajusta a nenhuma rota de sub-rede ou de sub-rede de peering.
  • A conexão de peering para network-b está configurada para exportar rotas personalizadas, e a conexão de peering para network-a está configurada para importar rotas personalizadas.

Independentemente do modo de roteamento dinâmico de network-a, as seguintes características de roteamento se aplicam:

  • Quando o modo de roteamento dinâmico de network-b é global, os prefixos locais (10.0.0.0/8) aprendidos pelo Cloud Router em network-b são adicionados como rotas dinâmicas em todas as regiões de network-b e como rotas dinâmicas de peering em todas as regiões de network-a. Se as regras de firewall estiverem configuradas corretamente, vm-a1, vm-a2 e vm-b poderão se comunicar com um recurso local com endereço IP 10.5.6.7.

  • Se o modo de roteamento dinâmico de network-b for alterado para regional, os prefixos locais (10.0.0.0/8) aprendidos pelo Cloud Router em network-b serão adicionados apenas como rotas dinâmicas na região us-west1 de network-b e como rotas dinâmicas de peering na região us-west1 de network-a. Se as regras de firewall estiverem configuradas corretamente, somente vm-a1 e vm-b poderão se comunicar com um recurso local com endereço IP 10.5.6.7 porque essa é a única VM na mesma região do Cloud Router.

Rede de transporte público

No exemplo a seguir, network-b atua como uma rede de transporte público.

  • network-a está em peering com network-b, e network-b está em peering com network-a
  • network-c está em peering com network-b, e network-b está em peering com network-c
  • network-b está conectado a uma rede local com túneis do Cloud VPN usando roteamento dinâmico. Os mesmos princípios se aplicam caso os túneis sejam substituídos por anexos da VLAN do Cloud Interconnect.
    • Para fornecer conectividade do local para sub-redes em network-a, network-b e network-c, o Cloud Router em network-b precisa ser configurado para usar divulgação de rota personalizada. Por exemplo, o Cloud Router divulga rotas de sub-redes de network-b e prefixos personalizados que abrangem rotas de sub-rede em network-a e network-c.
    • Sujeito às interações de sub-rede e rota dinâmica, o Cloud Router em network-b aprende os prefixos locais e cria rotas dinâmicas em network-b.
  • As conexões de peering de network-b para network-a e de network-b para network-c foram configuradas para exportar rotas personalizadas. As conexões de peering de network-a para network-b e de network-c para network-b foram configuradas para importar rotas personalizadas.

Se os firewalls estiverem configurados corretamente, os seguintes cenários de conectividade podem acontecer:

  • As instâncias de VM em network-a podem alcançar outras VMs em network-b e sistemas locais.
  • As instâncias de VM em network-c podem alcançar outras VMs em network-b e sistemas locais.
  • As instâncias de VM em network-b podem acessar outras VMs em network-a e network-c, bem como em sistemas na rede local.

Como o peering de rede VPC não é transitivo, as instâncias de VM em network-a e network-c não podem se comunicar, a menos que você também conecte as redes network-a e network-c usando o peering de rede VPC.

A seguir