Define New Paths with Routing
Why routes are at the foundation of network success and how to set them up on Google Cloud
Your network is strategic
Since the beginning of this series, I’ve made it clear that data and applications are inseparable from the networks they run on. The reliability of your digital infrastructure depends directly on this network. And frankly, this is why you should be investing in architecting it using the right building blocks.
The problem is that it doesn’t work to try to adapt existing networking technologies to the cloud — whether you’re connecting resources from separate data centers or between branch offices. No matter how well-designed or sophisticated your on-premise networking footprint is, virtualizing that hardware to the cloud retains too much complexity. It carries over configuration, management, and troubleshooting that often overlooks the very benefits cloud networking brings you. Your DevOps teams will be at the mercy of handling this cloud connectivity, having to retrofit the networking hardware to try to maintain original connectivity and performance expectations.
A new way of routing
Cloud routing is not only mandatory, but it’s a foundational part of building a strong network architecture from the ground up. Think of it like the Postal Service, UPS or Fedex. Packets come in from across the world and land in local sorting centers (routers), possibly landing at other centers before their destination. They’re rerouted for weather, truck failures, and natural disasters. It’s an amazing feat of logistics.
Now imagine that instead of 10 post offices, you had thousands— all while carrying thousands of times more packets.
Routing protocols are a way for your systems to let networks know who they’re talking to and how to efficiently send information there. As network condition change or equipment fails, routing protocols can change the routes they advertise to other networks to compensate.
On top of 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 & B shared a common wall in a building and each had their own private networks, but then wished 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 amount of heavy lifting. This includes physically assembling devices, such as routers, switches, bridges, hubs, and firewalls, to build interconnectivity between users and the applications they use. Implementation can 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.
Software defined networking, however, aims to remove the need for hardware management, and provides scalability and security benefits with simpler configuration. Google Cloud’s software-defined routing is designed around a VPC network that uses a scalable, distributed virtual routing mechanism. 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.
Cloud routing under the hood
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 is kept informed of all its routes from the network’s routing table. You may remember that routes are usually applied selectively per VM, but GCP’s routing table is actually defined at the global VPC network level. 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.
Types of routes
Now there are two types of routes on GCP VPC: system-generated routes or custom routes.
System-generated routes give you subnet routes and default routes.
The subnet routes (red) define a path for traffic into your VPC to each subnet. These apply to a VPC network and are programmed to all the endpoints in a VPC network. When a subnet is added to a VPC, subnet routes are automatically created to allow VMs to talk to other VMs in the same VPC. Just know that these routes can’t be deleted or changed. Subnet routes are how VPC Peering works (VPC peers always exchange all subnet routes).
The default route (blue) defines a path for traffic from your VPC to Google services and the public Internet. It includes a pre-programmed 0.0.0.0/0 route to an Internet Gateway. Unlike subnet routes, these routes can be changed.
Custom routes, on the other hand, involve defining your own static routes, or dynamic routes using Google Cloud Router.
Static route set up
Let’s walk through creating a custom static route using a VPN example:
- Set your project ID.
gcloud config set project [PROJECT_ID]2. Create 2 VPCs in different regions.
gcloud compute networks create ohio --subnet-mode=customgcloud compute networks create texas --subnet-mode=customgcloud compute networks subnets create subnet1 --network=ohio — region us-east1 --range=10.0.0.0/24gcloud compute networks subnets create subnet2 --network=texas — region us-central1 --range=10.8.0.0/24
3. Create a Compute Engine instance in each VPC.
gcloud compute instances create ohio-server --subnet subnet1 --zone us-east1-bgcloud compute instances create texas-server --subnet subnet2 --zone us-central1-a
4. Create firewall rules to enable access to the instances and between the networks.
gcloud compute firewall-rules create allow-ssh-ohio --network ohio --allow tcp:22 --source-ranges 0.0.0.0/0gcloud compute firewall-rules create allow-ohio-texas --network ohio --allow tcp:3306,icmp --source-ranges 10.8.0.0/24gcloud compute firewall-rules create allow-texas-ohio --network texas --allow tcp:3306,icmp --source-ranges 10.0.0.0/24
5. Create 2 VPN gateways in each region with the following configurations:
gcloud compute target-vpn-gateways create evpn \
--network ohio \
--region us-east1gcloud compute target-vpn-gateways create cvpn \
--network texas \
--region us-central1
6. Reserve a regional external (static) IP address for each VPN gateway:
gcloud compute addresses create east-ip \
--region us-east1gcloud compute addresses create central-ip \
--region us-central1
7. Create three forwarding rules for the central gateway. These rules instruct Google Cloud to send ESP (IPsec), UDP 500, and UDP 4500 traffic to the gateway.
gcloud compute forwarding-rules create fr-cvpn-esp \
--ip-protocol ESP \
--address central-ip \
--target-vpn-gateway cvpn \
--region us-central1gcloud compute forwarding-rules create fr-cvpn-udp500 \
--ip-protocol UDP \
--ports 500 \
--address central-ip \
--target-vpn-gateway cvpn \
--region us-central1gcloud compute forwarding-rules create fr-cvpn-udp4500 \
--ip-protocol UDP \
--ports 4500 \
--address central-ip \
--target-vpn-gateway cvpn \
--region us-central1
8. Create 3 forwarding rules for the east gateway.
gcloud compute forwarding-rules create fr-evpn-esp \
--ip-protocol ESP \
--address east-ip \
--target-vpn-gateway evpn \
--region us-east1gcloud compute forwarding-rules create fr-evpn-udp500 \
--ip-protocol UDP \
--ports 500 \
--address east-ip \
--target-vpn-gateway evpn \
--region us-east1gcloud compute forwarding-rules create fr-evpn-udp4500 \
--ip-protocol UDP \
--ports 4500 \
--address east-ip \
--target-vpn-gateway evpn \
--region us-east1
9. Next generate a shared secret, which you’ll need in order to create the VPN tunnels. Take note of it.
10. Create a static-route based VPN tunnel from the east gateway to the central gateway. First copy the central-ip address of the cvpn from the VPN Gateways page. For Route based VPN, both the local and remote traffic selectors are 0.0.0.0/0.
gcloud compute vpn-tunnels create tunnele2c \
--peer-address [CVPN_IP] \
--ike-version 1 \
--shared-secret [SHARED_SECRET] \
--local-traffic-selector=0.0.0.0/0 \
--remote-traffic-selector=0.0.0.0/0 \
--target-vpn-gateway evpn \
--region us-east111. Create a static-route based VPN tunnel from the central gateway to the east gateway. First copy the east-ip address of the evpn from the VPN Gateways page.
gcloud compute vpn-tunnels create tunnelc2e \
--peer-address [EVPN-IP] \
--ike-version 1 \
--shared-secret [SHARED_SECRET] \
--local-traffic-selector=0.0.0.0/0 \
--remote-traffic-selector=0.0.0.0/0 \
--target-vpn-gateway cvpn \
--region us-central1On the VPN tunnels page, you should first see a status of allocating resources and attempt to establish first handshake under the VPN tunnel status column. Then, a green check mark will appear after establishing the VPN connection between the gateways.
12. Try pinging the texas-server from the ohio-server. Grab the internal IP of the texas-server from the Compute Engine instances page. Then SSH into the ohio-server from the Compute Engine instances page and enter the following command.
ping [TEXAS_INTERNAL_IP]It’ll hang as there is no route specified from the ohio-server to the texas-server over the VPN tunnel.
13. Next create a static route for traffic from the east VPC to the central VPC. The destination-range is the internal IP range of the central subnet. The next hop is the east to central VPN tunnel.
gcloud compute routes create tunnele2c \
--destination-range 10.8.0.0/24 \
--next-hop-vpn-tunnel tunnele2c \
--network ohio \
--next-hop-vpn-tunnel-region us-east114. Now do the same to create a route from the central to the east VPC.
gcloud compute routes create tunnelc2e \
--destination-range 10.0.0.0/24 \
--next-hop-vpn-tunnel tunnelc2e \
--network texas \
--next-hop-vpn-tunnel-region us-central1Check the Routes page and you should see the new static routes created.
15. Let’s try pinging the texas-server from the ohio-server once more.
You should see a response as the routes have allowed traffic to be sent over the VPN tunnel as next hop!
Using Connectivity Test in the Network Intelligence Center, I created an ICMP test for traffic from the ohio-server to the texas-server and it confirms traffic travels through our VPN and static route set up:
Pros and cons
Keep in mind that with static routes, you have to create or maintain a routing table. A topology change on either source or destination network requires you to manually update static routes. In other words, static routes can’t automatically reroute traffic if a link fails (as opposed to dynamic routing, which can automatically reroute — more on this in my next post). Yet static routing is perfect for small networks with stable topologies, and you can also maintain strict control over the routing tables, as shown in the VPN example above.
All in all, Google’s software-defined routing gives you:
- Simplicity with centralized control
- A high degree of automation
- Built-in security and encryption
- And high performance
Software defined routing is what connects subnet to subnet and directs traffic between VPCs, and even to your local on-premise network. Through the routing interface, you’ll begin to see how it has transformed how easily you can start to build a highly scalable network.
Now what?
- Deep dive on routing here.
- Subscribe to the GCP Youtube channel and follow my video series Networking End-to-End.
- Check out Networking 102 where I discuss routing with Networking Specialist, Ryan Pryzbl.
- Want more content? Follow me on Twitter @swongful.
- And check out the Google’s Cloud events near you.
Stay tuned for more on this series and thanks for joining me on this wild ride to demystify cloud networking.
