이 문서에서는 정적 경로가 Network Connectivity Center에서 작동하는 방식을 설명합니다. Virtual Private Cloud(VPC) 네트워크에서 경로는 CIDR 형식의 단일 대상 프리픽스와 단일 다음 홉으로 구성됩니다. VPC 네트워크의 인스턴스가 패킷을 전송하면 패킷의 목적지 위치 주소가 경로의 목적지 범위 내에 있는 경우 Google Cloud 가 패킷을 경로의 다음 홉으로 전달합니다.
정적 경로를 만들 때는 대상 프리픽스와 다음 홉을 지정합니다. VPC 스포크부터 Network Connectivity Center 허브를 통해 액세스할 수 있는 내부 패스 스루 네트워크 부하 분산기까지의 정적 경로를 만들 수 있습니다.
따라서 원격 VPC가 홈 VPC와 함께 Network Connectivity Center 연결을 사용하는 경우에만 정적 경로는 다른 스포크의 내부 패스 스루 네트워크 부하 분산기의 IP 주소를 가리킬 수 있습니다.
이 연결은 두 VPC가 서브넷 경로를 교환해야 하는 Network Connectivity Center 정책에 의해 제어됩니다. VPC가 Network Connectivity Center 허브를 통해 연결되지 않으면 트래픽이 삭제됩니다.
정적 경로에 사용할 수 있는 대상은 VPC 스포크 토폴로지에 따라 다릅니다.
메시 토폴로지를 사용하는 경우 VPC 스포크부터 허브에 연결된 VPC 스포크의 내부 패스 스루 네트워크 부하 분산기까지의 정적 경로를 만들 수 있습니다.
스타 토폴로지를 사용하는 경우 에지 VPC와 센터 VPC 사이에 정적 경로를 만들 수 있습니다. 한 에지 VPC와 다른 에지 VPC 사이에 정적 경로를 만들면 서브넷이 서로 연결될 수 없으므로 트래픽이 삭제됩니다.
Network Connectivity Center 정적 경로에는 다음과 같은 제한사항이 있습니다.
내부 패스 스루 네트워크 부하 분산기의 IP 주소가 원격 Network Connectivity Center 스포크 VPC에 있고 내보내기 필터로 인해 교환되지 않으면 다른 VPC 스포크의 정적 경로를 사용하여 해당 IP 주소에 연결할 수 없습니다. 따라서 대상 범위로 흐르는 트래픽이 삭제됩니다.
한 Network Connectivity Center VPC 스포크에 있는 IP 주소까지의 정적 경로를 만든 후 해당 스포크의 서브넷과 내부 패스 스루 네트워크 부하 분산기를 삭제하고 새 내부 패스 스루 네트워크 부하 분산기의 IP 주소가 포함된 IP 주소 범위로 새 서브넷을 만들면 트래픽이 자동으로 새 스포크로 다시 라우팅됩니다.
정적 경로가 있는 VPC 스포크를 새 Network Connectivity Center 스포크 그룹으로 이동하면 경로 대상 범위에 대한 트래픽이 새 스포크 그룹의 경로 테이블에 따라 전달됩니다.
존재하지 않거나 허브에 연결되지 않은 대상 IP 주소로 정적 경로를 만들면 트래픽이 삭제됩니다. 하지만 IP 주소를 사용할 수 있게 되어 허브에 연결되면 트래픽이 자동으로 해당 IP 주소로 라우팅됩니다.
VPC 스포크를 삭제하면 내부 패스 스루 네트워크 부하 분산기의 IP 주소가 다음 홉으로 있는 기존 정적 경로는 구성된 상태로 유지됩니다. 하지만 대상이 로컬 네트워크나 VPC 네트워크 피어링을 통해 연결될 수 없으면 트래픽이 삭제됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(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)"]]