Google Cloud 絕不會將 Cloud VPN 通道視為尚未建立 IKE 安全關聯 (SA) 的有效下一個躍點。如果 Cloud VPN 通道已建立 IKE SA， Google Cloud會將其視為運作中。只有在 Cloud VPN 通道依轉送順序選為下一個躍點時，才會傳送流量。系統可能會改用其他路徑的下一個躍點，該路徑具有更明確的目的地或較高的優先順序。
以下情境說明預期行為：
如果您為相同目的地建立多個靜態路徑，且每個路徑都有不同的下一個躍點 Cloud VPN 通道， Google Cloud只會考量已建立 IKE SA (第 1 階段) 的通道。系統會先忽略沒有有效 IKE SA 的通道，再考慮路徑優先順序。
舉例來說，假設您有三個 192.168.168.0/24 目的地的靜態路徑：優先順序為 10 的路徑，其下一個躍點 Cloud VPN 通道已關閉；優先順序為 20 的路徑，其下一個躍點通道已開啟；優先順序為 30 的路徑，其下一個躍點通道也已開啟。 Google Cloud 會將流量傳送至第二個下一個躍點，即使該路徑的優先順序低於下一個躍點已關閉的路徑。如果重新建立第一個通道， Google Cloud 會將其視為有效的下一個躍點，並改用該路徑。
[[["容易理解","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-05 (世界標準時間)。"],[],[],null,["# Order of routes\n\n| **Warning:** Certain Classic VPN dynamic routing functionality is deprecated. For more information, see [Classic VPN dynamic routing partial deprecation](/network-connectivity/docs/vpn/deprecations/classic-vpn-deprecation).\n\nThis page describes how custom routes with next hops of Cloud VPN\ntunnels work in Google Cloud.\n\nFor background information about Google Cloud routes, including\nroute applicability and order and static route parameters, see\nthe Virtual Private Cloud (VPC) [routes overview](/vpc/docs/routes).\n\nRoute types\n-----------\n\nA Cloud VPN tunnel can be a next hop for a custom route in your\nVPC network. Each custom route with a next hop Cloud VPN\ntunnel defines an *egress path* for packets leaving your VPC\nnetwork:\n\n- A Cloud Router always manages a Classic VPN tunnel that uses\n [dynamic routing](/network-connectivity/docs/vpn/concepts/choosing-networks-routing#dynamic-routing)\n or an HA VPN tunnel. The\n Cloud Router receives BGP advertisements from and sends BGP messages\n to a [peer VPN gateway](/network-connectivity/docs/vpn/concepts/key-terms#peer-definition).\n Cloud Router automatically creates and removes [dynamic\n routes](/vpc/docs/routes#dynamic_routes) in your VPC\n network---that is, the routes with destinations in a peer network. It also\n advertises routes to a peer network---that is, routes to the IP\n ranges of subnets in your VPC network or to [custom\n destinations that\n you specify](/network-connectivity/docs/router/how-to/advertising-custom-ip)\n in a Cloud Router configuration. The [dynamic\n routing mode](/vpc/docs/vpc#routing_for_hybrid_networks) of your\n VPC network controls the set of routes that\n Cloud Router imports and exports.\n\n- A policy-based or route-based Classic VPN tunnel uses [static\n routing](/network-connectivity/docs/vpn/concepts/choosing-networks-routing#static-routing).\n If you use the Google Cloud console to create one of these tunnels,\n Google Cloud automatically creates [static\n routes](/vpc/docs/static-routes) based on the remote IP ranges that you\n specify in the Cloud VPN configuration. If you use the Google Cloud CLI\n to create one of these tunnels, you must manually create the static routes\n that use the tunnel as a next hop.\n\nExample scenarios\n-----------------\n\nGoogle Cloud follows a well-defined\n[applicability and order](/vpc/docs/routes#instancerouting) when selecting\nthe next hop to which a packet should be sent. The following examples\ndemonstrate common interactions between routes and Cloud VPN.\n\n### Interaction with subnet routes\n\nThe following table demonstrates how subnet routes and custom routes interact.\nEach row represents a possible IP range of a subnet in a VPC\nnetwork. The on-premises ranges are `10.2.0.0/16` for IPv4 and `fd20:a:b:c::/64` for IPv6.\n\nIPv6 traffic is supported only by HA VPN gateways that are\nconfigured with a dual stack type of IPv4 and IPv6.\n\n### When tunnels are down\n\n#### Dynamic (BGP) routing\n\nWhen a Classic VPN tunnel that uses dynamic routing or an\nHA VPN tunnel goes down, the Cloud Router\nmanaging it automatically removes the learned routes. The length of time that\nit takes to detect the breakage varies depending on whether\n[Bidirectional Forwarding Detection (BFD)](/network-connectivity/docs/router/concepts/bfd)\nis enabled. If\nBFD is enabled, the detection occurs when the BGP holddown timer expires.\nOtherwise, detection occurs in less than 60 seconds. The learned routes can be\nre-added when the tunnel is re-established.\n\nThis process is fully automatic, but can still result in some packet loss during\nthe time that it takes for Cloud Router to remove the affected routes.\n\n#### Static routing\n\nGoogle Cloud never considers a Cloud VPN tunnel as a valid next\nhop that has not established an IKE security association (SA). If a\nCloud VPN tunnel has established an IKE SA, Google Cloud\nconsiders it operational. An operational Cloud VPN tunnel\nonly passes traffic if it is selected as the next hop according to the\n[routing order](/vpc/docs/routes#routeselection). The next hop for a different\nroute, with either a more specific destination or with a higher priority,\nmight be used instead.\n\nThe following scenarios demonstrate expected behaviors:\n\n- If you have multiple static routes for the same destination, each\n having a different next hop Cloud VPN tunnel, Google Cloud\n only considers those tunnels that have established IKE SAs (Phase 1). Tunnels\n that are down---that is, that do not have valid IKE SAs---are disregarded\n *before* considering route priority.\n\n For example, suppose that you have three static\n routes for the `192.168.168.0/24` destination: one with priority `10` whose\n next hop Cloud VPN tunnel is down, a second with priority `20` whose\n next hop tunnel is up, and a third with priority `30` whose next hop tunnel is\n also up. Google Cloud sends traffic to the second next hop, even\n though its route has a lower priority than the route whose next hop is down.\n If the first tunnel is re-established, then Google Cloud considers\n it a valid next hop and uses that route instead.\n- Traffic is dropped if all Cloud VPN tunnels serving as next hops for\n static routes with the same destination are down. Traffic is dropped even\n if there is a static route for a broader destination with an\n operational next hop tunnel.\n\n For example, suppose that you have a static route for\n `192.168.168.0/24` whose next hop Cloud VPN\n tunnel is down (no valid IKE SA). Even if you have a route for\n `192.168.0.0/16` whose next hop is an operational Cloud VPN tunnel,\n traffic to `192.168.168.0/24` is dropped. This is because Google Cloud\n always selects routes with the most specific destinations.\n\nWhen traffic switches from one next hop Cloud VPN tunnel to another,\nyou should still expect packet loss. In-flight packets might be dropped and need\nto be re-transmitted.\n\n### ECMP over tunnels\n\nFor both dynamic and static routing, if more than one custom route exists for\nthe same destination and has the same priority and an active (IKE SA\nestablished) next hop tunnel, Google Cloud uses equal-cost multipath\n(ECMP) routing to distribute packets among the tunnels.\n\nThis balancing method is based on a hash, so all packets from the same flow use\nthe same tunnel as long as that tunnel is up.\n\nTo test ECMP behavior, use [iperf3](/community/tutorials/network-throughput)\nto send multiple simultaneous TCP streams, ideally from multiple\nGoogle Cloud virtual machine (VM) instances,\nthrough Cloud VPN tunnels. If you need to validate ECMP behavior, do\nnot use ICMP (`ping`) to perform tests. A `ping` test from one VM instance isn't\nsufficient to test ECMP-based egress through Cloud VPN tunnels\nbecause only one tunnel is selected when you have a fixed source and destination.\nICMP has no concept of ports and is a fixed protocol, so the hash is only\ncalculated from two pieces of information: the source and destination addresses\n(a two-tuple hash).\n\nWhat's next\n-----------\n\n- To learn about the basic concepts of Cloud VPN, see the [Cloud VPN overview](/network-connectivity/docs/vpn/concepts/overview).\n- To help you solve common issues that you might encounter when using Cloud VPN, see [Troubleshooting](/network-connectivity/docs/vpn/support/troubleshooting)."]]
