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. Esses frames também são conhecidos como frames Ethernet com tag VLAN.

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

Como posso criptografar meu 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 Platform acessíveis pelo Cloud Interconnect, esse tráfego já estará criptografado com o TLS como se as APIs tivessem sido 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.

Se você precisar de criptografia na camada IP, poderá criar um ou mais gateways VPN autogerenciados (não GCP) em sua rede de nuvem privada virtual e atribuir um endereço IP particular a cada gateway. 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 ver mais detalhes, consulte a documentação de criptografia em trânsito.

Posso criar um pipe 100G por meio de Interconexão dedicada?

A partir de dezembro de 2018, o tamanho máximo de uma única interconexão do Cloud Interconnect é de 80G, que é implantado como um link de canal de porta 8 x 10GE (grupo LAG). É possível solicitar mais de uma interconexão do Cloud Interconnect e usá-las de forma ativa-ativa aproveitando os recursos de roteamento do BGP do Cloud Router. Para ver as informações mais recentes, fale com seu representante de vendas do Google sobre a disponibilidade de portas 100GE.

A partir de dezembro de 2018, a capacidade máxima de um anexo de interconexão (VLAN) é de 10 Gbps. Para ver informações atualizadas, consulte a página "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 preservar valores IP DSCP por meio de Interconexão dedicada?

A Interconexão dedicada preserva os valores IP DSCP originais de ponta a ponta.

Se você definir o valor IP DSCP no tráfego enviado para sua rede VPC pela Interconexão dedicada, esse valor será preservado e permanecerá inalterado em suas instâncias.

Se definir o valor IP DSCP no tráfego de saída gerado de uma instância que atravessa a Interconexão dedicada, o valor será preservado no destino.

Se estiver usando o Partner Interconnect, verifique com seu parceiro se os valores IP DSCP são preservados na conexão do Partner.

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, a maior parte do acesso às Cloud APIs, às APIs de desenvolvedor e à maioria dos serviços do GCP é concedida.

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 para restricted.googleapis.com, que é resolvido persistentemente 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 particular 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, 169.254.10.0/30 pode ter sido configurado.

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?

A partir de dezembro de 2018, as rotas da Internet não são anunciadas pelo Cloud Interconnect.

Como posso me conectar ao GCP se eu estiver em um local POP não listado na página "Instalações de colocation" do Cloud Interconnect?

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 de seu local de ponto de presença (POP, na sigla em inglês) a um dos locais de Instalação 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.

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.

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 https://cloud.google.com/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.

Posso encaminhar o tráfego por meio do Cloud Interconnect entre o 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 camada local que ainda não foi migrada para o GCP (camada legada) e uma camada 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 GCP.

É 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 implantar o balanceamento de carga interno com clientes por VPN ou Interconnect para ver 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 mover uma ou mais instâncias do Cloud Interconnect entre projetos ou organizações do GCP?

Se você quer mover um projeto para uma nova organização do GCP, é possível abrir um caso de suporte, e o Suporte do Cloud pode facilitar a mudança.

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 vários projetos dentro da mesma organização do GCP?

É possível especificar uma interconexão do Cloud Interconnect que existe em um projeto diferente daquele no qual o anexo de interconexão (VLAN) é criado.

Se você tiver muitos projetos, será possível fornecer a cada um seu próprio anexo de interconexão (VLAN) e seu próprio Cloud Router ao configurar todos os anexos para usar a mesma interconexão física do Cloud Interconnect 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ê quer centralizar as políticas de roteamento, é possível revisar o modelo de VPC compartilhada e as considerações de VPC compartilhada e encerrar o anexo de interconexão (VLAN) na rede VPC do projeto de host de VPC compartilhada. 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 ver detalhes, consulte a página de 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 acordada entre os provedores de nuvem para "interligar" fisicamente duas interconexões, uma fornecida pelo GCP 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 GCP e o outro provedor de nuvem encerrarem 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 GCP sem colocar equipamento em uma instalação próxima à borda do Google?

O Megaport oferece sua própria solução de roteador na nuvem para clientes do GCP que não querem colocar o hardware perto da borda do Google. Veja as instruções de configuração sobre como configurar esse produto com o GCP.

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, é possível usar o comando gcloud compute interconnects attachments create com a sinalização --vlan ou seguir as instruções do Console do Google Cloud Platform.

O exemplo a seguir mostra o uso do comando gcloud para alterar o código VLAN para 5:

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

Para ver instruções completas, consulte um dos seguintes documentos:

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?

A partir de dezembro de 2018, a VPC não oferece uma capacidade nativa no GCP para encerrar o MPLS LSP.

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

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 VPN MPLS PE ao seu dispositivo de borda de peering para o Cloud Interconnect - Dedicado usando um modelo muito semelhante a Inter-AS MPLS VPN Option A. Consulte o RFC 4364, Parágrafo 10 (em inglês). Em outras palavras, é possível encerrar a VPN MPLS-VPN necessária, por exemplo, VRF_A, em seu dispositivo de borda PE e, em seguida, usar o mapeamento de VLAN para VRF para "unir" o anexo de interconexão (VLAN) do GCP a essa VPN, basicamente mapeando a VLAN para 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 gerenciar intervalos de IPs sobrepostos criando várias VPNs separadas. 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 dispositivo de borda de peering para 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…