[MUSIC PLAYING]
ERIC YU: Hello.
My name is Eric, and I'm a network specialist here
at Google Cloud.
In this demo, we build a data path between VPCs
by configuring each VPC as an NCC spoke.
We'll use the multi-tier application architecture
to illustrate some key NCC concepts.
A common design practice may use different VPCs
to segment a multi-tier application.
Cloud architects can use this approach
to reduce risk in one layer of the stack
from impacting the others during changes and updates.
And using VPC or projects to segment an application stack
creates a demarcation that helps the right resources to quickly
isolate and to fix any issues.
In the interest of time, we've pre-built
some of the network components that we
will be using in the demo.
By the end of this, we would have configured a fully meshed
data path between all VPCs.
The console shows pre-configured VPCs
that NCC will interconnect.
We'll create a global route table
to store all VPC subnet routes by creating an NCC hub.
And in this demo, I'm naming this new hub as NCC-HUB.
On the same configuration page, this
allows me to configure a VPC as a spoke,
and this is helpful to me as I will
be configuring VPC1 and VPC4 as NCC spokes to the NCC hub.
When this step is completed, we should see our NCC hub
routing table be populated with VPC1 and VPC4 subnets.
NCC hub supports all valid IPv4 ranges
except for privately used public IP addresses.
So far, both our VPC spokes and our NCC hub
belongs to the same project.
Network Connectivity Center can support other VPCs
as spokes from a different project.
This allows other project owners to participate in
the same routing domain, all while maintaining
their own administrative autonomy.
To demonstrate this, we'll switch to a new GCP project.
On the NCC Configuration page, we configure this project
with the name of our hub, and we specify the project ID
where that hub resides.
And we will name this spoke Cross Project Spoke,
and we'll configure VPC1 from this new project
as an NCC spoke.
Upon creating a new spoke, the NCC hub admin
will have the opportunity to review the cross-project spokes
request to join our hub.
The new spoke will only become active once our NCC hub
admin approves the request.
Here, we've switched back to the project that's hosting our hub.
We can see the new VPC request wants to join the hub.
We drill down into the hub to find the new spoke,
and we can either accept or reject the requests.
If we choose to reject the request,
we can provide a brief explanation for the rejection,
but instead, we'll accept and confirm
the activation of the new cross-project spoke.
Once the new cross-project spoke becomes active,
we should see the subnets from cross-project VPC1
in the hub's routing table.
In this next part of the demo, we'll
see how NCC checks for overlapping IP
ranges from different subnets.
VPC1 and VPC3 have both been pre-configured with
an overlapping IP range of 10.3.3.0/24.
We'll watch what happens when we configure both VPC2 and VPC3
as new spokes to join our hub.
Network Connectivity Center checks for overlapping subnets
from all spokes.
If it detects an overlap, it will
fail new VPC spoke creation with an error.
The error message tells us subnet 10.3.3.0 and VPC3
overlaps with VPC2.
To resolve this error, we'll need
to exclude the overlapping 10.3.3.0
IP range from both VPC2 and VPC3 from being exported
into the NCC hub routing table.
We navigate to the Spoke Configuration page
like we did before, only this time we enter the overlapping
IP range that will be excluded from being exported
into the hub's routing table.
This time, the hub should accept VPC2 and VPC3 as spokes,
and we can see the spokes status as active.
And if we drill into the NCC hub's routing table,
we should only see VPC2 and VPC3 subnets that were not excluded.
Let's visualize what we've configured so far.
We have five VPCs configured as NCC spokes
that is attached to our NCC hub.
Our VPCs are pre-configured with firewall rules that allows
traffic between all subnets.
In this part of our demo, we'll use Cloud Shell to set up
private NAT between VPCs.
Here, I've already logged into Cloud Shell.
In VPC2, we create an IP subnet dedicated for NAT.
Next, we create the Cloud router in VPC in the same region
as our virtual machine.
We'll configure the Cloud router to translate VPC2's overlapping
10.3.3.0/24 subnet.
Finally, we'll create a NAT rule that
will source NAT, the overlapping IP range, if the traffic takes
an NCC hub route.
Logging out of cloudshell and switching to our web interface,
we should see our private NAT configuration
represented on the console.
Note that dynamic port allocation
is enabled by default.
Let's test NCC's datapath.
The web server in VPC1 is configured with tcpdump
to listen for traffic sourced from VPC4's subnet,
10.4.4.0/24.
We'll use ping to verify the data path by initiating
an echo request from vm4 in VPC4 to the web server on VPC1,
and if we use a curl command on VM4
to validate web connectivity to the web server,
we should expect to see bidirectional traffic
between the two hosts.
Next, let's test our private NAT config.
We'll log onto pnat-vm that resides on VPC2's overlapping
subnet.
On our web server, we'll configure tcpdump to listen
for traffic source from the NAT pool range of 10.10.10.0/29.
Note the host IP on pnat-vm.
This IP address belongs to the range
that has been excluded from the NCC hub route table.
When we establish a web request from the pnat-vm host,
we should see the web requests come through on the web server
using a translated IP address.
Network connectivity support for VPC
as a spoke and private VPC NAT is now
publicly available for testing.
Different chairs of the application stack
that was once segmented by VPC and projects
can now use NCC hub to orchestrate
full network connectivity.
If you have any questions, reach out
to your friendly neighbor Google Cloud customer engineer.
Thanks for watching.
[MUSIC PLAYING]