Google Cloud VPC Routing
In this post I want to summarize some information about how routing in Google Cloud works. This topic is well documented from Google.
Google Cloud VPC networks
A Virtual Private Cloud (VPC) network is a virtual version of a physical network, implemented inside of Google’s production network, using Andromeda. A VPC network provides the following:
- Provides connectivity for your Compute Engine virtual machine (VM) instances, including Google Kubernetes Engine (GKE) clusters, App Engine flexible environment instances, and other Google Cloud products built on Compute Engine VMs.
- Offers native Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
- Connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
- Distributes traffic from Google Cloud external load balancers to backends.
Projects can contain multiple VPC networks. Unless you create an organizational policy that prohibits it, new projects start with a default network (an auto mode VPC network) that has one subnetwork (subnet) in each region.
The terms subnet and subnetwork are synonymous. They are used interchangeably in the Google Cloud console, gcloud commands, and API documentation.
A subnet is not the same thing as a (VPC) network. Networks and subnets are different types of resources in Google Cloud.
Virtual Private Cloud (VPC) networks are global resources. Each VPC network consists of one or more IP address range called subnets. Subnets are regional resources, and have IP address ranges associated with them.
Source: https://cloud.google.com/vpc/docs/vpc
Networks and subnets
A network must have at least one subnet before you can use it. Auto mode VPC networks create subnets in each region automatically. Custom mode VPC networks start with no subnets, giving you full control over subnet creation. You can create more than one subnet per region. For information about the differences between auto mode and custom mode VPC networks, see types of VPC networks.
When you create a resource in Google Cloud, you choose a network and subnet. For resources other than instance templates, you also select a zone or a region. Selecting a zone implicitly selects its parent region.
Because subnets are regional objects, the region that you select for a resource determines the subnets that it can use.
- When you create an instance, you select a zone for the instance. If you don’t select a network for the VM, the default VPC network is used, which has a subnet in every region. If you do select a network for the VM, you must select a network that contains a subnet in the selected zone’s parent region.
- When you create a managed instance group, you select a zone or region, depending on the group type, and an instance template. The instance template defines which VPC network to use. Therefore, when you create a managed instance group, you must select an instance template with an appropriate configuration; the template must specify a VPC network that has subnets in the selected zone or region. Auto mode VPC networks always have a subnet in every region.
- The process of creating a Kubernetes container cluster involves selecting a zone or region (depending on the cluster type), a network, and a subnet. You must select a subnet that is available in the selected zone or region.
Regions and zones
A region is a specific geographical location where you can host your resources. Regions have three or more zones. For example, the us-west1 region denotes a region on the west coast of the United States that has three zones: us-west1-a, us-west1-b, and us-west1-c.
Putting resources in different zones in a region reduces the risk of an infrastructure outage affecting all resources simultaneously. Putting resources in different regions provides an even higher degree of failure independence. This lets you design robust systems with resources spread across different failure domains.
Regions are collections of zones and a zone is a deployment area within a region.
Regarding the following fact mentioned above, I want to see this in action as shown below.
Because subnets are regional objects, the region that you select for a resource determines the subnets that it can use.
I had set up a Shared VPC network in my organization set up for Google Cloud as shown in my following post.
That Shared VPC network includes the following two IP address ranges (subnets) and each hosted in a different region.
172.24.0.0/16 in the region europe-west3 for Frankfurt/Germany
172.25.0.0/16 in the region europe-west2 for London/England
Now I have a project named Testing VMs which is attached to that Shared VPC network in order to assign VMs a network interface and IP address from.
When I now create a new VM instance I must select a region and zone where the VM resource will be hosted.
Below for example I will choose the region europe-west2 (London) for the instance.
Regarding the mentioned fact, I just can choose an interface for my VM from the second subnet 172.25.0.0/16 which is hosted in the same region as my VM instance europe-west2 (London).
The first subnet 172.24.0.0/16 hosted in the region europe-west3 (Frankfurt) is not available for the VM instance hosted in europe-west2 (London).
So take care when you select a region for you instances, that the region will host the subnet you want to assign to.
VPC Network Peering vs. VPNs
To connect and enable routing between VPCs in Google Cloud, you can either use VPC network peering or VPNs.
VPC Network Peering gives you several advantages over using external IP addresses or VPNs to connect networks, including:
- Network Latency: Connectivity that uses only internal addresses provides lower latency than connectivity that uses external addresses.
- Network Security: Service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
- Network Cost: Google Cloud charges egress bandwidth pricing for networks using external IP addresses to communicate even if the traffic is within the same zone. If however, the networks are peered they can use internal IP addresses to communicate and save on those egress costs. Regular network pricing still applies to all traffic.
For information about creating peering connections, see Use VPC Network Peering.
Source: https://cloud.google.com/vpc/docs/vpc-peering/
Routing in Google Cloud
Google Cloud routes define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These destinations can be inside your Google Cloud Virtual Private Cloud (VPC) network (for example, in another VM) or outside it.
In a VPC network, a route consists of a single destination prefix in CIDR format and a single next hop. When an instance in a VPC network sends a packet, Google Cloud delivers the packet to the route’s next hop if the packet’s destination address is within the route’s destination range.
Every VPC network uses a scalable, distributed virtual routing mechanism. There is no physical device that’s assigned to the network. Some routes can be applied selectively, but the routing table for a VPC network is defined at the VPC network level.
Each VM instance has a controller that is kept informed of all applicable routes from the network’s routing table. Each packet leaving a VM is delivered to the appropriate next hop of an applicable route based on a routing order. When you add or delete a route, the set of changes is propagated to the VM controllers by using an eventually consistent design.
Source: https://cloud.google.com/vpc/docs/routes
Below for example you will see the routing table from my productive VPC network from the Organization setup described in my following post.
The routing table you will find in the VPC network details page and the ROUTES tab. This route table will be available for all instances created in that VPC network.
Below you will see all routes for this VPC network. The routes for the destination with the prefix 192.168….. where advertised by BGP from my on-premise network. The on-premise network is connected through an IPSec route based S2S VPN tunnel as shown in my following post.
For the next Hop the VPN tunnel is assigned. Further you will see the routes to both /16 subnets from the VPC network itself. The next hop for both is here the virtual network itself.
The last route with the destination IP range 0.0.0.0/0 is the default internet gateway and will be created by default.
As mentioned above when you create a VPC network, it includes by default a system-generated IPv4 default route 0.0.0.0/0.
Therefore all instances within the VPC network, can communicate outbound to the internet by default.
In AWS in contrast you first need to create an internet gateway (IGW) and attach it to the VPC network. In Microsoft’s Azure VNet also all VMs within an Azure VNet can communicate by default outbound to the internet using the default route created from Azure.
Details about routing in AWS and Microsoft Azure you can read in my following posts.
The routes in my VPC network above where all created by Google Cloud itself besides the advertised routes from my on-premise network, they where advertised from my on-premise router (pfSense) and BGP and are so called dynamic routes in Google Cloud.
You can also add yourself static routes by clicking inside the route table on the Create Route button as shown below.
In order to create a new static route inside your VPC network, you need to select the network the route will be assigned to, the destination IP range, the priority if there is more than one matching route, the instances tags optional, if used the route will just be applied to instances they include these instances tags.
Finally you need to select the next hop the packets will be routed to.
More you will find at the following link https://cloud.google.com/vpc/docs/routes.
Links
VPC networks
https://cloud.google.com/vpc/docs/vpcSubnets
https://cloud.google.com/vpc/docs/subnetsVirtual Private Cloud (VPC)
https://cloud.google.com/vpcVPC Network Peering
https://cloud.google.com/vpc/docs/vpc-peeringRouting in Google Cloud
https://cloud.google.com/vpc/docs/routes
