Termos importantes

Nesta página, você encontra a terminologia principal que se aplica aos produtos de conectividade de rede. Analise esses termos para entender melhor como cada produto funciona.

Termos do Google Cloud

A terminologia a seguir se aplica ao Google Cloud e aos recursos dele.

Google Cloud
O Google Cloud é um conjunto de serviços de computação em nuvem pública oferecidos pelo Google. Para mais informações, consulte Produtos do Google Cloud.
ID do projeto
O ID do seu projeto do Google Cloud. Um projeto contém recursos de rede, como redes, sub-redes e gateways do Cloud VPN, conforme descrito na Visão geral da rede VPC. Para conferir uma descrição da diferença entre o nome do projeto, o ID do projeto e o número do projeto, consulte Como identificar projetos. É possível visualizar o ID do projeto no Console do Google Cloud.

Termos do Cloud VPN

Os termos a seguir se aplicam aos gateways e túneis do Cloud VPN e aos gateways na sua rede de peering.

Gateway do Cloud VPN
Um gateway de VPN virtual em execução no Google Cloud gerenciado pelo Google, que utiliza uma configuração especificada no projeto e é usado apenas por você. Cada gateway do Cloud VPN é um recurso regional que usa um ou mais endereços IP externos regionais. Um gateway do Cloud VPN pode se conectar a um gateway de VPN de peering.
VPN clássica
O antecessor da VPN de alta disponibilidade. Para mais informações, consulte Tipos de Cloud VPN: VPN clássica.
VPN de alta disponibilidade
Substitui a VPN clássica por um gateway que fornece um SLA de disponibilidade de 99,99%. Para mais informações, consulte Tipos de Cloud VPN: VPN de alta disponibilidade.
Gateway de VPN externo
Um recurso de gateway que você configura no Google Cloud para VPN de alta disponibilidade que fornece informações ao Google Cloud sobre seu gateway ou gateways de VPN de peer. Dependendo das recomendações de alta disponibilidade do fornecedor do gateway da VPN de peering, é possível criar um recurso de gateway de VPN externo para os diferentes tipos de gateways da VPN de peering descritos nas topologias do Cloud VPN.
Gateway de VPN de peering
Um gateway conectado a um gateway do Cloud VPN. Um gateway de VPN de peering pode ser um dos seguintes:
  • outro gateway do Cloud VPN;
  • um gateway de VPN hospedado por outro provedor de nuvem, como AWS ou Microsoft Azure;
  • Um dispositivo de VPN local ou serviço de VPN
Endereço IP de peering remoto

Para uma interface de gateway de VPN de alta disponibilidade que se conecta a um gateway de VPN externo, o endereço IP de peering remoto é o endereço IP da interface no gateway de VPN externo usado para o túnel.

Para uma interface de gateway de VPN de alta disponibilidade que se conecta a outro gateway de VPN de alta disponibilidade, o endereço IP de peering remoto é o endereço IP da outra interface do gateway de VPN de alta disponibilidade usada para o túnel.

Para a VPN clássica, o endereço IP de peering remoto é o endereço IP externo do gateway da VPN de peering.

Túnel VPN
Um túnel de VPN conecta dois gateways da VPN e serve como meio virtual de passagem do tráfego criptografado. Dois túneis de VPN devem ser estabelecidos para criar uma conexão entre dois gateways de VPN: cada túnel define a conexão a partir da perspectiva do gateway, e o tráfego só pode passar depois que o par de túneis é estabelecido. Um túnel do Cloud VPN está sempre associado a um recurso de gateway específico do Cloud VPN.
Conexão
Conforme definido para o Google Cloud, uma vinculação lógica entre os locais do Cloud VPN e da VPN de peering, identificados por um recurso vpnGateway em uma extremidade e por um externalVpnGateway ou outro recurso VpnGateway do Google Cloud no final do peering. Uma conexão também inclui todos os recursos do vpnTunnel e sessões do BGP entre os recursos do gateway.
Internet Key Exchange (IKE)
O IKE é o protocolo usado para autenticação e para negociação de uma chave de sessão para criptografar o tráfego.
MTU do gateway do Cloud VPN
O tamanho em bytes do maior pacote IP, incluindo cabeçalhos, dados e sobrecarga de IPSec, compatível com um túnel do Cloud VPN.
MTU de payload do Cloud VPN
O tamanho em bytes do maior pacote IP, incluindo cabeçalhos e dados, que pode ser criptografado e enviado em um túnel do Cloud VPN sem fragmentação. Em outras palavras, o tamanho do pacote original não conta a sobrecarga do IPSec.
VPN de alta disponibilidade sobre MTU do gateway do Cloud Interconnect
O tamanho em bytes do maior pacote IP, incluindo cabeçalhos, dados e sobrecarga de IPsec, com suporte em uma VPN de alta disponibilidade pelo túnel do Cloud Interconnect.
VPN de alta disponibilidade sobre MTU de payload do Cloud Interconnect
O tamanho em bytes do maior pacote de IP, incluindo cabeçalhos e dados, que pode ser criptografado e enviado em uma VPN de alta disponibilidade pelo túnel do Cloud Interconnect sem fragmentação. Em outras palavras, o tamanho do pacote original sem contar a sobrecarga do Cloud Interconnect e a sobrecarga de IPsec.

Termos do Cloud Interconnect

A terminologia da chave a seguir descreve os conceitos relacionados à criação do Cloud Interconnect. Cada seção indica se um termo se aplica à Interconexão dedicada, Interconexão por parceiro, Cross-Cloud Interconnect ou uma combinação deles.

Elementos do Cloud Interconnect

Conexão do Interconnect

Aplicável à Interconexão dedicada e ao Cloud Interconnect.

Para Interconexão dedicada

Uma conexão física específica entre o Google e sua rede local. Essa conexão existe em uma instalação de colocation em que sua rede local e a rede do Google se conectam.

Uma única conexão pode ser um link de 10 Gbps, um link de 100 Gbps ou um pacote de links. Se você tiver várias conexões com o Google em locais ou com dispositivos diferentes, será necessário criar conexões separadas do Interconnect.

Para Cross-Cloud Interconnect

Uma conexão física específica entre o Google e a rede de outro provedor de serviços de nuvem (o provedor de serviços de nuvem remoto). Essa conexão existe em uma única instalação de colocation ou em instalações adjacentes, nas quais as redes do Google e do provedor de serviços de nuvem remota se encontram.

Uma única conexão pode ser um link de 10 Gbps, um link de 100 Gbps ou, dependendo do que o provedor de nuvem remoto suporta, um pacote de links.

tipo de conexão
O tipo de conexão do Cloud Interconnect se encaixa em uma destas três categorias:
  • Interconexão dedicada
  • Interconexão por parceiro
  • Interconexão entre nuvens
Anexo da VLAN

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

Um anexo da VLAN (rede de área virtual) é uma conexão lógica entre uma rede externa e uma única região na sua rede de nuvem privada virtual (VPC). Na API Compute Engine, o anexo da VLAN é conhecido como um recurso interconnectAttachment.

Ao criar um anexo da VLAN, você o associa a um projeto, uma região, um Cloud Router novo ou atual e a uma conexão existente do Cloud Interconnect. Em seguida, configure uma sessão do Border Gateway Protocol (BGP) entre o Cloud Router e seu roteador externo.

  • Na Interconexão dedicada, o anexo da VLAN usa uma conexão dedicada que você cria para o roteador local.
  • Na Interconexão por parceiro, o anexo usa uma conexão que o parceiro escolhido configura e gerencia.
  • No Cross-Cloud Interconnect, o anexo usa uma conexão que o Google cria em seu nome entre as redes do Google Cloud e seu provedor de serviços de nuvem remoto.

Um anexo da VLAN não está diretamente associado a uma rede VPC. No entanto, ele está indiretamente vinculado a uma única rede VPC, porque um Cloud Router pode ser associado a apenas uma rede. Portanto, o anexo da VLAN está vinculado à rede em que o Cloud Router está localizado.

Para Interconexão dedicada

Um anexo da VLAN para a Interconexão dedicada aloca uma única VLAN 802.1Q na conexão da Interconexão dedicada e a conecta a uma rede VPC específica. Como cada conexão com a Interconexão dedicada é compatível com vários anexos da VLAN. Além disso, é possível acessar várias redes VPC sem criar várias conexões.

Cada anexo criado é associado a uma rede VPC e a uma região do Google Cloud:

  • Ao associar um anexo para a Interconexão dedicada com uma rede VPC, essa rede precisa estar em um projeto na mesma organização do projeto que contém a conexão do Interconnect.
  • O conjunto de regiões válidas para um anexo depende da instalação de colocation usada pela conexão do Cloud Interconnect.

É possível definir a capacidade de cada anexo. Para uma lista de capacidades, consulte a página Preços. A capacidade de anexos padrão é de 10 Gbps.

A configuração de capacidade limita a largura de banda máxima que um anexo pode usar. Se você tiver vários anexos em uma única conexão do Interconnect, o limite de capacidade será útil quando você quiser evitar o congestionamento de rede na conexão. A largura de banda máxima é aproximada, por isso, é possível que um anexo use um valor maior do que a capacidade selecionada.

Como a configuração de capacidade limita apenas a largura de banda da transferência de dados do Google Cloud para a instalação de colocation da conexão do Interconnect, recomendamos que você configure um limitador de taxa de transferência de dados no roteador na sua conexão. Ao configurar esse limitador, é possível restringir a largura de banda máxima da transferência de dados de entrada na sua rede VPC do tráfego que usa essa conexão.

Para Partner Interconnect

Para solicitar a conectividade da Interconexão por parceiro de um provedor de serviços, crie um anexo da VLAN no seu projeto do Google Cloud. O anexo da VLAN gera uma chave de pareamento exclusiva que você compartilha com o provedor de serviços. O provedor usa a chave de pareamento, a capacidade e o local de conexão solicitados para concluir a configuração do anexo da VLAN.

Depois que o provedor de serviços configurar o anexo, ele alocará uma VLAN 802.1q específica na conexão local.

Para Cross-Cloud Interconnect

Um anexo da VLAN para o Cross-Cloud Interconnect aloca uma única VLAN 802.1Q na conexão do Cloud Interconnect. O anexo da VLAN e o Cloud Router associado vinculam sua conexão a uma rede VPC específica. Como cada conexão do Cloud Interconnect é compatível com vários anexos da VLAN, é possível acessar várias redes VPC sem criar várias conexões.

Os seguintes requisitos são aplicáveis:

  • Ao associar um Cloud Router ao anexo da VLAN, você associa o anexo a uma rede VPC. Essa rede precisa estar no mesmo projeto que a conexão do Cloud Interconnect.
  • O conjunto de regiões válidas para um anexo depende dos locais compatíveis com o Google Cloud e do seu provedor de serviços de nuvem remoto.

Você pode selecionar uma capacidade para cada anexo. Para uma lista de capacidades, consulte a página Preços. A capacidade padrão é de 10 Gbps. Essa configuração afeta a largura de banda máxima que o anexo pode usar. Se você tiver vários anexos da VLAN, recomendamos definir uma capacidade para cada um deles. Isso pode impedir que qualquer anexo tente usar toda a largura de banda da conexão, o que pode fazer com que os pacotes sejam descartados. A largura de banda máxima é aproximada, por isso, é possível que um anexo use um valor maior do que a capacidade selecionada.

A configuração de capacidade limita apenas a largura de banda da transferência de dados de saída do Google Cloud para a instalação de colocation da conexão do Cross-Cloud Interconnect. Por esse motivo, recomendamos que você configure um limitador de taxa de transferência de dados de saída no roteador virtual na nuvem remota. Ao configurar esse limitador, é possível restringir a largura de banda máxima da transferência de dados de entrada na sua rede VPC do tráfego que usa essa conexão.

Cloud Router

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

O Cloud Router usa o Border Gateway Protocol (BGP) para trocar rotas dinamicamente entre a rede VPC e a rede local. Antes de criar um anexo da VLAN, você precisa criar ou usar um Cloud Router atual na rede VPC à qual quer se conectar. Em seguida, use o Cloud Router para configurar uma sessão do BGP com seu roteador externo.

Se você quiser ver mais informações sobre o Cloud Router, consulte a este link.

A configuração do BGP do Cloud Router varia se você estiver usando a conectividade da camada 2 ou 3. A Interconexão dedicada e o Cloud Interconnect usam apenas a conectividade da camada 2. A interconexão por parceiro pode usar conectividade de camada 2 ou camada 3.

  • Na camada 2, você estabelece uma sessão do BGP entre o Cloud Router e o roteador externo.
  • Na camada 3, o provedor de serviços estabelece uma sessão do BGP entre o Cloud Router e o respectivo roteador de extremidade. Para saber mais, consulte Conectividade da camadas 2 comparada à camada 3.

O Cloud Router anuncia sub-redes na rede VPC e propaga as rotas aprendidas para elas. A menos que você configure uma divulgação de rota personalizada, o Cloud Router anunciará as seguintes rotas:

  • Se a rede VPC usar o modo de roteamento dinâmico regional, o Cloud Router divulgará rotas de sub-rede na região em que estiver localizado.
  • Caso sua rede VPC use o modo de roteamento dinâmico global, o Cloud Router divulgará rotas de sub-rede em todas as regiões.

O Cloud Router também cria rotas dinâmicas na sua rede VPC para destinos que ele aprende com o roteador externo. Se a rede VPC usar o modo de roteamento dinâmico regional, o Cloud Router disponibilizará essas rotas apenas para a região em que ele está localizado. Se a rede usa o modo de roteamento dinâmico global, o Cloud Router disponibiliza essas rotas para todas as regiões.

Roteador local

Aplicável à Interconexão dedicada e à Interconexão por parceiro.

O roteador local é um roteador externo que estabelece uma sessão do BGP com o Cloud Router. Essa conexão permite trocar dados entre a rede local e a rede VPC.

Na Interconexão dedicada, você gerencia o roteador local, que geralmente está localizado fisicamente na instalação de colocation em que a conexão da Interconexão é provisionada. No entanto, o dispositivo pode estar fisicamente localizado em outra instalação, como um escritório onde você gerencia equipamentos de rede. Você estabelece as sessões do BGP entre seu roteador local e o Cloud Router.

Na Interconexão por parceiro, um roteador local é um dispositivo que você ou o provedor de serviços usa para configurar sessões BGP com o Cloud Router.

  • Com as conexões da Interconexão por parceiro da camada 2, você configura a sessão do BGP entre seu roteador local e o Cloud Router.
  • Com as conexões da Interconexão por parceiro de camada 3, seu provedor de serviços gerencia a sessão do BGP entre o roteador local e o Cloud Router dele.

Para mais informações sobre diferentes conexões de parceiros, consulte Conectividade das camadas 2 e 3.

Para informações sobre a configuração de roteadores locais, consulte os seguintes documentos:

roteador externo

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

Um roteador externo é um dispositivo de rede que fornece acesso à rede com que você quer fazer peering. O roteador externo pode ser um dos seguintes:

Dataplane v1

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

A versão legada da infraestrutura do Cloud Interconnect. O Dataplane v1 está sendo substituído pelo Dataplane v2. No entanto, enquanto a migração ocorre, alguns anexos da VLAN ainda podem funcionar no Dataplane v1.

Dataplane V2

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

O Cloud Interconnect Dataplane v2 é uma nova implementação da infraestrutura do Cloud Interconnect. Ele foi projetado para fornecer maior confiabilidade, desempenho e funcionalidade.

Alguns recursos de rede do Google Cloud que funcionam com o Cloud Interconnect, como a Detecção de encaminhamento bidirecional (BFD, na sigla em inglês) para o Cloud Router, exigem que os anexos da VLAN usados com o recurso sejam executados no Dataplane v2.

O Google está migrando todos os anexos da VLAN atuais para usar o Dataplane v2, sem nenhuma ação necessária da sua parte. Se você quiser usar um recurso do produto que exija o Dataplane v2 e precise atualizar a versão de um anexo da VLAN atual, entre em contato com o suporte do Google Cloud.

Todos os novos anexos da VLAN que você cria nas regiões disponíveis para o Cloud Interconnect são provisionados automaticamente no Dataplane v2.

Para ver as regiões disponíveis para o Cloud Interconnect, consulte a tabela de locais da Interconexão dedicada ou veja a lista de provedores de serviços da Interconexão por parceiro.

Para verificar a versão do Dataplane de um anexo da VLAN atual, consulte um dos seguintes documentos:

Locais do Cloud Interconnect

local da conexão ou instalação de colocation

Aplica-se ao Dedicated Interconnect, com observações para o Partner Interconnect e Cross-Cloud Interconnect.

A instalação de colocation em que uma conexão do Cloud Interconnect física é provisionada. Esse é o local em que os aparelhos locais de roteamento se conectam à extremidade de peering do Google.

Uma instalação de colocation é onde o Google tem um ponto de presença (PoP, na sigla em inglês) que permite conectar sua rede local à rede do Google. Na instalação de colocation, você precisa trabalhar com o provedor da instalação para provisionar os aparelhos de roteamento antes de usar a Interconexão dedicada.

Cada local de conexão é compatível com um subconjunto de regiões do Google Cloud. Por exemplo, lga-zone1-16 é compatível com anexos da VLAN nas regiões northamerica-northeast1, northamerica-northeast2, us-central1, us-east1, us-east4, us-east5, us-south1, us-west1, us-west2, us-west3 e us-west4.

Para ver uma lista de todos os locais e as regiões com suporte, consulte Todas as instalações de colocation.

Ao usar a Interconexão por parceiro, os parceiros já configuraram conexões com a rede do Google. O conjunto de locais varia de acordo com o parceiro que você escolher. Ao configurar seu anexo da VLAN, é possível selecionar com base nos locais disponíveis do parceiro. Para ver uma lista de locais compatíveis com cada provedor de serviços, consulte a página de provedores de serviços.

Ao usar o Cloud Interconnect, é preciso escolher um local compatível com seu provedor de serviços de nuvem remota:

Cada local do parceiro é compatível com um subconjunto de regiões do Google Cloud. É nessas regiões compatíveis que você se conecta aos roteadores do Cloud Router e anexos da VLAN associados. Por exemplo, se você escolher o local Ashburn, será possível se conectar a todas as regiões da América do Norte, como us-east1 e us-west1. Para ver uma lista de regiões do Google Cloud, consulte a página Regiões e zonas.

Provedor de serviços

Aplicável à Interconexão por parceiro.

Um provedor de serviços de rede para a Interconexão por parceiro. Para usar a Interconexão por parceiro, você precisa se conectar a um provedor de serviços autorizado. Ele fornece conectividade entre sua rede local e a rede VPC.

Área metropolitana

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

A cidade onde uma instalação de colocation está localizada.

A área metropolitana escolhida depende da localização da rede local e das instâncias de VM do Compute Engine (a região delas no Google Cloud). Normalmente, é melhor escolher uma área metropolitana geograficamente próxima à sua rede local para reduzir a latência. Ao configurar uma conexão redundante, é possível escolher outrqa área metropolitana mais distante.

Cada área metropolitana oferece suporte a um subconjunto de regiões do Google Cloud. Só é possível criar anexos da VLAN nessas regiões. Por exemplo, se você escolher uma instalação em Ashburn, só será possível criar anexos da VLAN nas regiões da América do Norte. Supondo que suas instâncias de VM também estejam localizadas nessas regiões, crie anexos de VLAN nas mesmas regiões que suas VMs para reduzir a latência e os custos de transferência de dados de saída. Caso contrário, o tráfego teria que viajar entre regiões para acessar as instâncias de VM ou a rede local.

Para saber mais sobre a Interconexão dedicada, consulte Todas as instalações de colocation.

Zona de disponibilidade na área metropolitana

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

Termo mais antigo para domínio de disponibilidade de extremidade.

Domínio de disponibilidade de borda

Aplica-se ao Dedicated Interconnect, ao Partner Interconnect e ao Cross-Cloud Interconnect.

Cada área metropolitana tem dois domínios de falha independentes chamados domínios de disponibilidade de borda. Os dois domínios de disponibilidade de borda são chamados zone1 e zone2. Eles oferecem isolamento durante a manutenção programada, o que significa que dois domínios na mesma área metropolitana não estão desativados para manutenção ao mesmo tempo. Esse isolamento é importante quando você quer aumentar a redundância.

Os domínios de disponibilidade de borda abrangem uma área metropolitana inteira e não cruzam áreas metropolitanas. Para manter a disponibilidade e um SLA, é necessário criar conexões duplicadas do Cloud Interconnect escolhendo dois locais de conexão na mesma área metropolitana que estejam em diferentes domínios de disponibilidade de borda. Algumas áreas metropolitanas oferecem mais de dois locais, mas ainda há apenas dois domínios de disponibilidade de borda na área metropolitana. Por exemplo, a criação de conexões nos locais dfw-zone1-4 e dfw-zone1-505 não oferece redundância porque os dois locais estão no domínio de disponibilidade de borda zone1. Criá-los em dfw-zone1-4 e dfw-zone2-4 proporciona redundância porque os locais estão em domínios de disponibilidade de borda diferentes.

As janelas de manutenção não são coordenadas entre áreas metropolitanas. Por exemplo, os domínios de disponibilidade de borda dfw-zone1-4 e ord-zone1-7 podem enfrentar eventos de manutenção sobrepostos. Ao se conectar a várias áreas metropolitanas por questões de redundância, é importante se conectar a diferentes domínios de disponibilidade de extremidade em cada uma dessas áreas, como descrito na topologia de produção.

Provisionamento e configuração

Carta de autorização e atribuição de instalação de conexão (LOA-CFA)

Aplicável à Interconexão dedicada.

Uma LOA-CFA identifica as portas que o Google atribuiu à conexão de Interconexão dedicada e concede permissão para um fornecedor em uma instalação de colocation se conectar a ele. Os documentos LOA-CFA são necessários ao solicitar conexões de Interconexão dedicada em uma instalação de colocation.

Quando você solicita conexões de Interconexão dedicada, o Google aloca recursos para suas conexões e, em seguida, gera um documento LOA-CFA para cada uma. A LOA-CFA lista os pontos de demarcação que o Google alocou para suas conexões. Envie esse formulário ao fornecedor da instalação para provisionar conexões entre seu equipamento e o do Google. Depois que o status de uma conexão for alterado para PROVISIONED, a LOA-CFA não será mais válida, necessária ou estará disponível no Console do Google Cloud.

Para saber mais sobre o fluxo de provisionamento, consulte a Visão geral de provisionamento da Interconexão dedicada.

Chave de pareamento

Aplicável à Interconexão por parceiro.

Um identificador exclusivo que permite aos provedores de serviços identificarem determinados anexos da VLAN sem que ninguém compartilhe informações potencialmente confidenciais sobre a rede VPC ou o projeto do Google Cloud. As chaves de pareamento são usadas apenas com o Partner Interconnect.

Trate a chave de pareamento como informação confidencial até que o anexo da VLAN esteja configurado. Se for descoberta, é possível que terceiros a usem para se conectar à sua rede. A chave é usada apenas uma vez e não pode ser modificada. Se você precisar de uma nova chave de pareamento, exclua o anexo da VLAN e crie um novo.

O pareamento de chaves usa o seguinte formato:
<random>/<vlan-attachment-region>/<edge-availability-domain>.

Por exemplo, 7e51371e-72a3-40b5-b844-2e3efefaee59/us-central1/2 é uma chave de pareamento para um anexo da VLAN na região us-central1 e domínio de disponibilidade de borda 2.

provedor de serviços de nuvem remota

Aplicável ao Cross-Cloud Interconnect.

Outro provedor de serviços em nuvem, além do Google Cloud, em que você pode ter recursos de rede.

Termos do Border Gateway Protocol (BGP)

A terminologia a seguir se aplica ao Border Gateway Protocol (BGP), que o Cloud VPN e o Cloud Interconnect usam para roteamento dinâmico.

Border Gateway Protocol (BGP)
Um protocolo de roteamento de gateway externo padronizado pela Internet Engineering Task Force (IETF) na RFC 1722. O BGP troca automaticamente informações de roteamento e acessibilidade entre sistemas autônomos na Internet. O dispositivo é compatível com o BGP se puder executar o roteamento do BGP, o que significa que é possível ativar o protocolo BGP nele e atribuir a ele um endereço IP do BGP e um número de sistema autônomo. Para determinar se o dispositivo é compatível com o BGP, consulte as informações do fornecedor para seu dispositivo ou entre em contato com o fornecedor do dispositivo.
Sistema autônomo (AS)
Uma coleção de prefixos de roteamento de IP conectados sob o controle de uma única entidade ou domínio administrativo que apresenta uma política de roteamento comum para a Internet, como um provedor de acesso à Internet (ISP, na sigla em inglês), uma grande empresa ou uma universidade.
Número de sistema autônomo (ASN)
Um identificador exclusivo alocado para cada sistema autônomo que usa o roteamento do BGP. Para mais informações, consulte a RFC 7300 (em inglês).
Autenticação MD5
Um método de autenticação de peering do BGP que usa o algoritmo MD5 de resumo por mensagem. Quando você usa essa abordagem, os peerings do BGP precisam usar a mesma chave de autenticação, ou não é possível estabelecer uma conexão entre eles. Mais tarde, todos os segmentos roteados entre os apps semelhantes serão verificados. Para mais informações sobre a autenticação MD5, consulte a RFC 2385 (em inglês). Para descobrir se o dispositivo é compatível com a autenticação MD5, consulte as informações do fornecedor ou entre em contato direto com ele. Para receber suporte sobre o uso da autenticação MD5 do Cloud Router, consulte Suporte.