Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve como as rotas estáticas funcionam com o Network Connectivity Center. Em uma rede de nuvem privada virtual (VPC), uma rota consiste em um prefixo de destino
no formato CIDR e um próximo salto. Quando uma instância em uma
rede VPC envia um pacote, Google Cloud entrega o
pacote ao próximo salto da rota se o endereço de destino do pacote estiver dentro do
intervalo de destino da rota.
Ao criar uma rota estática, você especifica o prefixo de destino e o próximo salto. É possível criar rotas estáticas dos raios da VPC para balanceadores de carga de rede de passagem interna acessíveis pelo hub do Network Connectivity Center.
Portanto, uma rota estática só pode apontar para o endereço IP de um balanceador de carga de rede de passagem interna em outro spoke se a VPC remota tiver conectividade do Network Connectivity Center com a VPC inicial.
Essa conectividade é controlada pela política do Network Connectivity Center, em que
as duas VPCs precisam trocar rotas de sub-rede. Se as
VPCs não estiverem conectadas pelo hub do Network Connectivity Center,
o tráfego será descartado.
Os destinos disponíveis para rotas estáticas dependem da topologia dos spokes da VPC:
Se você usar uma topologia de malha, poderá criar rotas estáticas dos spokes da VPC para balanceadores de carga de rede de passagem interna em qualquer spoke da VPC conectado ao hub.
Se você usar uma topologia em estrela, poderá criar rotas estáticas entre as VPCs de borda e as VPCs centrais. Se você criar uma rota estática entre duas VPCs de borda, o tráfego será descartado porque as sub-redes não poderão se alcançar.
Para mais informações sobre rotas estáticas, consulte
Rotas estáticas.
Limitações
As rotas estáticas do Network Connectivity Center têm as seguintes limitações:
Se o endereço IP do balanceador de carga de rede de passagem interna estiver em uma VPC spoke remota do Network Connectivity Center e não for trocado devido a um filtro de exportação, esse endereço IP não poderá ser acessado usando uma rota estática de outro spoke de VPC. Portanto, o tráfego para o intervalo de destino é descartado.
Se você criar uma rota estática para um endereço IP em um hub de VPC do Network Connectivity Center, excluir a sub-rede e o balanceador de carga de rede de passagem interno desse hub e criar uma nova sub-rede com um intervalo de endereços IP que contenha o endereço IP de um novo balanceador de carga de rede de passagem interno, o tráfego será redirecionado automaticamente para o novo hub.
Se você mover um spoke da VPC com uma rota estática para um novo grupo de spokes do Network Connectivity Center, o tráfego para o intervalo de destino da rota será entregue de acordo com a tabela de rotas do novo grupo de spokes.
Se você criar uma rota estática com um endereço IP de destino que não existe ou não está conectado ao hub, o tráfego será descartado. No entanto, se o endereço IP ficar disponível e for conectado ao hub, o tráfego será roteado automaticamente para ele.
Quando você exclui uma VPC spoke, todas as rotas estáticas atuais com um endereço IP de balanceador de carga de rede de passagem interna como o próximo salto permanecem configuradas. No entanto, o tráfego será descartado, a menos que o destino seja acessível por uma rede local ou pelo peering de rede VPC.
Rotas estáticas com tag não são compatíveis.
As seguintes limitações se aplicam a VPCs de roteamento:
Não há suporte para rotas estáticas em VPCs de roteamento no Network Connectivity Center.
Adicione a VPC de roteamento como um spoke da VPC
para permitir que as rotas estáticas na VPC de roteamento funcionem no
Network Connectivity Center.
Todos os endpoints híbridos em uma VPC de roteamento recebem a rota estática, independente de estarem conectados ao hub do Network Connectivity Center como spokes híbridos.
[[["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-12 UTC."],[],[],null,["This document describes how Network Connectivity Center supports static routes in\nVPC spokes.\n\nBefore reading this page, ensure that you're familiar with the following resources:\n\n- [Routes](/vpc/docs/routes) for a general overview of routes in Google Cloud\n- [Static routes](/vpc/docs/static-routes) for an overview of static routes\n\nIntroduction\n\nUnlike subnet routes and dynamic routes, Network Connectivity Center hubs don't exchange\nstatic routes. Instead, a hub provides additional configuration flexibility for\nstatic routes created in each VPC spoke.\n\nA static route in one VPC spoke can use a next hop in a\ndifferent VPC spoke if all of the following are true:\n\n- The static route doesn't use a network tag.\n- The destination range of the static route is an IPv4 range.\n- The specified next hop of the static route is an IPv4 address of an internal passthrough Network Load Balancer.\n- Google Cloud is able to [identify a next hop\n internal passthrough Network Load Balancer](#identify-nh) at the specified next hop IP address.\n- [Network Connectivity Center connectivity requirements](#ncc-reqs) have been met.\n\nThe additional configuration flexibility for static routes applies only to\nVPC spokes, not to VPC networks that are purely\nrouting VPC networks (containing only hybrid spokes).\n\nFor a comparison to other types of static route next hops, see [Next hop\nproject and network](/vpc/docs/static-routes#static-route-next-hop-loc).\n\nIdentifying the next hop internal passthrough Network Load Balancer\n\nGoogle Cloud attempts to find an internal passthrough Network Load Balancer for a static route that\nhas a next hop internal passthrough Network Load Balancer IP address by using the following process:\n\n- If the next hop IP address is in the destination range of a local subnet\n route: Google Cloud exclusively searches for an internal passthrough Network Load Balancer whose\n forwarding rule IP address is in the corresponding local subnet. If a next\n hop internal passthrough Network Load Balancer is found, both the static route and next hop are in the\n same VPC network.\n\n- If the next hop IP address is in the destination range of a Network Connectivity Center\n subnet route (imported from the hub): Google Cloud exclusively searches\n for an internal passthrough Network Load Balancer whose forwarding rule IP address is in the corresponding\n subnet of another VPC spoke. If a next hop internal passthrough Network Load Balancer\n is found, the static route is in one VPC spoke, and the next\n hop is in a different VPC spoke.\n\n - For details about how an internal passthrough Network Load Balancer in another VPC spoke\n can be found, see [Network Connectivity Center requirements for\n connectivity](#ncc-reqs).\n\n - If you want to use a next hop internal passthrough Network Load Balancer in a routing\n VPC network (containing hybrid spokes), you must add the\n routing VPC network to the hub as a VPC\n spoke. For more limitations relevant to using a routing VPC\n network as a VPC spoke, see [Limitations of dynamic route\n exchange](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#limitations-of-route-exchange).\n\n- If the next hop IP address is in the destination range of a peering subnet\n route (imported from another network that is using VPC Network Peering):\n Google Cloud exclusively searches for an internal passthrough Network Load Balancer whose forwarding\n rule IP address is in the corresponding subnet of the peered VPC\n network. If a next hop internal passthrough Network Load Balancer is found, the static route is in one\n VPC network, and the next hop is in the peered VPC\n network.\n\nIf no next hop internal passthrough Network Load Balancer is found, packets sent to the destination\nrange of the static route are dropped.\n\nUpdates to the next hop internal passthrough Network Load Balancer\n\nGoogle Cloud continuously attempts to identify a next hop internal passthrough Network Load Balancer.\nIn the following example situations, the next hop for a static route is updated\nautomatically.\n\n- Replacing the next hop internal passthrough Network Load Balancer: when the next hop for a static route is\n the IP address of an internal passthrough Network Load Balancer, you can delete the next hop internal passthrough Network Load Balancer\n without needing to first delete the static route. If Google Cloud finds a\n replacement internal passthrough Network Load Balancer with the same IP address, Google Cloud switches\n to the replacement internal passthrough Network Load Balancer next hop.\n\n- An existing static route without a valid next hop internal passthrough Network Load Balancer can become\n operational: when a valid next hop internal passthrough Network Load Balancer is found, Google Cloud\n begins using that internal passthrough Network Load Balancer next hop.\n\n- Adjusting Network Connectivity Center configuration: moving a VPC spoke to\n a different spoke group or adjusting export filters can result in a next hop\n internal passthrough Network Load Balancer no longer being found or a different next hop internal passthrough Network Load Balancer being\n found and used.\n\nNetwork Connectivity Center requirements for connectivity\n\nTo find a next hop internal passthrough Network Load Balancer in another VPC spoke, the\nsubnet used by the internal passthrough Network Load Balancer forwarding rule must be accessible in the\nVPC spoke where the static route is defined. Both the following\nconditions must be true:\n\n1. The [hub\n topology](/network-connectivity/docs/network-connectivity-center/concepts/connectivity-topologies)\n must allow exchange of subnet routes that contain the next hop internal passthrough Network Load Balancer.\n\n - If you use the mesh topology, all VPC spokes are part of the\n same spoke group. The static route can exist in any VPC\n spoke, and its next hop internal passthrough Network Load Balancer can exist in any VPC\n spoke.\n\n - If you use the star topology, the following requirements apply:\n\n - If the static route is in a VPC spoke of the edge\n spoke group, the next hop internal passthrough Network Load Balancer can be in that edge\n VPC spoke or in any VPC spoke of the\n center spoke group. The next hop can't be in a different\n VPC spoke of the edge spoke group.\n\n - If the static route is in a VPC spoke of the center\n spoke group, its next hop internal passthrough Network Load Balancer can be in any\n VPC spoke (in either the edge spoke group or the center\n spoke group).\n\n2. The subnet range used by the internal passthrough Network Load Balancer forwarding rule must be exported\n to the hub. For more information, see [VPC connectivity with\n export\n filters](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-connectivity-with-export-filters).\n\nEffect of global access\n\nNext hop internal passthrough Network Load Balancers that don't have global access enabled aren't reachable\nfrom regions outside of the load balancer's region. If Google Cloud has\nidentified a next hop load balancer at the specified next hop IP address,\nand Network Connectivity Center connectivity requirements are met, but the load balancer\ndoesn't have global access enabled, Google Cloud drops all packets sent\nfrom VM instances, VLAN attachments, and Cloud VPN tunnels in regions\ndifferent from the load balancer's region.\n\nTo change this behavior and make the next hop load balancer reachable from all\nregions, [enable global\naccess](/load-balancing/docs/internal/setting-up-internal#ilb-global-access).\n\nWhat's next\n\n- [Configure static routes](/network-connectivity/docs/network-connectivity-center/how-to/configure-static-routes)"]]
