Google Professional Data Engineer – VPCs and Interconnecting Networks part 6

12. Cloud Router

In order to avoid static routes, where you have to update the routing tables on your VPN in order to learn new networks, you will often use VPNs with cloud routers. The cloud router can be used to dynamically exchange route information between VPCs that you have on the Google Cloud platform and your on premise network. In addition to VPCs, Google also has a legacy network setup, which we’ll see briefly at the end of this section. Cloud routers work with both legacy networks as well as VPCs cloud router. Once again, as with all things, cloud is not a physical device that can cause a bottleneck. It’s a fully distributed and managed Google Cloud service and will scale with the amount of traffic that you send over the network.

You configure a cloud router to work with the VPN gateway that you have configured for your Vpc, and this cloud router will exchange topology information which automatically propagates routes between your Vpc network and your on premise network. You don’t need to configure static routes if you remember your networking classes from back in the day. Route information is typically exchanged using BGP or the Border Gateway Protocol, and that’s what Cloud Router uses. The BGP is a standardized gateway protocol designed to exchange routing and reachability information. It makes routing decisions based on paths, network policies, or rule sets configured by your network administrator.

Now, if you do not configure a cloud router to work with your VPN, what you need to use are static routes. Static routes require that you create and maintain a routing table manually. Now, topology changes are not uncommon in networks. You might add a new subnet because you’ve added a new rack to your on premise network, or you’ve added a bunch of new virtual machines to connect to your network on your Google’s Vpc. In every case, you have to manually update your routing table. Routes are not automatically updated in response to new additions to your network, which means these new additions will not receive traffic till the routing table has been manually updated.

Similarly, if your machine goes down or a subnet fails, the traffic will not be rerouted unless some manual intervention is carried out. Static routes are typically not preferred when you have a large network that is dynamically changing. If you want a handsfree approach to managing your network topology, you will use dynamic routes instead. Static routes are typically used for small, very simple networks which have stable topologies routers that are used when we use. Static routes do not advertise routes to each other. They simply perform their own routing operation. Let’s first understand how static routes work for a VPN tunnel and then move on and see how dynamic routes are an improvement.

Here, once again, is your on premise peer network connected with Google’s Vpc via a VPN tunnel? The VPN tunnel is a secure tunnel over the Internet. This VPN tunnel connects a gateway at either end. Now, let’s say the network topology changes in a certain way. You’ve added a new subnet to the on premise network because you’ve added a new rack of machines to your data center. Now, it’s possible that your business is growing so rapidly that this is a very common operation, not something which happens just once a year or something. In order for traffic to be routed to this new subnet and the machines which are on it, we require that new routes be added to the cloud Vpc in order to reach this new subnet.

In addition to manually updating your routing table, using static routes requires that you tear down your VPN connection and reestablish it so that the new routes are picked up by your VPN tunnel. There are two steps that you need to do in addition to adding the subnet. Updating the routing table and tearing down and reestablishing a connection seems like a major pain. This is the reason why static routes are slower to converge. Updates are manual. Every step is manual, which is why new machines take a while to be recognized and take a while to start receiving traffic. Having manual intervention to update your network topology is not ideal for a fast moving business, which is why you have dynamic routes. Dynamic routes can be implemented using cloud router.

On the Google Cloud platform, cloud router peers with your VPN gateway on the cloud and uses border gateway protocol to exchange topology information. In effect, any network topology change either on your on premise network or on your Vpc on the cloud, is automatically propagated to the other end. The network as a whole has the ability to automatically and rapidly discover changes. This constant exchange of information using the border gateway protocol means any subnet that you add will immediately start receiving traffic. Another important point is that this change occurs without disrupting traffic. You do not need to tear down the VPN connection and reestablish a new tunnel in order for your new machines new subnets to be identified and routed traffic.

Let’s look at the same VPN interconnection example as before, but this time notice that on the Google Cloud Platform end, we have a cloud router that peers with our Google VPN gateway. Some things to note about a cloud router a cloud router belongs to a particular network and it is regional. It belongs to a particular region. So if you have a VPC that spans multiple regions and you’ve configured different VPN gateways in different regions, you need to configure a cloud router in each region. So if you have VPN gateways in different regions, you need a cloud router per region. But a single cloud router can be used for multiple VPN gateways and multiple tunnels provided there in the same region where the router belongs. Let’s take a look at what this network has.

On the Google Cloud Platform end, we have subnets which segment the network IP space. These subnets are basically instances which belong to your testing environment production environment, and you’ve just added a subnet for your staging environment. At the other end, we have our on premise network. Notice that an additional subnet has been added here as well. We’ve added a new rack to our data center. The staging subnet that we’ve added on our Vpc will be advertised using the Border gateway protocol. The cloud router is aware of this change and it will basically announce this network topology change to our peer gateway on the on premise network. Similarly, using the border gateway protocol, it will also learn of topology changes on the on premise network.

That is, the fact that a new subnet has been added. A new rack has been added. In order to enable border gateway protocol on this VPN tunnel to allow for routing information exchange, we require that the IP address of the cloud router and the gateway router should both be linked local IP addresses.

These are additional IP addresses that have to be configured on each end of the VPN tunnel in a computer network. A linked local IP address is a network address that is valid only for communications within that network segment. Linked local IP addresses are not guaranteed to be unique beyond that network segment. Cloud routers have two modes of operation.

This is called the dynamic routing mode, and this is what determines what subnets are visible to the cloud router. Only those subnets that are visible to the cloud router can be advertised to the remote peer network. If the cloud router operates in global dynamic routing mode, it advertises all subnets in the Vpc network to the on premise router. In the global mode, the cloud router has visibility into all subnets within the Vpc, whether they are in a particular region where the cloud router is configured or in a different region in another part of the world. The cloud router can also operate in the regional dynamic routing mode.

In this case, it advertises and propagates only those routes in the local region it does not see, and it cannot advertise those route changes that occur in a different region from where the cloud router is configured. Let’s take this example of a VPN tunnel connecting a VPC on the Google Cloud with an on premise network on the Google Cloud platform. Notice that the Vpc spans multiple regions. We have instances in US West One and US Central One. There are two subnets in this Vpc, one in each region. If you remember, we’d mentioned earlier that a cloud router belongs to a single network and is associated with a particular region. The cloud router here is configured in the US West region. It’s peered with the cloud VPN that is present in the same region, and it has been configured in the global dynamic routing mode.

Because of that, the subnets which are available in both of these regions are visible to this cloud router. As both of these subnets are visible to the cloud router. Routes in both of these regions are advertised to the connected network. Our on premise network will get updates if the topology changes in either of these regions. Now, with the same network configuration setup, let’s say you configured your cloud router to work with regional dynamic routing. This is the mode that it operates in. In that case, the subnetwork that is in a different region that is in US central one is not visible to your cloud router. Any route changes or network topology changes in the subnet that is in US central one will not be advertised to the network which is onpremise.

13. Lab: Using Cloud Routers for Dynamic Routing

In this lab we will create two virtual networks. We will create a cloud router on each of these networks and then establish a VPN connection between the two. And we will see how instances provisioned on each of the networks can communicate with each other using their internal IP addresses and then we will go on to add a new subnet in one of these networks and see how an instance provisioned on that subnet can continue to communicate with the other instances using the internal IP, even without any explicit changes to our configuration. Let us start though by creating our virtual Networks. So we navigate to the Vpc networks page and then we create our first virtual network which we shall call VPN network One. Let us have one subnet in this one called Subnet A and this will be in the Asia East region we list our cyber block and then hit Create.

We then move on to creating our second Vpc network let us call this VPN Network Two. The subnet here will be called Subnet B and it’s going to be in the Asia South region and with our Cider block specified we hit Create and we now have our two virtual networks. Let us now provision our instances so we will have one in each of these Vpc networks. So we navigate to the VM instances page and we choose to create our instance the first one let us call Server One. This will be in the Asia East region and for the machine type let us have a micro instance we then navigate to Networking and select our VPN network One as the location for this instance we hit Create and now let us provision our second instance so this one calls Server Two.

This will be in the Asia South region. Once again we select a micro instance type and we would like this in our second VPN network so navigate to Networking, we select our network and we hit Create. All right, so we now have our instances ready next, let us create Firewall rules so that we can reach these instances via Ssh and so that we can also ping them. So for that we navigate to Vpc networks and Firewall rules and for our first rule call it Allow icmp Ssh for Network One. This will apply to our first Vpc network we want the rule to apply to all instances within the network and we want the connections to be able to come in from anywhere so we specify that cyber block. So let us select the Icmp protocol for pings and let’s open up port 22 for Ssh and then we just hit Create.

Okay, so that’s one Firewall rule ready. Let us create the second one. This one we will call Allow Icmp Ssh network Two and this will be attached to our second Vpc network. Once again, this is an ingress rule which we wish to apply to all instances in the network and we want connections to be able to come in from anywhere. And once again we specify the Icmp protocol and open up port 22 for Ssh. Okay, we hit Create and we now have our firewall rules in place as well. So let us just test the connectivity between our instances and see if everything is working as expected. Navigate to the VM instances page and we then Ssh into our first instance. And once the terminal is up, try to ping the second instance from here. So we go and grab the external IP for server two.

And now when we try to ping, we see that server two is reachable from over here from the external IP. Now try to use the internal IP for a second instance. So once we have that ready, we try to ping. And we can see that pinging doesn’t work with the internal IP address, which makes sense because they’re on different Vpc networks. But let us just test the inverse connection. So we Ssh into server two, and once we’re in, we grab the external IP address for server one. And when we bring with that the connection works. And then when we use the internal IP address and as expected, this thing fails. However, we would like these instances to communicate with each other using their internal IP address. So as a first step, let us go ahead and create our cloud routers.

So for this we navigate in the menu to interconnect cloud router and then we choose to create a new router. Call this network one cloud router. We attach this to our first Vpc network. So VPN Network One. This will be in the Asia East region and for the Google AFN or Autonomous system number. This is a unique number to identify the router and is used by the Border Gateway protocol or Bgp. We will soon see how this works, but the value to enter here we can choose from among a range of private numbers which are available for use in Gcp. So let us just select one of these numbers. Let us just put in 65470. So with this cloud router created, let us go ahead and provision our second one. So this one we will call Network Two cloud router.

This will be attached to our second virtual network. This will be in the Asia South region. And once again we specify an Asn. All right, so we now have our two cloud routers. Let us now do further preparatory work to configure our VPN gateways by reserving some static IP addresses. So we navigate to Vpc networks, external IP addresses and reserve a static address. We would like to use an iPV four address, it’ll be in the Asia East region. And we hit reserve and we create another static IP address by essentially repeating the steps. Except this time it’s going to be in the Asia South region. Okay, so we now have two static IP addresses as well. So we are ready now to go ahead and create our VPN connections.

So we navigate in the menu to interconnect VPN and create VPN connection. Call this VPN One and we will attach this to our first virtual network. This will be in the Asia East region and for the IP address let us use our first static IP address which we created. And once we have that, let us move to the tunnel section. And for the remote peer address let us just use the second static IP which we have provisioned and we will soon see how this is used in the second VPN. Let us enter a shared secret. So we choose to have dynamic routing using Bgp and we select our first cloud router and let us configure the Bgp session. So we want to get routing information from our second network to the first. So we call this bgp two to one.

For pure esn we use the Asn for the second cloud router. For our final two fields we need to specify what are known as Linked Local IP addresses and they need to fall under a certain range. So let us specify two addresses which we know are valid and when we create a second VPN connection and defining its Bgp session, we will essentially be reversing these values with all the information entered, let us hit save and then let us create our VPN connection. And now that we have the first one in place, create our second VPN connection. So this is essentially going to be an inverse of the first one we created. Call this VPN Two and then this is going to be in the Asia South region.

We use the second static IP address and again for the tunnels we use the first static IP address. For the remote peer we need to use the same shared secret as we did in the first VPN connection. Again it’s dynamic routing with Bgp. This time we use the second cloud router and as for the Bgp session, again this is just going to be an inverse of what we did previously. So we enter the Asn number for our second cloud router and for the last two fields we just reverse what we did previously for the first VPN connection and with all the fields populated, let us hit save and then we create a second VPN connection. And now we are ready with both of the VPN connections which we require.

Let us now go back to our instances and test the connectivity between them using the internal IP address. So we navigate to VM instances and we Ssh into our second instance and once we’re in, let us try to ping the first instance using its internal IP address. Once we get that, we can see that this time the ping is successful. To shed some light on how this has happened, let us navigate to the routes page which is under Vpc networks and when we scroll to the bottom, we see that two new routes have popped up, one on each of our networks. So this is how our instances on different networks are able to talk to each other using the internal IPS.

Now for a true test of dynamic routing, let us go to our second virtual Network and add a new subnet. So in the Vpc networks page we edit our second network. We add subnet. Let us call this subnet C and this will be in the Asia South region. We specify a cyder block and we hit add. So now we have modified our network to include a new subnet and finally, let us go and create a new instance in this subnet so navigating to VM instances we go and create a new instance let us call the Server Three. So again we fill in the details and importantly here let us go into networking. We select our second Virtual Network and choose to create this in subnet fee we hit Done and Create.

Now that our third instance is up, let us see if this which is on VPN network Two can be reached using its internal IP from our first instance which is on VPN network One. So we Ssh into server one and when we’re in, let us try to ping server Three using its internal IP address. So we grab that IP and we see that this time the ping is successful. And to understand how exactly this communication was possible, let us navigate to routes page. And over here when we scroll further down, we see that a new route has popped up out from our first Virtual network to the new subnet which we just created on the second network. So with that, we conclude our lab on dynamic VPN with cloud routers.