Perguntas frequentes sobre o Cloud Interconnect

Neste documento, abordaremos perguntas frequentes sobre os recursos e a arquitetura do Cloud Interconnect, agrupados nas seguintes seções principais:

Tráfego por meio do Cloud Interconnect

Nesta seção, abordaremos perguntas sobre tipos de tráfego, largura de banda e criptografia por meio do Cloud Interconnect.

Que tipo de pacotes são transportados pelo Cloud Interconnect?

O circuito Cloud Interconnect transporta frames Ethernet 802.1q com pacotes IPv4 no payload. Eles também são conhecidos como frames Ethernet com tags VLAN.

O valor do campo ID da VLAN (VID, na sigla em inglês) de 12 bits do cabeçalho 802.1q é igual ao valor atribuído pelo Google Cloud quando um anexo de interconexão (VLAN) é criado. Para mais informações, consulte estes documentos:

Como criptografar o tráfego por meio do Cloud Interconnect?

Dependendo do serviço que é acessado usando o Cloud Interconnect, seu tráfego já pode estar criptografado sem a necessidade de fazer algo especial. Por exemplo, se você estiver acessando uma das APIs do Google Cloud pelo Cloud Interconnect, esse tráfego já estará criptografado com TLS (em inglês). Isso é feito como se as APIs fossem acessadas pela Internet pública.

Também é possível usar a solução TLS para os serviços que você cria. Por exemplo, um serviço oferecido em uma instância do Compute Engine ou em um pod do Google Kubernetes Engine que ofereça suporte ao protocolo HTTPS.

Também é possível usar a solução TLS para os serviços que você cria. Por exemplo, um serviço oferecido em uma instância do Compute Engine ou em um pod do Google Kubernetes Engine que ofereça suporte ao protocolo HTTPS. Por exemplo, execução de uma VPN StrongSwan em uma instância do Compute Engine. É possível, então, encerrar os túneis IPsec para esses gateways VPN por meio do Cloud Interconnect de seu próprio local.

Para mais detalhes, consulte a documentação da criptografia em trânsito.

Posso criar uma conexão de 100 G por meio da Interconexão dedicada?

Sim, é possível escalonar a conexão com o Google de acordo com suas necessidades.

Uma conexão do Cloud Interconnect consiste em um ou mais circuitos implantados como um grupo de links de canal de porta Ethernet (LAG). Os circuitos em uma conexão podem ser de 10 ou 100 Gbps, mas não ambos.

Uma conexão pode ter uma das seguintes capacidades máximas:

  • 8 circuitos de 10 Gbps (80 Gbps no total)
  • 2 circuitos de 100 Gbps (200 Gbps no total)

A Interconexão dedicada ou por parceiro é compatível com capacidades de anexo de interconexão (VLAN) de 50 Mbps a 50 Gbps.

É possível solicitar mais de uma conexão e usá-las de maneira ativa-ativa ao aproveitar os recursos de roteamento do BGP do Cloud Router.

Para conseguir uma lista detalhada de capacidades, cotas e limites, consulte as páginas de preços e de cotas do Cloud Interconnect.

Posso acessar minhas instâncias usando IPv6 por meio do Cloud Interconnect?

O VPC não oferece um recurso nativo para encerrar o tráfego IPv6 para instâncias.

Posso especificar o endereço IP de peering do BGP?

  • Isso não é possível na interconexão por parceiro. Os endereços IP de peering são escolhidos pelo Google.
  • Para Interconexão dedicada, é possível especificar um intervalo de endereços IP (bloco CIDR) que o Google seleciona quando você cria um anexo de interconexão (VLAN). O bloco CIDR precisa estar no intervalo de endereços IP do link local 169.254.0.0/16.

Posso acessar as APIs do Google por meio do Cloud Interconnect no local? Quais serviços ou APIs estão disponíveis?

Há duas maneiras de acessar as APIs do Google.

Com a Opção 1, é possível ativar o Acesso privado do Google para uma ou mais sub-redes na rede VPC e implantar uma ou mais instâncias de proxy reverso nessas sub-redes. Esses proxies reversos têm apenas o IP particular da VPC configurado e, portanto, podem ser acessados somente por meio do link do Cloud Interconnect no local. Com essa solução, você recebe a maior parte do acesso às APIs do Cloud e de desenvolvedor e à maioria dos serviços do Google Cloud.

Consulte Como configurar o Acesso privado do Google para ver mais detalhes, incluindo uma lista de serviços do GCP com suporte ao Acesso privado do Google.

Com a Opção 2, é possível aproveitar o Acesso privado do Google para hosts locais. Nesse caso, as solicitações de hosts locais precisam ser enviadas a restricted.googleapis.com, que é resolvido de forma persistente para o intervalo de IPs 199.36.153.4/30, também conhecido como intervalo VIP restrito.

Adicione uma rota personalizada ao Cloud Router para anunciar o intervalo VIP restrito. Isso garante que o tráfego para o VIP restrito (como destino) seja roteado do local para os endpoints da API por meio do Cloud Interconnect. Somente as APIs e os serviços do Google que oferecem suporte a VIP restrito podem ser acessados com essa solução.

Para ver informações mais recentes sobre detalhes de configuração e serviços com suporte, consulte Como configurar o Acesso privado do Google para hosts locais.

Posso usar o Cloud Interconnect como um canal privado para acessar todos os serviços do G Suite por meio de um navegador?

A partir de dezembro de 2018, não é possível acessar os aplicativos do G Suite por meio do Cloud Interconnect.

Por que minhas sessões de BGP oscilam continuamente após determinado intervalo?

Verifique se há uma máscara de sub-rede incorreta no intervalo de IPs do BGP no local. Por exemplo, em vez de configurar 169.254.10.0/29, talvez você tenha definido 169.254.10.0/30.

É possível enviar e aprender valores MED por meio de uma conexão de interconexão por parceiro L3

Se você estiver usando uma conexão de Interconexão por parceiro na qual um parceiro de nível 3 gerencie o BGP para você, o Cloud Router não poderá aprender valores MED do seu roteador local ou enviar valores MED para esse roteador. Isso ocorre porque os valores MED não podem passar por sistemas autônomos. Isso significa que, nesse tipo de conexão, não é possível definir prioridades para rotas anunciadas pelo Cloud Router para o roteador local e também não é possível definir prioridades de rota para rotas anunciadas pelo roteador local para a rede VPC.

Arquitetura do Cloud Interconnect

Nesta seção, abordaremos perguntas comuns que surgem ao criar ou usar uma arquitetura do Cloud Interconnect.

Posso usar o Cloud Interconnect para me conectar à Internet pública?

Desde dezembro de 2018, as rotas da Internet não são mais divulgadas pelo Cloud Interconnect.

Como me conecto ao Google Cloud se eu estiver em um local POP não listado na página Como escolher um local de instalação de colocation?

Você tem duas opções, após as quais é possível passar pelo processo normal de pedido e provisionamento da Interconexão dedicada:

  • É possível solicitar linhas alugadas de uma operadora para se conectar do seu ponto de presença (POP, na sigla em inglês) a uma das instalações de colocation do Cloud Interconnect do Google. Geralmente, é melhor entrar em contato com o provedor da instalação de colocation atual e conseguir uma lista de provedores "on-net". Um provedor "on-net" é aquele que já tem infraestrutura no prédio em que você está localizado, tornando essa opção mais barata e mais rápida do que usar um provedor diferente que precisa criar infraestrutura para localizar você em seu POP atual.
  • Outra opção é usar o Partner Interconnect com uma operadora parceira que ofereça um circuito Last Mile (última milha) para localizar você. Provedores de colocation geralmente não podem fornecer esse tipo de serviço porque têm locais fixos onde você já precisa estar presente.

Se eu usar o Partner Interconnect, verei a interconexão no projeto em que crio o anexo de interconexão (VLAN)?

Quando você usa o serviço de Interconexão por parceiro, o objeto de interconexão é criado no projeto dele e não fica visível em seu projeto. O anexo de interconexão (VLAN) ainda fica visível no projeto, como no caso do Cloud Interconnect.

Como faço para criar uma arquitetura redundante que aproveite o Cloud Interconnect?

Dependendo do SLA desejado, há arquiteturas específicas que precisam ser implementadas tanto para a Interconexão dedicada quanto para o Partner Interconnect.

As topologias para arquiteturas prontas para produção com um SLA de 99,99% e para aplicativos não críticos com um SLA de 99,9% estão disponíveis em /network-connectivity/docs/interconnect/docs/tutorials.

Esses níveis de SLA referem-se à disponibilidade do Cloud Interconnect, que é a disponibilidade da conexão roteada entre a localização no local e a rede VPC. Por exemplo, se você criar um serviço nas instâncias do Compute Engine que pode ser acessado pelo Cloud Interconnect, a disponibilidade do serviço dependerá da disponibilidade combinada de ambos os serviços do Cloud Interconnect e do Compute Engine.

  • Na Interconexão dedicada, uma interconexão única (pacote LACP) tem um SLA sem tempo de atividade.
  • Na Interconexão por parceiro, um anexo de interconexão (VLAN) único tem um SLA sem tempo de atividade.

Os problemas de falhas de pacote/interconexão única são tratados em uma prioridade de histórico de consultas não superior a P3: impacto médio, uso de serviço parcialmente reduzido. Portanto, não é possível esperar uma resolução rápida ou análise posterior da causa raiz.

Devido à manutenção planejada ou não planejada, os links ou pacotes únicos podem ser drenados mesmo por longos períodos de tempo, como horas ou dias.

Posso encaminhar o tráfego por meio do Cloud Interconnect entre meu aplicativo legado local e meus back-ends do balanceador de carga interno?

Neste cenário, você implantou um aplicativo que consiste em duas camadas: uma local que ainda não foi migrada para o Google Cloud (camada legada) e uma de nuvem em execução nas instâncias de VPC que também são back-ends de um balanceador de carga interno (ILB, na sigla em inglês) do Google Cloud.

É possível usar o Cloud Interconnect para encaminhar o tráfego entre essas duas camadas de aplicativos, desde que você implemente as rotas necessárias entre o Cloud Router e seu roteador local. O Cloud Router usado para o Cloud Interconnect que processa o tráfego desse aplicativo precisa residir na mesma região da sub-rede que contém os back-ends do ILB. Isso ocorre porque o ILB oferece suporte apenas ao roteamento regional, e o acesso ao ILB é perdido quando o Roteamento global para o VPC usa um túnel fora da região onde os back-ends do ILB estão localizados. Consulte Como usar o Cloud VPN ou o Interconnect para mais informações.

Se o tráfego local entrar na rede VPC de uma região diferente, será possível implantar um ILB com os respectivos back-ends na outra região ou rotear o tráfego para um proxy reverso do qual o VIP do ILB pode ser acessado.

Posso transferir uma ou mais instâncias do Cloud Interconnect entre organizações ou projetos do Google Cloud?

Se você quiser transferir um projeto para uma nova organização do Google Cloud, abra um caso de suporte, e o Cloud facilitará o processo.

Interconexão dedicada e anexos de interconexão (VLANs) não são afetados por mudanças de organização, desde que o projeto permaneça o mesmo.

Para alterações de projeto, se você estiver executando uma ativação do Cloud Interconnect e tiver uma procuração, mas ainda não tiver concluído a ativação, cancele a ativação atual e crie uma nova no projeto correto. O Google emite uma nova procuração, que pode ser fornecida ao seu provedor de conexão cruzada.

No entanto, não é possível mover uma interconexão ativa do Cloud Interconnect entre projetos porque se trata de um objeto filho do projeto, e não há capacidade de migrar objetos automaticamente entre projetos. Se possível, inicie uma solicitação para uma nova interconexão do Cloud Interconnect.

Como posso usar a mesma interconexão do Cloud Interconnect para conectar várias redes VPC em diversos projetos dentro da mesma organização do Google Cloud?

A especificação de um anexo da VLAN atual em um projeto diferente do Cloud Interconnect ao qual ele está anexado é compatível com Interconexão dedicada e Partner Interconnect.

Para Partner Interconnect

Se você tiver vários anexos de interconexão (VLANs), incluindo aqueles em projetos diferentes, será possível emparelhá-los com uma conexão do Partner Interconnect do mesmo provedor de serviços, ou então com conexões do Partner Interconnect de diferentes provedores de serviços.

Para Interconexão dedicada

Durante a configuração de todos os anexos, se você tiver muitos projetos, poderá atribuir a cada um deles o próprio anexo de interconexão (VLAN) e o próprio Cloud Router para usar a mesma Interconexão dedicada física em um projeto especificado.

O anexo de interconexão (VLAN), além de ser uma VLAN com um código 802.1q, é um objeto filho de uma interconexão do Cloud Interconnect atual em um projeto.

Neste modelo, cada rede VPC tem sua própria configuração de roteamento. Se você quiser centralizar as políticas de roteamento, poderá revisar o Modelo de VPC compartilhado e as Considerações de VPC compartilhado e encerrar o anexo de interconexão (VLAN) na rede VPC do projeto de host de VPC compartilhado. O projeto de host tem uma cota para o número máximo de anexos de interconexão (VLANs) por interconexão do Cloud Interconnect. Para mais detalhes, consulte a página "Cotas" do Cloud Interconnect.

Posso usar uma única interconexão do Cloud Interconnect para conectar vários sites locais à minha rede VPC?

É possível fazer isso facilmente. Por exemplo, se os vários sites fizerem parte de uma rede VPN MPLS, autogerenciada ou gerenciada por uma operadora, será possível "adicionar logicamente" a rede VPC como um site adicional usando uma abordagem semelhante a Inter-AS MPLS VPN Option A. Consulte o RFC 4364, Parágrafo 10 (em inglês).

Esta solução está descrita na resposta para fazer uma rede VPC aparecer no serviço VPN MPLS de um parceiro. Aproveitando os recursos de BGP do Cloud Router, é possível injetar rotas de VPC em uma estrutura de núcleo de IP atual usando técnicas e arquiteturas semelhantes às usadas para importar rotas da Internet.

Posso "interligar" fisicamente o Cloud Interconnect e uma interconexão de outro provedor de nuvem?

Se você já estiver usando outro provedor de nuvem que ofereça um serviço com função equivalente ao Cloud Interconnect, não haverá configuração em comum entre os provedores de nuvem para "interligar" fisicamente as duas interconexões, uma fornecida pelo Google Cloud e uma pelo outro provedor de nuvem. No entanto, é possível rotear entre o espaço de endereço particular da rede VPC e a rede de um provedor de nuvem diferente.

Se o ponto de transferência de serviço do outro provedor de nuvem estiver no mesmo local que o Cloud Interconnect, será possível provisionar seu próprio roteador nesse local para encerrar os dois serviços de interconexão. Em seguida, o roteador será roteado entre a rede VPC e a rede do outro provedor de nuvem. Essa configuração permite rotear diretamente das duas redes em nuvem para sua rede local com um mínimo de atraso.

Algumas operadoras do Partner Interconnect podem oferecer isso como um serviço gerenciado, com base em um roteador virtual. Se o Google Cloud e o outro provedor de nuvem encerrarem os serviços de interconexão em locais diferentes, será preciso fornecer um circuito que conecte os dois locais.

Como posso conectar a AWS e o Google Cloud sem colocar o equipamento em uma instalação próxima à borda do Google?

O Megaport oferece a própria solução de roteador na nuvem (em inglês) para clientes do Google Cloud que não querem colocar o hardware perto da borda do Google. Consulte as instruções de configuração (em inglês) desse produto com o Google Cloud.

Anexos de interconexão (VLANs)

Nesta seção, abordamos questões sobre anexos de interconexão (VLANs).

Como posso escolher o código VLAN usado para um anexo de interconexão (VLAN)?

Para um anexo de interconexão criado com o Partner Interconnect, o parceiro escolhe o código VLAN durante o processo de criação do anexo ou permite que você o escolha. Verifique com seu parceiro se ele permite que você escolha o código VLAN para anexos de interconexão.

Para um anexo de interconexão criado com a Interconexão dedicada, use o comando gcloud compute interconnects attachments create com a sinalização --vlan. Se preferir, siga as instruções do Console do Google Cloud.

Veja no exemplo a seguir o uso do comando gcloud para alterar o ID da VLAN para 5:

gcloud compute interconnects attachments dedicated create my-attachment \
  --router my-router \
  --interconnect my-interconnect \
  --vlan 5 \
  --region us-central1

Para instruções completas, consulte um dos documentos a seguir:

Posso usar o Cloud Router com mais de um anexo de interconexão?

Sim, essa é uma configuração compatível.

MPLS

Nesta seção, abordamos questões sobre o Cloud Interconnect e o MPLS.

Posso usar o Cloud Interconnect para encerrar um MPLS LSP dentro da minha rede VPC?

Desde dezembro de 2018, a VPC não oferece mais recursos nativos no Google Cloud para encerrar o LSP de MPLS.

Em um serviço de VPN de MPLS autogerenciado, posso fazer com que minha rede VPC apareça como um site extra?

Se você tiver um serviço de VPN MPLS que gerencia sozinho, será possível fazer com que sua rede VPC apareça como um site adicional que consiste em uma VPN autogerenciada.

Este cenário pressupõe que você não está comprando um serviço de VPN MPLS de um provedor. Em vez disso, você tem um ambiente VPN MPLS onde gerencia e configura sozinho os roteadores P e PE da rede MPLS.

Para que sua rede VPC apareça como um site adicional em seu serviço de VPN MPLS autogerenciado, faça o seguinte:

  1. Conecte um dos seus dispositivos de borda PE de VPN de MPLS ao dispositivo de borda de peering da Interconexão dedicada. Basta usar um modelo muito semelhante a Inter-AS MPLS VPN Option A. Consulte o parágrafo 10 do RFC 4364(em inglês). Em outras palavras, encerre a VPN de MPLS-VPN necessária, como a VRF_A, no dispositivo de borda PE. Em seguida, use o mapeamento de VLAN em VRF para "unir" o anexo de interconexão (VLAN) do Google Cloud a essa VPN, basicamente mapeando a VLAN em VRF_A no dispositivo de borda PE.

  2. Crie uma sessão BGP IPv4 padrão entre o roteador PE e o Cloud Router para garantir que as rotas sejam trocadas entre eles. As rotas enviadas pelo Cloud Router aparecerão apenas na tabela de roteamento da VPN (dentro de VRF_A), e não na tabela de roteamento global do dispositivo de borda PE.

    É possível criar várias VPNs separadas para gerenciar intervalos de IPs sobrepostos. Por exemplo, VRF_A e VRF_B, cada um com uma sessão BGP para o Cloud Router em uma rede VPC específica, como VPC_A e VPC_B. Esse procedimento não requer nenhum encapsulamento MPLS entre o dispositivo de borda PE e o de peering na Interconexão dedicada.

Posso fazer com que a minha rede VPC apareça como um site adicional na minha VPN MPLS de uma operadora que também seja parceira do Partner Interconnect?

Se você comprar um serviço de VPN MPLS de uma operadora que também é parceira oficial do Partner Interconnect, será possível fazer com que sua rede VPC apareça como um site adicional na sua VPN MPLS.

Nesse caso, o provedor gerencia e configura os roteadores P e PE da rede MPLS deles. Como o Partner Interconnect usa exatamente o mesmo modelo de conectividade que a Interconexão dedicada, a operadora pode aproveitar um modelo muito semelhante a Inter-AS MPLS VPN Option A. Consulte o RFC 4364, Parágrafo 10 (em inglês).

Essencialmente, a operadora fornece a você um serviço do Partner Interconnect de Camada 3 e, em seguida, "vincula" seu anexo de interconexão (VLAN) à VPN MPLS correta no dispositivo de borda da operadora. Consulte a Visão geral do Partner Interconnect para ver detalhes. Como esse é um modelo de serviço de Camada 3, a sessão do BGP é estabelecida entre seu Cloud Router e seu VRF dentro do dispositivo de borda da operadora.