Multiple VPC Networks
Multiple VPC Networks
Multiple VPC Networks
google.qwiklabs.com/focuses/1230
GSP211
Overview
In this lab, you create several VPC networks and VM instances and test connectivity
across networks. Specifically, you create two custom mode networks (managementnet
and privatenet) with firewall rules and VM instances as shown in this network diagram:
The mynetwork network with its firewall rules and two VM instances ( mynet-eu-vm
and mynet-us-vm) have already been created for you in this Qwiklabs project.
1/20
Objectives
In this lab, you will learn how to perform the following tasks:
This Qwiklabs hands-on lab lets you do the lab activities yourself in a real cloud
environment, not in a simulation or demo environment. It does so by giving you new,
temporary credentials that you use to sign in and access the Google Cloud Platform for
the duration of the lab.
Note: If you already have your own personal GCP account or project, do not use it for
this lab.
2. Copy the username, and then click . The lab spins up resources, and then opens
another tab that shows the Choose an account page.
2/20
4. The Sign in page opens.
Paste the username that you
copied from the Connection
Details panel. Then copy and
paste the password.
Note: You can view the menu with a list of GCP Products and Services by clicking the
Navigation menu at the top-left, next to “Google Cloud Platform”.
Google Cloud Shell is a virtual machine that is loaded with development tools. It offers a
persistent 5GB home directory and runs on the Google Cloud. Google Cloud Shell
provides command-line access to your GCP resources.
1. In GCP console, on the top right toolbar, click the Open Cloud Shell button.
3/20
2. In the dialog box that opens, click START CLOUD SHELL:
You can click "START CLOUD SHELL" immediately when the dialog box opens.
It takes a few moments to provision and connect to the environment. When you are
connected, you are already authenticated, and the project is set to your PROJECT_ID. For
example:
gcloud is the command-line tool for Google Cloud Platform. It comes pre-installed on
Cloud Shell and supports tab-completion.
You can list the active account name with this command:
Output:
Credentialed accounts:
- <myaccount>@<mydomain>.com (active)
Example output:
Output:
[core]
project = <project_ID>
Example output:
[core]
project = qwiklabs-gcp-44776a13dea667a6
1. In the Console, navigate to Navigation menu ( ) > VPC network > VPC
networks.
5/20
Each GCP project starts with the default network. In addition, the mynetwork
network has been premade as part of your network diagram.
6. Set the following values, leave all other values at their defaults:
Name managementsubnet-us
Region us-central1
7. Click Done.
6/20
These commands illustrate that networks and subnets can be created using the
Cloud Shell command line. You will create the privatenet network using these
commands with similar parameters.
7/20
9. Click Close.
The output should look like this (do not copy; this is example output):
default and mynetwork are auto mode networks, whereas, managementnet and
privatenet are custom mode networks. Auto mode networks create subnets in each
region automatically, while custom mode networks start with no subnets, giving you full
control over subnet creation
8/20
5. Run the following command, to list the available VPC subnets (sorted by VPC
network):
The output should look like this (do not copy; this is example output):
As expected, the default and mynetwork networks have subnets in each region as they
are auto mode networks. The managementnet and privatenet networks only have the
subnets that you created as they are custom mode networks.
6. In the Console, navigate to Navigation menu ( ) > VPC network > VPC
networks.
7. You see that the same networks and subnets are listed in the Console.
9/20
Create the firewall rules for managementnet
Create firewall rules to allow SSH, ICMP, and RDP ingress traffic to VM instances on the
managementnet network.
1. In the Console, navigate to Navigation menu ( ) > VPC network > Firewall
rules.
3. Set the following values, leave all other values at their defaults:
Name managementnet-allow-icmp-ssh-rdp
Network managementnet
Source IP 0.0.0.0/0
ranges
Protocols Specified protocols and ports, and then check tcp, type: 22, 3389; and
and ports check Other protocols, type: icmp.
Make sure to include the /0 in the Source IP ranges to specify all networks.
These commands illustrate that firewall rules can also be created using the Cloud
Shell command line. You will create the privatenet's firewall rules using these
commands with similar parameters.
5. Click Close.
6. Click Create.
The output should look like this (do not copy; this is example output):
The output should look like this (do not copy; this is example output):
The firewall rules for mynetwork network have been created for you. You can define
multiple protocols and ports in one firewall rule (privatenet and managementnet), or
spread them across multiple rules (default and mynetwork).
3. In the Console, navigate to Navigation menu ( ) > VPC network > Firewall
rules.
4. You see that the same firewall rules are listed in the Console.
Create VM instances
Create two VM instances:
managementnet-us-vm in managementsubnet-us
privatenet-us-vm in privatesubnet-us
11/20
Create the managementnet-us-vm instance
Create the managementnet-us-vm instance using the GCP Console.
The mynet-eu-vm and mynet-us-vm has been created for you, as part of your
network diagram.
3. Set the following values, leave all other values at their defaults:
Name managementnet-us-vm
Region us-central1
Zone us-central1-c
5. Click Networking.
7. Set the following values, leave all other values at their defaults:
Network managementnet
Subnetwork managementsubnet-us
8. Click Done.
This illustrate that VM instances can also be created using the Cloud Shell
command line. You will create the privatenet-us-vm instance using these
commands with similar parameters.
12/20
Test Completed Task
Click Check my progress to verify your performed task. If you have successfully created
VM instance in managementnet network, you will see an assessment score.
The output should look like this (do not copy; this is example output):
The output should look like this (do not copy; this is example output):
13/20
zone and network as another. In the next section, you explore the effect this has
on internal connectivity.
You are able to ping the external IP address of all VM instances, even though they are
either in a different zone or VPC network. This confirms public access to those instances
is only controlled by the ICMP firewall rules that you established earlier.
14/20
Ping the internal IP addresses of the VM instances to determine if you can reach the
instances from within a VPC network.
You are able to ping the internal IP address of mynet-eu-vm because it is on the same
VPC network as the source of the ping (mynet-us-vm), even though both VM instances
are in separate zones, regions and continents!
This should not work either as indicated by a 100% packet loss! You are unable to ping
the internal IP address of managementnet-us-vm and privatenet-us-vm because they
are in separate VPC networks from the source of the ping (mynet-us-vm), even though
they are all in the same zone us-central1.
VPC networks are by default isolated private networking domains. However, no internal
IP address communication is allowed between networks, unless you set up mechanisms
such as VPC peering or VPN.
15/20
Create the VM instance with multiple network interfaces
Create the vm-appliance instance with network interfaces in privatesubnet-us,
managementsubnet-us and mynetwork. The CIDR ranges of these subnets do not
overlap, which is a requirement for creating a VM with multiple network interface
controllers (NICs).
3. Set the following values, leave all other values at their defaults:
Name vm-appliance
Region us-central1
Zone us-central1-c
5. Click Networking.
7. Set the following values, leave all other values at their defaults:
Network privatenet
Subnetwork privatesubnet-us
8. Click Done.
10. Set the following values, leave all other values at their defaults:
Subnetwork managementsubnet-us
13. Set the following values, leave all other values at their defaults:
Network mynetwork
Subnetwork mynetwork
Each network interface has its own internal IP address so that the VM instance can
communicate with those networks.
17/20
8. In the Console, navigate to Navigation menu ( ) > Compute Engine > VM
instances.
10. Run the following, to list the network interfaces within the VM instance:
sudo ifconfig
The output should look like this (do not copy; this is example output):
The sudo ifconfig command lists a Linux VM's network interfaces along with the internal
IP addresses for each interface.
18/20
4. To test connectivity to privatenet-us-vm's internal IP, run the following command,
replacing privatenet-us-vm's internal IP:
This works!
ping -c 3 privatenet-us-vm
You are able to ping privatenet-us-vm by its name because VPC networks have an
internal DNS service that allows you to address instances by their DNS names rather
than their internal IP addresses. When an internal DNS query is made with the instance
hostname, it resolves to the primary interface (nic0) of the instance. Therefore, this only
works for privatenet-us-vm in this case.
This works!
This works!
This does not work! In a multiple interface instance, every interface gets a route for the
subnet that it is in. In addition, the instance gets a single default route that is associated
with the primary interface eth0. Unless manually configured otherwise, any traffic
leaving an instance for any destination other than a directly connected subnet will leave
the instance via the default route on eth0.
9. To list the routes for vm-appliance instance, run the following command:
ip route
The output should look like this (do not copy; this is example output):
19/20
default via 172.16.0.1 dev eth0
10.128.0.0/20 via 10.128.0.1 dev eth2
10.128.0.1 dev eth2 scope link
10.130.0.0/20 via 10.130.0.1 dev eth1
10.130.0.1 dev eth1 scope link
172.16.0.0/24 via 172.16.0.1 dev eth0
172.16.0.1 dev eth0 scope link
The primary interface eth0 gets the default route (default via 172.16.0.1 dev eth0), and
all three interfaces eth0, eth1 and eth2 get routes for their respective subnets. Since, the
subnet of mynet-eu-vm (10.132.0.0/20) is not included in this routing table, the ping to
that instance leaves vm-appliance on eth0 (which is on a different VPC network). You
could change this behavior by configuring policy routing as documented here.
Congratulations!
In this lab, you created several custom mode VPC networks, firewall rules and VM
instances using the Console and the Cloud Shell command line. Then, you tested the
connectivity across VPC networks which worked when pinging external IP addresses but
not when pinging internal IP addresses. Thus, you created a VM instance with three
network interfaces and verified internal connectivity for VM instances that are on the
subnets that are attached to the multiple interface VM.
You also explored the default network along with its subnets, routes, and firewall rules.
You deleted the default network and determined that you cannot create any VM
instances without a VPC network. Thus, you created a new auto mode VPC network with
subnets, routes, firewall rules and two VM instances. Then, you tested the connectivity
for the VM instances and explored the effects of the firewall rules on connectivity.
This self-paced lab is part of the Qwiklabs , Cloud Architecture and Cloud Engineering
Quests. A Quest is a series of related labs that form a learning path. Completing this
Quest earns you the badge above to recognize your achievement. You can make your
badge (or badges) public and link to them in your online resume or social media account.
Enroll in this QuestSee other available Qwiklabs Quests.
20/20