STEPHANIE WONG: Your cloud application
has a lot of data moving over many parts of the public
and the private internet.
But what if you want a heavier hand
in defining exactly what paths your data can take?
In this episode of Cloud Networking,
we'll talk about how to define traffic
routing between networks.
Stay tuned.
[MUSIC PLAYING]
One common problem with networking
is that you need the ability to link networks together
without allowing the data to be visible to every user
in every location.
For example, let's say company A and B share
a common wall in a building and each
have their own private networks, but then wish
to connect them together without giving up their current network
configuration.
This would mean making both networks use different IP
address ranges and set up a router that
connects to both of these networks
to pass traffic between them.
Traditionally, setting up a router
for an on-premise network requires
a fair bit of heavy lifting.
You physically assemble these things together
to build interconnectivity between users
and the applications they used.
Implementing all of this could take days or even weeks.
And as the network grows, the associated management
and cost to operate it also grows disproportionately
larger for your company.
But with Google Cloud Platform, software-defined routing
means every VPC network uses a scalable Distributed Virtual
Routing mechanism.
GCP routes define the paths network traffic takes from a VM
instance to other destinations.
These destinations can be inside your VPC network--
for example, in another VM--
or outside of it.
Even though some routes can be applied selectively,
the routing table for a VPC network
is defined at the global VPC network level.
Let's take a closer look.
Every route consists of a destination
and a next hop, which are IP addresses or ranges of IP
addresses.
Traffic whose destination IP is within the destination range
is sent to the next hop for delivery.
Each VM instance has a controller
that's kept informed of all its routes
from the network's routing table.
Each packet leaving a VM is sent to the 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
using an eventually consistent design.
This means that you have simplicity
and centralized control, a high degree of automation,
built-in security and encryption,
and high [? performance. ?]
Now, there are two types of routes on a GCP VPC--
system-generated routes or custom routes.
System-generated routes give you a default route and subnet
route.
The default route defines a path for traffic from your VPC
to Google services and the public internet.
The subnet route defines a path for your traffic
into your VPC to each subnet.
This is how VPC peering works.
VPC peers always exchange all subnet routes.
Custom routes mean you create static routing yourself
or dynamic routes using Google Cloud Router.
Let's walk through a static route setup.
Here, I have two VPCs set up in US east and US central.
I also set up a VPN gateway on both sides
and created two IPSec tunnels between them.
I have an Ohio server in the US East VPC
and a warehouse server in the US central VPC.
But I still can't ping the internal IP of the warehouse
server from the Ohio server.
I need to create two static routes
to enable traffic to be forwarded into the tunnel.
We have default routes created for each network,
but we're going to create custom static routes.
First, let's create a route from east to central.
Click CREATE ROUTE.
Specify a name for the route.
Select an existing network where the route will apply.
The Destination IP range is a central subnet internal IP
range.
I'll skip Priority for now, but you
would use this to determine routing order
if routes have the same destinations.
Select a target instance tag, or leave
it blank to apply the route to all instances in the network.
Select a Next hop for the route.
I'll select my VPN tunnel.
And click Create.
Now, I'll create another route for traffic
from central to east.
And voila, I can now ping the internal IP of the warehouse
server from the Ohio server.
Keep in mind that with static routes,
you have to create or maintain a routing table.
And a topology change on either network
requires you to manually update static routes.
Also, static routes can't automatically reroute traffic
if a link fails.
But static routing is perfect for small networks
with stable topologies.
There's so much more I can say around routing,
but it's clear that Google's virtual routing
is what connects all the moving pieces between subnets
and a VPC, and even to your local network on-premise.
Stay tuned for more networking end-to-end.
And remember, optimizing your network
means freeing up your bandwidth.
[MUSIC PLAYING]