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"]],["最后更新时间 (UTC)：2025-08-12。"],[],[],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)."]]
