Google Professional Data Engineer – VPCs and Interconnecting Networks part 8

17. VPC Network Peering

Another way to connect networks across Google cloud platform is by using Vpc network peering. This can be used to connect networks which are in different projects as well as in different organizations. Vpc Network Peering differs very significantly in a structural way from shared Vpc. The main logical differences are the networks that are peered are administered illustratively separate, they have their own firewall rules and policies and can be administered separately. And the second point of difference is that you can peer networks from different organizations as well. Shared VPCs only apply to networks which are within projects of the same organization.

Vpc Network Peering gives us stuff very similar to shared Vpc. The first and foremost is that it allows private RFC 109 One Eight connectivity across two or more Vpc networks. The instances on these networks can connect to other instances on Peered networks using their internal or private IP addresses. Networks which are peered together using Vpc Network Peering can belong to the same project or can be in different projects administered by different admins. Vpc Network Peering is typically used to build software as a service or SaaS ecosystems on the Google Cloud platform.

This is because services are made privately available across different Vpc networks within a particular organization and also across organizations. So if you have a product architecture setup which involves these different services calling each other, they can communicate with each other in private RFC 1918 space. You can also call external third party services hosted on VPCs in a different organization. Vpc Network Peering is very useful for organizations which have several network administrative domains. That means you have separate network administrators for one project versus another project, but you want those networks to be able to communicate with each other.

In that case, you will choose Network Peering. The Peering that we covered earlier in this course, the Direct and Carrier Peering involved an on premise network or a network from another cloud provider with the Vpc Network Peering is for two Google VPCs. So if you want to peer with other organizations which use the Google Cloud Platform, network Peering is what you would use. There are several reasons to choose. Vpc network peering. As opposed to calling an external IP address across two networks, you’ll have lower latency as compared with public IP networking because you don’t need to look up the external IP address on a DNS, you don’t need to route it via the Internet.

Vpc Network Peering is also better from a security point of view because we have these different services which are on the same network. Thanks to Peering, they communicate via internal IP addresses, which means these services do not need to expose an external IP address in order to receive requests from other services in other networks. External IP addresses are always a security risk. The way Google cloud platform performs its billing, you’ll find that Vpc network peering is also more cost effective in terms of traffic. Gcp charges aggress bandwidth pricing for networks which use external IPS to communicate even if the traffic is within the same zone.

So if you have two networks within the same zone and they use external IPS to communicate, gcp will charge you aggress bandwidth pricing. But if you use internal IP addresses to communicate, you do not have aggress bandwidth pricing you will just have regular network pricing. We’ll now look at some key characteristics of Vpc network peering peer networks are administratively separate routes firewalls, VPNs and traffic management are applied independently which means you can have separate network administrators manage each network independently they are peered together, but they appear as one network for instances on either network because they communicate with other instances using internal IP addresses.

One Vpc network can peer with multiple other Vpc networks with a limit of 25. Now, each side of a peering association is set up independently so one network can say that it’s ready to peer. It’s only when the other network is ready to peer as well that the connection is established. So Peering can be configured for one Vpc network even before the other Vpc network is created. Only directly peer networks can communicate with each other, so one network can peer with multiple networks.But Peering is not transitive, so if A peers with B and B peers with C, a cannot communicate with C via internal IPS, b can communicate with both A and C. We’ll see this in a diagram in just a little bit.

We haven’t covered load balancers yet, but let’s look at how peered networks work with internal load balancing. Internal load balancing is within a particular region here in this block diagram, we have network B that is Peered with two other networks network C on top and network A on the right side, VMs on network C and network B because they are directly peered together, can communicate with each other using internal IP addresses there is no load balancer in either network C or network B so there’s nothing we need to discuss there the interesting case is the peering between Network B and network A.

Network A has an internal load balancer which balances traffic or distributes traffic amongst all the VMs that is connected to this load balancer. This load balancer in network A will automatically apply to the VM instances in network B. It will basically treat the VM instances in network B as though it belongs to network A. There is no additional configuration required the internal load balancer automatically behaves this way peering is direct, not transitive. Network C is not directly peered with network A that is why the instances in network C cannot directly talk to network A.

Load balancer traffic cannot access the VM in network C because it’s not peered directly let’s now look at another block diagram which shows us how peered networks and firewalls work together here we have two projects p One and P two and there are two different networks network A and Network B. In each of these projects, each network has two subnets. These two networks are peered together, which means their VM instances can talk using internal IP addresses. But firewall rules are configured separately in each network. The network administrator of Network P in Project P Two can basically decide that subnet Three cannot receive traffic from subnet One and subnet Two.

It can only receive traffic from subnet Four, so he can set up an ingress firewall to prevent traffic from subnet One and two from reaching subnet three. Firewall rules become extremely important in the case of peering because all instances in the two peer networks can automatically access each other. Peering basically means that all instances have direct access via internal IP addresses. If you want more explicit rules where you want certain instances to be blocked from other instances, you need to configure firewall rules for peer networks. Now, if you so desire, you can also have a VPC peer with a shared Vpc.

This is completely legit, and the shared Vpc behaves like any other network on the Google Cloud platform. Highlighted on screen is a shared Vpc with one host project and two service projects. The network is called Network svpc. This shared Vpc has a direct peering connection with a simple Vpc that is present in Project P Two, that is Network A. Now, this peering connection behaves just like any other Vpc to Vpc peering that we’ve seen. All VMs, whether they are in the regular Vpc or in the shared Vpc, can communicate with each other via internal IP addresses.

The fact that it’s a shared Vpc doesn’t matter. You can also have direct tiering between two shared VPCs. Let’s now see how tiered networks behave when you have a VM which has multiple network interface cards. Here you see on network A we have VM One, which has multiple network interface cards, one of which is assigned IP Two and one of which is assigned IP One. IP Two, belongs to Network B. The other network interface, IP One, belongs to Network A, so VM One is in both Network B as well as Network A, thanks to its multiple network interface cards. Now we have another Network C which has appeared directly with Network B.

Now all VMs on network c can only see IP. They can access VM One, but they can only see the IP address called IP Two, which is present in Network B. Network A, which is standalone, is not peered. The virtual machine named VM Two, which is present in network C, can communicate directly with VM One using its IP address, which is present in network B, that is IP Two. So IP Three and IP Two can see and communicate with each other. However, IP One present in Network A cannot see any instances in either network B or in Network.

18. Lab: VPC Peering

In this demo, we shall simulate a situation where an organization’s division in Europe wishes to peer one of its virtual networks with the global headquarters. We are on the Vpc Networks page for Lunicon Europe and the network which we wish to share with the global entity is this Common Resources Europe network. So we would like the global entity to initiate the Vpc Peering connection. So we sent them a couple of pieces of information. One is our own project ID in Ulonicon Europe which we get from the project homepage the other being the name of the network to peer which we saw was Common Resources Europe.

So with that information in hand, let us move over to the Global Entities project page and we see that the network which the global entity will peer is called Common Resources Vpc in order to set up network Peering. Let us go to the Vpc Network Peering page and over here we see that a peering connection has already been set up with Lunicon’s Asia division. We will see later on how this will play a role in setting up the peering connection with Europe. So let us initiate the connection to Lunicon Europe. This just tells us that we need the project ID and the name of the Remote Virtual Network which we had noted already. We give a peering connection a name and choose the local network which we wish to share.

And as for the Peered Vpc network, it is in a different project in Unicorn Europe. So we enter the detail for that and when we hit Create we have only just completed half the work required for setting up Vpc Network Peering. This is because we essentially need Lunicon Europe to repeat the steps and complete the connection and this warning message here says as much. So let us go ahead to Lunicon Europe and complete the connection. So let us switch over to Lunicon Europe and set up a new Vpc Peering connection. We give this a name and list our shared network and we hope that the global entity has supplied their own project ID and the name of their shared network as well.

And with that in place, we just hit Create. And while waiting for this, we see that this network peering has failed. And then when we look further and take a look at the warning, it looks like there is a conflict in the IP address ranges and this conflict appears to be between our own local network and the remote network on the Loonicon Global project. So let us take a look at our own network and let us investigate whether this particular subnet Ten 00:24 is in conflict with the remote network. So we go over to Looneycon Global and taking a look at their network and we see that there is a direct conflict. So in the real world, I can imagine the resolution to this problem would be really complicated.

But in our simulated world, let us just go to Lunicon Europe and get rid of the offending subnet. So we switch over to the Europe project, we head over to our network and we just take a look at the subnet which is in conflict and we just go ahead and delete it. Once this is done, let us go and try to refresh our network peering connection and see if the connection is established. So we go back to Vpc Network Peering and try again and the connection fails again, let us take a look at the error message this time and we notice that it is different. Whereas previously our local network was in direct conflict with the network in the Lunicon Global project, on this occasion the conflict is between our local network and a network which Loonicon Global is peered with.

If you remember, the Loonicon Global project already had a peer connection with Loonicon Asia. So let us go to the Loonicon Asia project and see what their IP address range is. So we see that their shared network has that IP address range. Let’s take a note of that and switch over back to Lunicon Europe. And on this occasion as well we have a direct conflict and again, since we are not in the real world, we can just go ahead and delete the subnet. And once that is done, let us try to reset our network peering connection. So we head over to the Vpc Network peering page, hit refresh and this time the connection is successful. Let us head over to the global project and see the status of the connection at that end.

So once we make the switch and this has turned green over here as well so we have successfully set up Vpc Network Peering. Let us now try to test our configuration by exploring the connectivity between two instances on either side of our peer connection. So in the Loonicon Global side, we know the internal IP address of an instance we have already provisioned. We now head over to Loonicon Europe and see that there is an instance here already. So let us ssh into it and let us use the internal IP of the remote host and see if it’s reachable from over here and we see that the ping is successful. Let us now run one more test and note the internal IP address of the instance in Lunicon Asia and see if this is reachable from Europe going back to Europe with ping using an internal IP and this fails.

And this absolutely makes sense because Lunic and Europe never really set out to establish a peer in connection with Asia. So it would be a bit of a security hole if they could suddenly start communicating with each other without explicitly setting anything up. Finally, let us see what will happen if we were to delete a pure in connection from one end. So from within Lunic on Europe, let us go over to our connection and then hit delete. So we need to wait a few seconds for the changes to take effect. But once it’s done, we just switch over to the global project and we see that the network peering is broken from this end as well. Well, so a network peer can be broken unilaterally. This concludes the demo. I hope it was useful. Bye.

19. Cloud DNS And Legacy Networks

A domain name service should be very familiar to you. This is a service which enables routing on the Internet. A domain name service basically maintains a directory of domain names and translates them to IP addresses so that your packets can reach its destination. Google offers its own version of the DNS called the Cloud DNS, which is a fully managed service. Google’s domain name service, called Cloud DNS is a high performance, production quality, resilient global domain name service that publishes your domain names to the global DNS in a very cost effective way. They provide reliable, low latency lookups for your domains from anywhere in the world. Cloud DNS is a hierarchical distributed database.

You can store your external IP addresses and other data and then look them up by name. Cloud DNS allows you to publish the zones and records within the DNS without actually having to manage your own DNS server. The Gcp manages it for you. You’ve seen that a GCP project is a container for resources, and every Cloud DNS resource lives within a project. And every Cloud DNS operation must specify the project it has to work with within a Cloud DNS. The concept of a managed zone is an entity which manages the DNS records for a particular suffix. So if you have the nameexample. com nail example site example will be within a single managed zone. In cloud DNS. The managed zone is the resource that models a DNS zone.

All records in a managed zone are hosted on the same Google operated name servers. As you can see on screen, there are different kinds of records that are contained within your DNS. The A stands for an address record. This maps host names to iPV four addresses. So A stands for Start of Authority Record, which specifies authoritative information about a DNS zone. So an SOA record is created for you within a DNS when you create your manage zone to manage all the names associated with a particular site or a particular suffix. MX is the mail Exchange record. It’s used to route requests to mail servers. Ms is the name server record which delegates a DNS zone to an authoritative server.

All of these are basically standard domain name concepts. They are the same for Cloud DNS. You might want to read the documentation carefully to see where exactly they differ. Cloud DNS holds a resource record sets collection. This collection holds the current state of the DNS records that make up a particular managed zone. You can read this collection, but you do not modify it directly. Rather, you would edit the record resource record in a managed zone by creating a change request in the changes collection. This change request containing additions or deletions, can be done in bulk or as a single atomic transaction. These changes are first made to the authoritative servers and then picked up by the DNS resolvers when their cache expires. And that’s all about Cloud DNS we’ll quickly look at legacy Gcp networks.

We haven’t really referenced it much in this section of the course because they are legacy and they are no longer recommended for use. They exist though, and you should have a brief idea of how they work and what they are. These legacy networks have been replaced by VPCs that we discussed in a lot of detail in this section. In the legacy networks that Gcp used to offer the instance, IP addresses were not grouped by region or by zone, so they weren’t a range of IP addresses assigned to a subnet. In fact, legacy networks do not have subnets at all. So the virtual machines that existed on a legacy network had random and non contiguous IP addresses. As you can imagine, this is a little confusing. You can’t address instances by IP range and so on.

Legacy networks still exist and are part of the Google Cloud platform. It’s possible to create legacy networks through the Gcloud Command Line tool and the Rest API, but the web console does not support it. Here is a block diagram of a legacy Gcp network. It looks very similar to a VPC network, except for some subtle differences which are pretty important, and these have to do with the IP addresses that are assigned to the VM instances across this network. The first most important difference is that there are no subnets. The VM instances are across zones and across regions, but there is no subnet, demarcation or logically partitioning of the network. Also, the IP addresses of these PMS are drawn randomly and unpredictably from the Ten 2400 Forward slash 16 prefix.