Using Subnetworks

Prerequisites for this guide

• Complete a Getting Started tutorial.
• Install the gcloud command-line tool if you want to use the command-line examples in this guide.

Contents

Subnetworks

We are pleased to release the Alpha version of Subnetworks for the Google Cloud Platform. Subnetworks allows you to set up your own private cloud topology within Google Cloud. With this release you can segment your Cloud network IP space into prefixes (subnetworks).

The key benefits of this release of Subnetworks are:

• Subnetworks allow you to regionally segment the network IP space into prefixes (subnets) and control which prefix a VM instance’s internal IP address is allocated from.
• When using VPN, subnetworks allow you to configure your VPN gateway to have different destination IP ranges for separate regions in the same network. This allows additional control over how you configure your VPN routes. This also results in lower latency in cases where the VPN would previously have to assume the IP range spanned across all regions.
• Subnetworks in a network do not all have to come from the same larger prefix. Some subnetworks can use ranges from 10.0.0.0/8 while others use ranges from 192.168.0.0/16. This provides the granularity and flexibility for customers to efficiently configure the unused ranges in their private IP address space without having to rearrange existing allocated IP ranges.

This document describes how to set up and use Subnetworks, including changes to other networking features such as VPN, instance groups, and load balancing, and describes how they interact with subnetworks.

This document describes the behavior of the system in the following modes:

• Legacy (non-subnetwork) mode is the original approach for networks, where IP address allocation occurs at the global network level. This means the network address space spans across all regions. It is still possible to create a legacy network, but subnetworks are the preferred approach going forward.
• Subnet mode describes the new form of networks going forward in which regional subnetworks are created within a network. Each subnetwork controls the IP address range used for VMs that are allocated to that subnetwork. The IP ranges of the different subnetworks in a network may be non-contiguous. There are two options for using subnetworks:
  • Auto Subnet Network automatically assigns a subnetwork IP prefix range to each region in your network. The instances created in a zone in a specific region in your network get assigned an IP allocated from the regional subnetwork range.
  • Custom Subnet Network allows you to manually define subnetwork prefixes for each region in your network. There can be zero, one, or several subnetwork prefixes created per region for a network. In order to create an instance in a zone, you must have previously created at least one subnetwork in that region. At instance creation time, you will need to specify the subnetwork in the region that the instance IP should be allocated from.

For Alpha, the default network in a new project is still a legacy network.

Alpha Restrictions

• You cannot change the type of the network (i.e., you cannot change an auto subnet network to a custom subnet network and vice versa).
• You cannot change the IP prefix of a subnetwork once it is created.
• Auto subnet networks do not have default firewall rules.
• For VPNs, the --ike-networks field does not support IP ranges that do not belong to the network IPv4 range of the VPN gateway.
• The following restrictions exist with use of Subnetworks with other products:
  • Google Container Engine: Supported only on auto subnetwork network. Specifying a custom subnet network in the Container Cluster creation will lead to an error notifying that custom subnet networks are not supported. You are allowed to create a Container Cluster with an auto subnet network.
  • Google Cloud Dataproc: Supported only on auto subnet network. Specifying a custom subnet network in the Cluster Configuration will lead to an invalid configuration. You are allowed to specify an auto subnet network in your Dataproc Cluster configuration.
  • Click to Deploy: Supported only on auto subnet network. The custom subnet networks are not supported in the Click to Deploy configuration and can’t be used to deploy applications.
  • Cloud Launcher: Supported only on auto subnet network. The custom subnet networks are not supported for Cloud Launcher deployments.
  • Deployment Manager: Supported only on auto subnet network. The custom subnet networks are not supported for Deployment Manager configuration.
  • Cloud Router: Cannot be deployed in a subnet (both auto and custom) network.
  • Google Managed VMs: Cannot be deployed in a subnet (both auto and custom) network.
• Quotas:
  • 25 subnetworks per project. There are no restrictions on how these subnetworks are allocated per network or per region within a project.
  • The maximum number of CIDR ranges when creating VPN Tunnel, specified in the --ike-networks field is 128.

Legacy (non-subnet) Network

In a traditional Compute Engine network, you define a single network IPv4 prefix range for all the instances attached to that network, and that network spans all Cloud regions.

A network belongs to only one project and each instance can only belong to one network. All projects include a default network named default. The default network is automatically created for you, and you do not need to take any action to initialize it. For many Compute Engine users, the default network is all that is needed. The default network functions just like any network you would create, so you can add or remove firewall rules from it or delete it altogether. Generally, most users only need one network, although you can have up to five networks per project.

You can create up to four additional networks for a single project to help manage your instances. Creating multiple networks for a project can help you isolate sets of instances, as instances in different networks can only communicate with each other through external IP addresses. For example, you might want to keep instances in your testing and production systems from talking to one another except through external IPs. Putting the instances in different networks can accomplish this.

Each instance within a project gets assigned an IPv4 address from a network IPv4 range. The IPv4 address assignment of instances are not aggregatable by zone or region. They are globally aggregatable to the single network IPv4 range. Therefore, any given range of IPs can be spread across all regions, and the IP addresses of instances created within a region are not necessarily contiguous. This is not ideal because:

• You can't group IP spaces by region
• If you want to group your VMs into separate IP spaces, you have to use the network as the grouping mechanism, and this is problematic if you want the groups of VMs to talk to each other because the communication across networks is only possible through external public IP space. This means with legacy networks, the network is the only available IP grouping mechanism. There is no mechanism for grouping IPs within the network.

The figure below shows a traditional network, which we now call a Legacy (non-subnet) network. Traffic from the Internet passes through a global switching function in the network (shown in the diagram as a virtual switch), then down to individual instances.

Instances in a region may have IP addresses that are not grouped in any way. As shown in the example, instances from 10.240.0.0/16 are spread unpredictably across regions 1 and 2. For example, 10.240.0.4 is in region 2, 10.240.0.5 is in region 1, and 10.240.0.6 is in region 2.

Subnet Network

With the introduction of subnetworks, a global network IPv4 prefix range is not required. Instead, a network can contain multiple subnetworks, each with its own IPv4 prefix. Subnetworks belonging to a single network must have non-overlapping RFC1918 ranges. Subnetworks belonging to a single network can have non-contiguous IPv4 address prefixes (e.g., 10.240.0.0/16 and 192.168.0.0/16). A subnetwork belongs to only one network and each instance can only belong to one subnetwork. For Alpha, each project can have up to 5 networks and up to 25 subnetworks in total. These 25 subnetworks can all be in the same network or spread across all networks.

Creating multiple subnetworks for a project can help you group instances by functionality or organizational department. Instances in different subnetworks can communicate with each other using their internal IPs, as long as they belong to the same network. Instances belonging to two different networks can only communicate using external IPs. For example, if you want to keep instances in your testing and production systems from talking to one another except through external IPs, you can put the instances in different networks.

Each instance created within a subnetwork gets assigned an IPv4 address from that subnetwork's range. Instances within a subnetwork are within the same IPv4 range.

The figure below shows a subnet network. A new instance takes its IP address from the given subnetwork's prefix. Subnet1 is in region 1 and has all of its private IPs allocated from 10.240.0.0/24 (instance IPs 10.240.0.1 and 10.240.0.2), and Subnet2 in region 2 has all of its private IPs allocated from 192.168.1.0/24 (instance IPs 192.168.1.1 and 192.168.1.2). You can also see that Subnet3 crosses zones within a region. Subnetworks are not restricted by zone (only region), though you can choose to create instances from one subnet in one zone and instances from another subnet in a separate zone if you desire.

Subnetworks features

Subnetworks partitions your network into predictable IP address ranges. Subnetworks have the following key properties:

• Each subnetwork has a known IP address space. All instances created in that subnetwork have internal IP addresses assigned from a CIDR range.
• Subnetwork ranges can be automatically allocated (auto subnet network) or specifically chosen by you (custom subnet network).
• In the case where the subnetwork ranges are specifically chosen by you (custom subnet network), the network can have zero, one, or many subnetwork CIDR ranges in a given region.

Subnetworks has the following benefits:

• When using two or more subnetworks as the target of a VPN gateway, VPN will optimize the routing of the traffic to the correct subnetwork, instead of routing it across the whole network like it does with the legacy network.
• The overall network IP space does not have to be determined at project creation. You can add new subnetworks as needed.
• Subnetworks provide a mechanism for aggregating IP addresses based on functional groups or organizational departments, while allowing them to communicate internally through the private RFC1918 spaces. Now that you have finer control over your cloud network address space, this can make the management of your on-premises network and your cloud network easier.

Subnetwork IP ranges

Subnetwork ranges can be automatically or manually configured. This section describes both kinds of ranges.

There are 4 reserved addresses per subnetwork, which are:

• Network address
• Broadcast address
• Gateway IP address (first address in the CIDR range)
• Reserved address (second last address in the CIDR range)

The minimum subnetwork size that can be used is /29.

Auto subnet IP ranges

When using an auto subnet network, a subnetwork is created automatically for that network in every region. The following table shows the automatically configured IP ranges for each region. Every auto subnet network uses these ranges.

Region	Default IP range
us-central1	10.128.0.0/20
us-east1	10.142.0.0/20
europe-west1	10.132.0.0/20
asia-east1	10.140.0.0/20

Custom subnet IP ranges

Manually created subnetworks (that can only be created in custom subnet networks), can use any valid RFC1918 IP range. Ranges do not have to be contiguous between subnetworks. For example, some subnetworks can use ranges from 10.0.0.0/8 while others use ranges from the 192.168.0.0/16 space. Ranges must be unique and non-overlapping within a network.

Subnetworks and other resources

This section describes how subnetworks relate to other Google Cloud resources. It also shows how to create networks, subnetworks, and other resources that depend upon subnetworks.

The glcoud Tool Guide has more information about the commands used in these procedures.

Networks and subnetworks

When you create a new subnet network, you can either accept the auto-created subnet allocations or specify your own.

Creating a new network with auto-created subnetwork ranges

1. Create a new network in your project with automatically allocated subnetworks. The --mode specifies auto, indicating you would like the subnetworks to be automatically created with pre-set IP blocks. Because this is a subnet network, there is no network level IPv4 range or gateway IP, so none will be displayed.

   $ gcloud alpha compute networks create auto-network1 \
       --mode auto
   NAME          MODE IPV4_RANGE GATEWAY_IPV4
   auto-network1 auto
   

2. List your new auto-created subnetworks.

   $ gcloud alpha compute networks subnets list
   NAME                           REGION          NETWORK       RANGE
   auto-network1-32a78da3f394f263 asia-east1      auto-network1 10.140.0.0/20
   auto-network1-5ad75e5199508b76 us-central1     auto-network1 10.128.0.0/20
   auto-network1-588b39c7379d3c22 europe-west1    auto-network1 10.132.0.0/20
   

Creating a new network with custom subnet ranges

In manually assigning subnetwork ranges, you first create a custom subnet network, then create the subnetworks you want within a region. You do not have to specify subnetworks for all regions right away, or even at all, but you cannot create instances in regions that have no subnetwork defined.

When creating a new subnetwork, its name has to be unique in that project for that region, even across networks. The same name can appear twice in a project, as long as each one is in a different region.

Because this is a subnet network, there is no network level IPv4 range or gateway IP, so none will be displayed.

1. Create a new custom subnet network in your project.

   $ gcloud alpha compute networks create custom-network1 \
       --mode custom
   NAME            MODE   IPV4_RANGE GATEWAY_IPV4
   custom-network1 custom
   

2. Specify the subnetwork prefix for your first region. In this example, we're assigning 192.168.1.0/24 to region us-central1.

   $ gcloud alpha compute networks subnets create subnet-us-central-192 \
     --network custom-network1 \
     --region us-central1 \
     --range 192.168.1.0/24
   NAME                  REGION      NETWORK         RANGE
   subnet-us-central-192 us-central1 custom-network1 192.168.1.0/24
   

3. Specify the subnetwork prefix for your second region. In this example, we're assigning 192.168.5.0/24 to region europe-west1.

   $ gcloud alpha compute networks subnets create subnet-europe-west-192 \
     --network custom-network1 \
     --region europe-west1 \
     --range 192.168.5.0/24
   NAME                   REGION       NETWORK         RANGE
   subnet-europe-west-192 europe-west1 custom-network1 192.168.5.0/24
   

4. Specify the subnetwork prefix for your third region. In this example, we're assigning 192.168.7.0/24 to region asia-east1.

   $ gcloud alpha compute networks subnets create subnet-asia-east-192 \
      --network custom-network1 \
      --region asia-east1 \
      --range 192.168.7.0/24
   NAME                 REGION     NETWORK         RANGE
   subnet-asia-east-192 asia-east1 custom-network1 192.168.7.0/24
   

5. List your networks. If you also created an auto subnet network in the prior section, those subnets will be listed as well.

   $ gcloud alpha compute networks subnets list
   NAME                           REGION          NETWORK         RANGE
   subnet-europe-west-192         europe-west     custom-network1 192.168.5.0/24
   subnet-us-central-192          us-central1     custom-network1 192.168.1.0/24
   subnet-asia-east-192           asia-east1      custom-network1 192.168.7.0/24
   

Creating a legacy network

You can still create a legacy (non-Subnet) network. Legacy networks have a single global IP range. You cannot create subnetworks in a legacy network or switch from legacy to auto or custom subnet networks.

1. Create a new legacy network in your project.

   $ gcloud alpha compute networks create legacy-network1 \
       --mode legacy \
       --range 10.240.0.0/16
   Created
   [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/networks/legacy-network1].
   NAME            MODE   IPV4_RANGE    GATEWAY_IPV4
   legacy-network1 legacy 10.240.0.0/16 10.240.0.1
   

Listing existing subnetworks

You can list all subnetworks in an existing network.

1. List general details on all subnetworks. (If you run this command on a project that has not been whitelisted for alpha, you will get an error that says Invalid choice: 'subnets'.)

   $ gcloud alpha compute networks subnets list
   NAME                           REGION          NETWORK         RANGE
   auto-network1-588b39c7379d3c22 europe-west1    auto-network1   10.132.0.0/20
   europe-west-192                europe-west     custom-network1 192.168.5.0/24
   auto-network1-5ad75e5199508b76 us-central1     auto-network1   10.128.0.0/20
   us-central-192                 us-central1     custom-network1 192.168.1.0/24
   asia-east-192                  asia-east1      custom-network1 192.168.7.0/24
   auto-network1-32a78da3f394f263 asia-east1      auto-network1   10.140.0.0/20
   

You can tailor the list by providing additional parameters:

• --regions REGION,[REGION,...]] Restrict the list to subnets in particular regions.
• --network NETWORK Restrict the list to only subnets in a particular network.

Describe an existing subnetwork

The describe command provides details on the indicated subnetwork.

1. Get details on an existing subnetwork

   $ gcloud alpha compute networks subnets describe subnet-asia-east-192 \
     --region asia-east1
   creationTimestamp: '2015-10-21T15:58:35.271-07:00'
   gatewayAddress: 192.168.7.1
   id: '2048026325272602228'
   ipCidrRange: 192.168.7.0/24
   kind: compute#subnetwork
   name: subnet-asia-east-192
   network: https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/networks/custom-network1
   region: https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/regions/asia-east1
   selfLink: https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia-east-192
   

Delete a subnetwork or network

You can delete any subnetwork in your project. You can also delete an entire network. You cannot delete a network or subnetwork that still has instances or resources.

Delete a subnetwork

You can only delete manually created subnetworks. Automatically created subnetworks can not be deleted individually; you have to delete the entire network.

You cannot delete any subnetwork that still has instances, manually created routes, or other manually created resources using it.

    $ gcloud alpha compute networks subnets delete subnet-asia-east-192 \
        --region asia-east1
    The following subnetworks will be deleted:
     - [subnet-asia-east-192] in [asia-east1]
    Do you want to continue (Y/n)?  y
    Deleted [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/regions/asia-east1/subnetworks/subnet-asia-east-192].

Delete a network

For a legacy network, you can explicitly delete the network resource only if:

• The network resource is not in use by any resources.

For an auto subnet network, you can explicitly delete the network resource only if:

• Any child subnetworks it has are not in use by any other resource AND
• The network resource is not in use by any other resources.

Example resources in use that restrict the deletion for the above include firewalls, custom routes, instances, target VPN gateways, and routers.

For a custom subnet network, the network can only be deleted if all child subnetworks have been deleted.

1. Delete the network

   $ gcloud alpha compute networks delete auto-network1
   The following networks will be deleted:
    - [auto-network1]
   Do you want to continue (Y/n)?  y
   Deleted [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/networks/auto-network1].
   

Subnetworks and instances

A subnetwork spans all of the zones within the region it is created in. However, when you create an instance, you specify which zone it is in and which subnetwork it is in. So, you can create one set of instances in subnetwork1 and in zone1 of region1 while another set of instances is in subnetwork2 and in zone2 of region1.

Create an instance in a subnetwork

This command creates an instance in the specified subnetwork and zone. Note that you cannot specify both the --network and --subnet parameters for this command. For other, non-subnetwork-related instance parameters, see gcloud compute instances create in the Cloud SDK documentation.

    $ gcloud alpha compute instances create instance1 \
       --zone us-central1-a \
       --subnet us-central-192
    Created [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/us-central1-a/instances/instance1].
    NAME      ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP   STATUS
    instance1 us-central1-a n1-standard-1             192.168.1.4 70.32.154.181 RUNNING

Subnetworks and load balancing

When creating a Managed Instance Group for HTTP(S) load balancing, you may now optionally specify a subnetwork in the Instance Template used by the Managed Instance Group.

Create an instance template that specifies a subnetwork

Instance template commands now have optional --subnet and --region flags that you can use so that new instances created will be placed into the subnetwork of your choice. Note, the subnet cannot be changed in the instance template after the instance template is created. The --subnet flag requires the --region flag. The subnetwork must exists before it can used in instance template creation.

    $ gcloud alpha compute instance-templates create template1 \
        --region us-central1 \
        --subnet subnet-us-central-192
    Created [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/instanceTemplates/template-qa].
    NAME        MACHINE_TYPE  PREEMPTIBLE CREATION_TIMESTAMP
    template-qa n1-standard-1             2015-10-23T20:34:00.791-07:00

Using this template to create instances for a Managed Instance Group (with or without autoscaling) automatically creates the instance in the specified region and subnetwork. This lets you control the subnetwork of new instances created for load balancing.

Subnetworks and firewall rules

Firewalls are global resources attached to a single network, not regional resources. Firewall rules apply to all instances in a network. This means you can add a firewall rule that allows traffic between instances within the same network, even across subnetworks.

There are no changes to firewall rules with the introduction of subnetworks. The default firewall rules applied to the default network remain the same. Also, any existing firewall rules you may have created remain unchanged. Any networks you create subsequently in a project have no default firewall rules. In the absence of firewall rules, all inbound communication is blocked by default. Firewall rules have to be created as required to allow traffic into VMs in non-default networks.

User-created networks don't contain default firewall rules. You have to create specific firewall rules allowing traffic to flow between the subnetworks that are created.

For two subnetworks to exchange traffic, “allow” permissions have to be configured in both directions.

Refer to Managing Firewalls for detailed documentation.

Isolation of Subnetworks

In the default network, by default, all virtual machine instances within a network can communicate with each other, due to the default firewall rules described above. On the other hand, user defined networks do not have default firewall rules, so instances cannot be reached, even by other instances, until you define appropriate firewall rules.

Normally, all firewall rules apply to all instances in the network. However, you can add tags to certain instances and use those tags in firewall rules, thus creating rules that only apply to certain instances. Tags can be applied to instances either individually or through instance templates. You can use these tags to create additional isolation between subnetworks by selectively allowing only certain instances to communicate. If you arrange for all instances in a subnetwork to share the same tag, you can specify that tag in firewall rules to simulate a per-subnetwork firewall. For example, you can tag all instances in subnet-a with the tag tag-subnet-a and use the that tag in firewall rule target-tags. You can also use source-ranges in firewall rules.

Assume that you have a network 'my-network' with 3 subnetworks:

• 'subnet-a' with IP prefix 192.168.2.0/24
• 'subnet-b' with IP prefix 10.128.0.0/16
• 'subnet-c' with IP prefix 10.240.0.0/16

Communication is allowed between 'subnet-a' and any other subnet, but must be blocked between 'subnet-b' and 'subnet-c':

These are the configuration steps required:

1. Tag the instances in the Subnetworks
   Configure all your instances in a subnetwork with a common tag (e.g. tag-subnet-a for subnetwork 'subnet-a', etc.):

   $ gcloud compute instances add-tags example-instance-subnet-a \
       --tags tag-subnet-a --zone us-central1-b
   Updated [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/us-central1-b/instances/example-instance-subnet-a].
   $ gcloud compute instances add-tags example-instance-subnet-b \
       --tags tag-subnet-b
   Updated
   [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/us-central1-b/instances/example-instance-subnet-b].
   $ gcloud compute instances add-tags example-instance-subnet-c \
   --tags tag-subnet-c
   Updated
   [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/us-central1-b/instances/example-instance-subnet-c].
   

   Note that you can tag your instances at creation time ($ [gcloud compute instances](/sdk/gcloud/reference/compute/instances/add-tags) create example-instance-subnet-a .... --tag tag-subnet-a)

If all your instances in the subnetwork are of the same type, you can group them into a managed instance group and use an instance template to give them all the same tag automatically.

1. Create the firewall rules to enable communication between subnet-a and subnet-b and between subnet-a and subnet-c.

   Allow traffic sourced in subnet-a CIDR (192.168.2.0/24) to all the instances belonging to subnet-b (tagged with tag-subnet-b) and to subnet-c (tagged with tag-subnet-c):

   $ gcloud compute firewall-rules create allow-subnet-a \
      --allow tcp,udp,icmp \
      --source-ranges 192.168.2.0/24 \
      --target-tags tag-subnet-b,tag-subnet-c
   Created [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/firewalls/allow-subnet-a].
   NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
   allow-subnet-a my-network 19.168.2.0/24 tcp,udp,icmp          tag-subnet-a,tag-subnet-c
   

2. Allow traffic sourced in subnet-b CIDR (10.128.0.0/16) to all the instances belonging to only subnet-a (tagged with tag-subnet-a):

   $ gcloud compute firewall-rules create allow-subnet-b \
      --allow tcp,udp,icmp \
      --source-ranges 10.128.0.0/16 \
      --target-tags tag-subnet-a
   Created [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/firewalls/allow-subnet-b].
   NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
   allow-subnet-b my-network 10.128.0.0/16 tcp,udp,icmp          tag-subnet-a
   

3. Allow traffic sourced in subnet-c CIDR (10.240.0.0/16) to all the instances belonging to only subnet-a (tagged with tag-subnet-a):

   $ gcloud compute firewall-rules create allow-subnet-c \
      --allow tcp,udp,icmp \
      --source-ranges 10.240.0.0/16 \
      --target-tags tag-subnet-a
   Created [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/global/firewalls/allow-subnet-c].
   NAME           NETWORK    SRC_RANGES    RULES        SRC_TAGS TARGET_TAGS
   allow-subnet-c my-network 10.240.0.0/16 tcp,udp,icmp          tag-subnet-a
   

Isolation of subnetworks B and C is achieved by not explicitly allowing B and C to exchange traffic.

Subnetworks and routes

Routes are global resources attached to a single network, not regional resources. User-created routes apply to all instances in a network. This means you can add a route that forwards traffic from instance to instance within the same network, even across subnetworks, without requiring external IP addresses. By default, routes exists between subnetworks.

Default routes

Certain default routes are created when you create a subnetwork or if you create a legacy network.

For subnet networks

Two default routes are created at network creation time.

• A default route is created per subnetwork for local traffic in the network, allowing VM instances in any subnetwork to send traffic to instances in any other or same subnetwork in that network. This route counts against overall route quota. The overall route quota for a project is currently 100, and each subnet created uses one route against the quota. Note that networks you create do not have firewall rules yet, so even though there are routes pointing to instances, the firewall will prevent traffic to instances until you add firewall rules.
• A default route for Internet traffic (0/0) is created when the network is created.

For legacy networks

Two default routes are created at network creation time.

• For the destination IP range within the IPv4 range of the network, a virtual network route is defined. For the default legacy network, default firewall rules are also automatically created, so traffic between instances is allowed from the beginning. For manually created legacy networks, you have to create firewall rules that allow inbound traffic to instances.
• A default route for Internet traffic (0/0) is created.

For instructions on creating additional routes, see the gcloud compute routes create command.

Routes and VPN tunnels

If you want to apply routes to a subnetwork only, you must apply the routes specifically to the instances that are part of the subnetwork.

Consider the following scenario, in which you have a network with two custom subnet networks: subnet-a and subnet-b. You want to route traffic from subnet-a to VPN tunnel to reach the peer network, but you do not require subnet-b to be able to route traffic through VPN tunnel-a.

The steps to apply routes to subnet-a only in the above scenario are:

1. Configure all your instances in a subnet-a with a common tag (e.g., tag-subnet-a):

   $ gcloud compute instances add-tags example-instance-subnet-a \
       --tags tag-subnet-a
   Updated [https://www.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/us-central1-b/instances/example-instance-subnet-a].
   

Note that you can tag your instances at creation time ($ [gcloud compute instances](/sdk/gcloud/reference/compute/instances/add-tags) create example-instance-subnet-a .... --tag tag-subnet-a)

1. Add a static route to all the VMs in subnet-a. This route has as its destination the peer prefix 192.168.1.0/24 and a next hop of tunnel-a.

   $ gcloud compute routes create route-via-tunnel \
       --destination-range 192.168.1.0/24 \
       --network my-network \
       --tags tag-subnet-a \
       --next-hop-vpn-tunnel tunnel-a
   

Subnetworks and VPN

Subnetworks provides a way for VM instances to be grouped by a common IP prefix. Such a grouping is useful in configuring policy (static routes) based VPN. Subnetworks enhances Cloud VPN functionality by providing control on what IP prefixes need to be announced on policy based VPNs by enabling on-premise VPN device to set up routing policy based on subnetwork prefixes, likely reducing latency between on-premise and Cloud networks.

Consider the following configuration. Without subnetworks, if you run VMs in two regions you'll need the following topology:

With a legacy network there is no control over the IP allocations, the IP prefix is fragmented between the US East and Europe regions. When your on-site VPN gateway has to make a routing decision it has no choice but to ECMP packets across both links.

When a host in the on-premise networks sends packets to VMs in Europe, roughly 50% of these packets will go via the US East region, potentially adding to the VPN latency.

With subnetworks, if you define the two subnetworks such that 10.240.1.0/24 is in US East and 10.240.2.0/24 is in Europe, then they will have the following topology shown in the following diagram.

With this approach, your peer VPN gateway has a routing table that allows it to direct packets to the correct region based on where the instance is located, thereby reducing average latency.

Subnetworks lets VM instances to be grouped regionally with a common IP prefix. This regionally grouped IP prefix can be statically announced during VPN tunnel creation. Users have flexibility to choose which subnetwork prefixes have to be announced to peer VPN endpoint at the VPN tunnel creation time.

Creating a Compute Engine VPN gateway

Compute Engine VPN gateway creation does not change with Subnetwork. See the gcloud compute target-vpn-gateways create Cloud SDK documentation.

Creating a VPN tunnel

With subnetworks, you must specify which Google Cloud CIDR ranges are valid for a VPN tunnel. These ranges are set when the tunnel is created and may not be changed afterwards because they are used during the IKE handshake on connect.

If the network of the VPN gateway is a legacy network, the --ike-networks field can be used to specify the Google Cloud CIDR ranges to forward through the tunnel. However, since the IP addresses for a legacy network are not allocated predictably across regions, this can result in inefficient performance for your VPN due to ECMP if you are using multiple regions as described in the above example.

If the network of the VPN gateway is in auto subnet network, the CIDR of the subnetwork in the same region as the VPN gateway is automatically announced to the peer VPN, while the IP prefixes of subnetworks from other regions are not. Therefore, if you wish to use the VPN for only the region's subnetwork traffic the VPN was created in and no other region's traffic, you can omit the --ike-networks field. If you want to use additional CIDR ranges in addition to the subnetworks in the VPN's region, you can specify the required ranges in the --ike-networks field.

If the network of the VPN gateway is a custom subnet network, no IP prefix is announced to the peer VPN by default. Use the --ike-networks field to specify the IP prefixes for the subnetworks that will be routed through the tunnel.

For all networks, in order to route traffic from VMs to the VPN tunnel, you would have to add routes in all the VMs sending traffic through the VPN. As a reminder, routes defined in a network are applied to all the VMs in such network. In order to apply routes to the tunnel to only specific subnetworks, all the VMs in that subnetwork must be configured with a common tag and the route must be configured to apply only to such target-tag.

The maximum number of CIDR ranges specified in --ike-networks is 128.

Configuration of VPN in the different types of networks

Auto subnet networks

Configuring VPN use to subnetwork in the region where VPN gateway exists

In an auto subnet network, one subnetwork is automatically created with a pre-defined CIDR range for every region in the network. For a VPN tunnel associated to an auto subnet network, if --ike-networks parameter is omitted, only the IP prefix of the subnetwork in the same region as the VPN gateway is announced to the remote peer.

Consider the following scenario in an auto subnet network, in which only subnetwork-b, located in the same region as the VPN, is allowed to use the tunnel and not other subnetworks in other regions:

To create a VPN tunnel with an auto-created subnetwork, use the normal VPN instructions, but change the following steps as shown:

Step 2: Create a VPN Gateway in network my-autosubnet-network and region region-b.

    $ gcloud alpha compute target-vpn-gateways create target-vpn-gateway-b \
        --network my-autosubnet-network \
        --region region-b

Step 7: Create the VPN tunnel tunnel-b:

    $ gcloud alpha compute vpn-tunnels create tunnel-b \
       --peer-address PEER_IP_ADDRESS \
       --region region-b \
       --shared-secret SHARED_SECRET \
       --target-vpn-gateway target-vpn-gateway-b

Since --ike-networks is omitted, only subnetwork-b CIDR 10.130.0.0/16 is announced during tunnel creation. In other words, only traffic from VMs in subnetwork-b will be allowed through VPN tunnel-b.

Step 7: Add a static route to all the VMs in subnetwork-b. This route has as its destination the peer prefix 192.168.0.0/16 and a next hop of tunnel-b.

    $ gcloud alpha compute routes create route-via-tunnel \
        --destination-range 192.168.0.0/16 \
        --network my-autosubnet-network \
        --next-hop-vpn-tunnel-region region-b \
        --next-hop-vpn-tunnel tunnel-b

Configuring VPN use for any subnetworks in any regions

In an auto subnet network, it is possible to specify the IP prefixes that are announced during handshake. That allows to have more control on from/to which prefixes traffic will be allowed through the VPN tunnel.

In order to allow subnetwork in region A to send and receive traffic through the tunnel in region-b, you can configure that the range 10.128.0.0/16 to be used in the IKE exchange of tunnel-b.

Consider the following scenario in which there is a VPN tunnel in region-b that is made available for use by other subnetworks outside region-b, in this specific case by subnetwork-a in region-a:

To create a VPN tunnel with an auto-created subnetwork and specifying --ike-networks, use the normal VPN instructions, but change the following steps as shown. Note that because we are using the --ike-networks parameter, all necessary network, including the network local to the tunnel, must be specified.

Step 2: Create a VPN Gateway in network my-autosubnet-network and region region-b.

    $ gcloud alpha compute target-vpn-gateways create target-vpn-gateway-b \
       --network my-autosubnet-network \
       --region region-b

Step 7: Create a VPN tunnel tunnel-b :

    $ gcloud alpha compute vpn-tunnels create tunnel-b \
       --peer-address PEER_IP_ADDRESS \
       --region region-b \
       --shared-secret SHARED_SECRET \
       --ike-networks 10.128.0.0/16,10.130.0.0/16 \
       --target-vpn-gateway target-vpn-gateway-b

By adding --ike-networks with CIDRs from subnetwork-a (10.128.0.0/16) and subnetwork-b (10.128.0.0/16), traffic from any VMs in those subnetworks will be allowed through the tunnel.

Step 8: Add a common tag to all your instances in subnetwork-a and subnetwork-b:

    $ gcloud compute instances add-tags example-instance-subnet-a \
        --tags tag-subnet-a
    $ gcloud compute instances add-tags example-instance-subnet-b \
        --tags tag-subnet-b

Step 9: Add a static route to all the VMs in subnetwork-a and subnetwork-b. This route has as destination peer prefix 192.168.0.0/16 and a next hop of tunnel-b.

    $ gcloud alpha compute routes create route-via-tunnel \
        --destination-range 192.168.0.0/16 \
        --network my-autosubnet-network \
        --next-hop-vpn-tunnel-region region-b \
        --next-hop-vpn-tunnel tunnel-b \
        --tags tag-subnet-a,tag-subnet-b

Custom subnet networks

Configuring VPN use by any subnetworks in any region

In custom subnet networks, there could be one or more subnetworks for a network in the region, and the IP ranges associated to those subnetworks are configured by you. Therefore, the IP prefixes to be announced must always be configured in --ike-networks. The absence of --ike-networks configured in the VPN tunnel in a custom subnet network will return an error.

Consider the following scenario in which there is a custom subnet network with a subnetwork-a in region-a with CIDR range 172.16.0.0/16 and a subnetwork-b in region-b with CIDR range 10.21.0.0/16. With the following configuration, VPN in region-b can ONLY be used by subnetwork-b:

To create a VPN tunnel with a custom subnet, use the normal VPN instructions, but change the following steps as shown:

Step 2: Create a VPN Gateway in network my-custom-network and region region-b.

    $ gcloud alpha compute target-vpn-gateways create target-vpn-gateway-b \
       --network my-custom-network \
       --region region-b

Step 7: Create a VPN tunnel tunnel-b:

    $ gcloud alpha compute vpn-tunnels create tunnel-b \
       --peer-address PEER_IP_ADDRESS \
       --region region-b \
       --shared-secret SHARED_SECRET \
       --ike-networks 10.21.0.0/16 \
       --target-vpn-gateway target-vpn-gateway-b

You MUST add --ike-networkswith the CIDR of subnetwork-b. An error will be returned if there is no --ike-networks configured in the VPN tunnel in a custom subnet network.

Step 8: Add a common tag to all your instances in subnetwork-b:

    $ gcloud compute instances add-tags example-instance-subnet-b \
        --tags tag-subnet-b

Step 9: Add a static route to all the instances in subnetwork-b. This route has as destination peer prefix 192.168.0.0/16 and as the next hop tunnel-b.

    $ gcloud alpha compute routes create route-via-tunnel \
        --destination-range 192.168.0.0/16 \
        --network my-custom-network \
        --tags tag-subnet-b \
        --next-hop-vpn-tunnel-region region-b \
        --next-hop-vpn-tunnel tunnel-b

FAQ

Addressing

Q: Can I change a legacy network to a subnet network?

A: Legacy network cannot be converted to subnet network.

Q: What are the valid IP prefixes for subnetworks?

A: Private Address space as defined by RFC 1918 are the valid IP prefixes for subnetworks.

Q: Can subnetworks have overlapping IP prefixes?

A: Within a network, two subnetworks may not have overlapping IP prefixes. Two subnetworks in two different networks may have duplicate or overlapping IP prefixes.

Q: Should IP prefixes of subnetworks be contiguous in a single Network?

A: Subnetworks within a single network need not be contiguous and can have discrete IP prefixes. For example: lab-subnetwork (10.240.1.0/24) and prod-subnetwork (192.168.1.0/24) is a valid subnetwork configuration.

Q: I want to limit all my instances to a single zone and to a single subnetwork. How can I achieve the zonal scope ?

A: When creating instances, always select the same zone and subnetwork.

Q: Do auto-created subnetworks always have the same IP ranges in each region.

A: Yes, see Automatically configured IP ranges.

Routes and Firewalls

Q: Can instances in subnetworks in the same network communicate with each other by default?

A: Yes. All instances in the same network can communicate with each other, even across subnetworks, using internal IP addresses. However, firewall rules have to be created to allow it across subnetworks.

Q: Can I prevent two subnetworks within a network from communicating?

A: Yes, Subnetworks with a network can be blocked from exchanging traffic by using firewall rules. See Isolation of Subnetworks.

VPN

Q: I have created a VPN for an auto subnet network and I can only use it from the subnet that is co-located in the same region by default. Can I use the VPN globally for auto subnet networks, like I did with legacy networks?

A: See VPN configuration in auto subnet network

Scenarios

Q: In what scenarios are auto subnet networks recommended?

A: Auto subnet networks are a quick starter configuration for users who want to focus on deploying applications rather than defining network topology and IP addressing.

Q: How to deploy a multi-tier (Web, API, DB) application in a single network, but with ability to isolate each tier as desired?

A: During network creation, create a custom subnet network. Create 3 subnetworks, one for each tier. E.g., 10.240.10.0/24 (Web), 10.240.30.0/24 (API), 10.240.50.0/24 (DB). See Isolation of Subnetworks to isolate Web from DB subnetworks and vice versa.

Q: How to deploy a Dev, Test, and Prod environment for my application in a single network, and still isolate each environment from one another?

A: During network creation, create a custom subnet network. Create 3 subnetworks, one for each environment. E.g. 10.240.10.0/24 (Dev), 192.168.10.0/24 (Test) and 172.16.10.0/24 (Prod). See Isolation of Subnetworks to isolate the environments from each other.

Q: How to deploy and isolate instances of multi-tenant application?

A: Prior to subnetworks, users created one network per tenant of their multi-tenant application and one network for shared services/applications (e.g. License, Billing). The shared service application were required to have external IPs to communicate with the tenant application in another network.

Subnetworks simplifies the multi-tenant application deployment model. Users can now create one custom subnetwork per tenant. Tenant applications in each subnetwork can be isolated from one another. Shared services/applications can be in another subnetwork, with ability to reach all tenants subnetworks. Refer alpha restriction on number of subnetworks that can created.

Send feedback

For questions or feedback on Subnetworks feature, please email gcp-subnetworks-alpha@googlegroups.com. We would love to hear from you!

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.