Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O dispositivo roteador é um recurso do Network Connectivity Center que permite usar um dispositivo virtual de
rede de terceiros no Google Cloud. Quando você usa essa
abordagem, o dispositivo pode trocar rotas com o Cloud Router
usando o protocolo de gateway de borda (BGP, na sigla em inglês).
Usando o dispositivo roteador e o Network Connectivity Center, você pode fazer o seguinte:
Conecte várias redes VPC entre si. As redes
VPC podem estar localizadas em diferentes projetos na mesma organização do Google Cloud ou em
organizações diferentes.
Conectar várias redes VPC à infraestrutura no local ou a outras redes
de provedor de nuvem.
Essas redes externas podem ser acessadas por qualquer tipo de spoke híbrido.
Essa abordagem é conhecida como conectividade site a nuvem.
Utilize as VMs do dispositivo roteador para gerenciar a conectividade entre as redes VPC.
Utilize uma rede VPC do Google Cloud como uma rede
de longa distância (WAN, na sigla em inglês) para conectar redes fora do Google Cloud.
É possível estabelecer conectividade entre sites externos usando qualquer tipo
de spoke híbrido. Essa abordagem é conhecida como conectividade
site a nuvem.
Como funciona
É possível configurar uma instância de dispositivo roteador instalando uma imagem em uma VM do Compute Engine. Use uma imagem fornecida por um parceiro compatível do Network Connectivity Center. Também é possível usar uma imagem personalizada, como uma imagem
criada.
Depois que a instância do dispositivo roteador for instalada, configure as interfaces no
Cloud Router para estabelecer o peering do protocolo de gateway de borda (BGP, na sigla em inglês) com essa instância. O BGP permite a troca dinâmica de rotas
entre o Cloud Router e a instância do dispositivo roteador. A troca de
rotas, por sua vez, permite a conectividade do site à rede
VPC pela instância do dispositivo roteador. Isso significa que as rotas
propagadas pela instância do dispositivo roteador podem ser usadas por VMs e outros
recursos que têm endereços IP na mesma rede VPC.
O Cloud Router usa interfaces configuradas com endereços IP internos RFC 1918
para estabelecer o peering do BGP com instâncias do dispositivo de roteador.
Não há APIs nem recursos ou permissões do Google Cloud separados para o
dispositivo roteador. Para trabalhar com o dispositivo roteador, use
os recursos e as permissões do Compute Engine e do Cloud Router.
Caso de uso: transferência de dados entre ambientes no local
A topologia a seguir mostra uma rede VPC e dois sites
locais. Cada site local se conecta ao Google Cloud usando um
spoke do dispositivo roteador. Os dois sites locais podem usar a rede do Google
para trocar dados entre si.
Topologia do dispositivo Router (clique para ampliar)
Cada Customer network A e Customer network B locais são conectados
com equipamentos locais do cliente (CPE, na sigla em inglês) a uma instância de dispositivo de roteador.
Os CPEs normalmente usam um mecanismo de conectividade, como um túnel de sobreposição SD-WAN
ou um túnel de VPN IPsec, para estabelecer conectividade com a
instância do dispositivo de roteador.
Cada instância do dispositivo de roteador está localizada na
região do Google Cloud mais próxima da rede do cliente associada a ela. As duas
instâncias do dispositivo roteador estão em uma única rede VPC.
No entanto, as instâncias do dispositivo roteador estão em regiões diferentes. Por isso,
a rede VPC está com o
modo de roteamento dinâmico
definido como global.
As duas instâncias do dispositivo de roteador são anexadas como spokes ao
Network Connectivity Center de rede. Como Customer network A e Customer network B
precisam enviar dados entre si, os dois spokes estão com o campo de transferência de dados
site a site ativado.
Em cada região, uma instância do dispositivo roteador estabelece o peering do protocolo de
gateway de borda (BGP, na sigla em inglês) com o Cloud Router apropriado. Cada
Cloud Router recebe e divulga prefixos de rota do
local correspondente.
Os Cloud Routers trocam dinamicamente todas as rotas recebidas
entre si. Essa configuração fornece troca de rota dinâmica
completa e conectividade do plano de dados entre Customer network A e
Customer network B.
Siga estes requisitos ao implantar instâncias de dispositivo de roteador.
Configuração do BGP
A imagem do dispositivo de roteador instalado precisa ser compatível com o protocolo de
roteamento do BGP.
Para ativar o peering do BGP entre uma instância de dispositivo de roteador e um
Cloud Router, anexe cada instância do dispositivo de roteador
como um spoke ao hub do Network Connectivity Center
Crie um Cloud Router na mesma região da
sub-rede
que contém a interface de peering da instância do dispositivo de roteador.
Crie manualmente interfaces do BGP na instância do dispositivo de roteador. Essas
interfaces precisam estar na mesma sub-rede da instância do dispositivo de roteador.
Crie sessões do BGP manualmente com o Cloud Router com base
na instância do dispositivo de roteador.
Para VMs que tenham várias interfaces de rede configuradas como parte da instância do
dispositivo de roteador, estabeleça sessões do BGP com
Cloud Routers que estejam na mesma sub-rede da interface da VM.
Para mais informações sobre interfaces de VM, consulte
Visão geral de várias interfaces de rede e exemplos.
Recomendações de disponibilidade
O contrato de nível de serviço (SLA, na sigla em inglês) padrão para VMs do Compute Engine também
se aplica à disponibilidade de instâncias do dispositivo de roteador. Esse
SLA de disponibilidade é de 99,5% para uma única VM e 99,99% para VMs em várias
zonas. Para mais informações, consulte o SLA do Compute Engine.
Para duas instâncias do dispositivo de roteador, cada uma para um ambiente no local
diferente, execute pelo menos duas VMs em zonas diferentes. Cada VM precisa
fazer peering com um par de interfaces redundantes do Cloud Router.
Para saber mais sobre zonas, consulte
Regiões e zonas.
Considerações
Antes de usar o dispositivo roteador, leia as seções a seguir.
Considerações gerais
Para usar o dispositivo de roteador, você precisa operar o Network Connectivity Center. Ou seja,
não é possível configurar instâncias de dispositivo de roteador autônomas que fazem peering
com um Cloud Router ou com outros roteadores de mesmo nível. Configure as
instâncias do dispositivo de roteador como parte de um spoke do Network Connectivity Center.
O dispositivo roteador só tem suporte no modelo de VPC compartilhada quando
implantado no projeto host. A instância do dispositivo do roteador precisa ser implantada
no projeto host e em todos os outros recursos associados, como hub,
spoke e Cloud Router.
O dispositivo roteador não oferece suporte à VPC compartilhada quando a
VM do dispositivo de roteador é implantada no projeto de serviço.
Considerações sobre o roteamento
Se várias instâncias do dispositivo de roteador anunciarem os mesmos prefixos de roteamento
com o mesmo MED, o Google Cloud usará o roteamento de vários caminhos de custo igual (ECMP, na sigla em inglês)
em todas as instâncias do dispositivo de roteador.
Recomendamos não anunciar os mesmos prefixos em uma combinação de diferentes
tipos de spoke (instâncias do dispositivo de roteador, gateways do
Cloud VPN e anexos da VLAN). Se os mesmos prefixos forem acessíveis por uma combinação de
tipos de spoke, o uso do ECMP entre os tipos de spoke combinados poderá comprometer
o tráfego em cada link.
Se um único Cloud Router aprender um prefixo com vários próximos saltos,
o Cloud Router selecionará primeiro os próximos saltos com o menor tamanho do caminho AS e, em seguida, usará o MED para quebrar as ligações. Para mais informações, consulte
Tamanho do caminho AS na
documentação do Cloud Router.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-28 UTC."],[],[],null,["# Router appliance overview\n\nRouter appliance is a Network Connectivity Center feature that lets you use a\nthird-party network virtual appliance in Google Cloud. When you use this\napproach, the appliance can exchange routes with Cloud Router by\nusing Border Gateway Protocol (BGP).\n\nUsing Router appliance and Network Connectivity Center, you can do the following:\n\n- Connect multiple VPC networks to one another. The VPC networks can be located across different projects in the same Google Cloud organization or different organizations.\n- Connect multiple VPC networks to on-premise or other cloud provider networks. These external networks can be reachable through any type of hybrid spoke. This approach is known as *site-to-cloud connectivity.*\n- Use Router appliance VMs to manage connectivity between your VPC networks.\n- Use a Google Cloud VPC network as an enterprise wide area network (WAN) to connect networks that are outside of Google Cloud. You can establish connectivity between your external sites by using any type of hybrid spoke. This approach is known as *site-to-site\n connectivity*.\n\nHow it works\n------------\n\nYou can configure a router appliance instance by installing\nan image on a Compute Engine VM. You can use an image provided by a\n[supported Network Connectivity Center partner](/network-connectivity/docs/network-connectivity-center/partners). You can also use a custom image, such as an image that you\ncreated.\n\nAfter the router appliance instance is installed, you configure interfaces on\nthe Cloud Router to establish Border Gateway Protocol (BGP) peering\nwith the router appliance instance. BGP enables the dynamic exchange of routes\nbetween the Cloud Router and the router appliance instance. Route\nexchange, in turn, permits connectivity from the site through the router\nappliance instance to the VPC network. That is, the routes\npropagated by the router appliance instance can be used by VMs and other\nresources that have IP addresses in the same VPC network.\n\nCloud Router uses interfaces configured with RFC 1918 internal IP\naddresses to establish BGP peering with router appliance instances.\n\nThere are no separate APIs or Google Cloud resources or permissions for\nRouter appliance. To work with Router appliance, you use\nCompute Engine and Cloud Router resources and permissions.\n\nUse case: Data transfer between on-premises sites\n-------------------------------------------------\n\nThe following topology shows a VPC network and two on-premises\nsites. Each on-premises site connects to Google Cloud by using a\nRouter appliance spoke. The two on-premises sites can use Google's network\nto exchange data with each other.\n[](/static/network-connectivity/docs/network-connectivity-center/images/router-appliance-topology.svg) Router appliance topology (click to enlarge)\n\n1. On-premises `Customer network A` and `Customer network B` are each connected\n through *customer premises equipment (CPE)* to a router appliance instance.\n CPEs typically use a connectivity mechanism, such as an SD-WAN overlay tunnel\n or an IPsec VPN tunnel, to establish connectivity with the\n router appliance instance.\n\n Each router appliance instance is located in the\n Google Cloud region closest to its associated customer network. Both\n router appliance instances are in a single VPC network.\n However, the router appliance instances are in different regions. For this\n reason, the VPC network has its\n [dynamic routing mode](/vpc/docs/create-modify-vpc-networks#switch-dynamic-routing)\n set to `global`.\n2. Both router appliance instances are attached as spokes to the\n Network Connectivity Center hub. Because `Customer network A` and `Customer network B`\n need to send data to each other, both spokes have the site-to-site data\n transfer field enabled.\n\n *You can use site-to-site data transfer only in supported locations.* For\n more information, see\n [Locations supported for data transfer](/network-connectivity/docs/network-connectivity-center/concepts/locations).\n3. In each region, a router appliance instance establishes Border Gateway\n Protocol (BGP) peering with the appropriate Cloud Router. Each\n Cloud Router receives and advertises route prefixes from the\n corresponding on-premises location.\n\n4. The Cloud Routers dynamically exchange all received\n routes with each other. This configuration provides end-to-end dynamic route\n exchange and data plane connectivity between `Customer network A` and\n `Customer network B`.\n\n | **Important:** For Cloud Routers in different regions to exchange routes with each other, you must enable global dynamic routing mode in your VPC network. For more information, see [Dynamic routing](/vpc/docs/vpc#routing_for_hybrid_networks).\n\nFor detailed configuration steps for a load-balanced single-site topology,\nsee\n[Create router appliance instances](/network-connectivity/docs/network-connectivity-center/how-to/creating-router-appliances).\n\nRequirements\n------------\n\nFollow these requirements when deploying router appliance instances.\n\n### BGP configuration\n\n- The router appliance image that you install must support the BGP routing protocol.\n- To enable BGP peering between a router appliance instance and a Cloud Router, attach each router appliance instance as a spoke to a Network Connectivity Center hub.\n- Create a Cloud Router in the same region as the [subnet](/vpc/docs/vpc#subnets_vs_subnetworks) that contains the peering interface of the router appliance instance.\n- Manually create BGP interfaces on the router appliance instance. These interfaces must be in the same subnet as the router appliance instance.\n- Manually create BGP sessions with Cloud Router from the router appliance instance.\n- For VMs that have multiple network interfaces configured as part of the router appliance instance, you can establish BGP sessions with Cloud Routers that are in the same subnet as the VM interface. For more information about VM interfaces, see [Multiple network interfaces overview and examples](/vpc/docs/multiple-interfaces-concepts).\n\n### Availability recommendations\n\n- The standard service-level agreement (SLA) for Compute Engine VMs also applies to the availability of router appliance instances. This availability SLA is 99.5% for a single VM and 99.99% for VMs in multiple zones. For more information, see the [Compute Engine SLA](/compute/sla).\n- For a pair of router appliance instances, each for a different on-premises location, run at least two VMs in different zones. Each VM must peer with a pair of redundant Cloud Router interfaces. For more information about zones, see [Regions and zones](/compute/docs/regions-zones).\n\nConsiderations\n--------------\n\nBefore using Router appliance, review the following sections.\n\n### General considerations\n\n- *Router appliance requires Network Connectivity Center to operate.* That is, you can't configure standalone router appliance instances that peer with a Cloud Router or with other peer routers. You must configure router appliance instances as part of a Network Connectivity Center spoke.\n- Router appliance is only supported in the Shared VPC model when\n deployed in the host project. The router appliance instance must be deployed\n in the host project and all the other associated resources, such as hub,\n spoke, and Cloud Router.\n\n Router appliance does not support Shared VPC when the\n Router appliance VM is deployed in the service project.\n\n### Routing considerations\n\n- If multiple router appliance instances announce the same routing prefixes with the same MED, Google Cloud uses equal-cost multipath (ECMP) routing across all the router appliance instances.\n- *We recommend not advertising the same prefixes through a mix of different\n spoke types (router appliance instances, Cloud VPN gateways,\n and VLAN attachments).* If the same prefixes are reachable through a mix of spoke types, using ECMP across the mixed spoke types can lead to imbalanced traffic across each link.\n- If a single Cloud Router learns a prefix with multiple next hops, Cloud Router selects the next hops with the shortest AS path length first, and then uses the MED to break ties. For more information, see [AS path length](/router/concepts/learned-routes#as-path-length-considerations) in the Cloud Router documentation.\n\nWhat's next\n-----------\n\n- To set up Google Cloud resources for your router appliance instance, see [Create router appliance instances](/network-connectivity/docs/network-connectivity-center/how-to/creating-router-appliances).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To view Router appliance monitoring and logging information, see [Viewing logs and metrics](/network-connectivity/docs/network-connectivity-center/how-to/viewing-logs-metrics).\n- To find solutions for Router appliance issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshooting-ra).\n- To get details about API and `gcloud` commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
