VPC Network Peering
1. VPC Network Peering
Welcome to the Sharing VPC Networks module of the Networking in Google Cloud course. This covers more details on sharing a VPC network. You will learn how to connect isolated Virtual Private Clouds (VPCs) using VPC Network Peering, enable centralized network management with Shared VPC, and migrate virtual machines (VMs) between networks. Through hands-on labs and practical examples, you'll gain a understanding of these essential networking concepts, ensuring optimal performance, security, and resource utilization. Let us start with a usecase. Lucian, a network engineer at Cymbal Corporation, faces a new challenge: seamlessly connecting and establishing a direct connection between their two organizations by consumer and producer. Public internet peering introduces unacceptable latency and security risks, while dedicated VPNs are proving cost-prohibitive. Lucian needs a solution that's private, secure, and scales with their evolving needs. Lucian opts to use VPC Network Peering. VPC Network Peering allows private connectivity across two VPC networks. Even if both VPC networks belong to the same project or the same organization, you can still peer them. Remember that each VPC network will have firewall rules that define what traffic is allowed or denied between the peered networks. For example, in this diagram, two organizations represent a consumer and a producer, respectively. Each organization has its own organization node, VPC network, VM instances, Network Admin, and Instance Admin. To successfully establish VPC Network Peering, two peering relationships must be created. The producer network administrator must peer the producer network with the consumer network. The consumer network administrator must peer the consumer network with the producer network. When both peering connections are created, the VPC Network Peering session becomes active and routes are exchanged. The peering relationships let the VM instance use their internal IP addresses to communicate privately. VPC Network Peering is a decentralized or distributed approach to multi-project networking. Each VPC network may remain in the control of separate administrator groups and maintains its own global firewall and routing tables. Historically, such projects would consider external IP addresses or VPNs to facilitate private communication between VPC networks. However, VPC Network Peering does not incur the network latency, security, and cost drawbacks that are present when you use external IP addresses or VPNs. Let’s talk about a few points to remember when using VPC Network Peering. First of all, VPC Network Peering works with Compute Engine, Google Kubernetes Engine, and App Engine flexible environments. You need to have the network administrator role to perform peering. Peered VPC networks remain administratively separate. In other words, routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks. These tools are not managed centrally for all network peers. Each side of a VPC Network Peering association is set up independently. Peering will be active only when the configuration from both sides matches. This arrangement allows either side to delete the peering association at any time. A subnet CIDR prefix in one peered VPC network cannot overlap with a subnet CIDR prefix in another peered network. For example, two auto mode VPC networks that only have the default subnets cannot peer. Google Cloud returns an error if any of the following operations result in an overlap. Only directly peered networks can communicate, which means that transitive peering is not supported. Let me explain this with an example. Suppose VPC network CymbalBank1 is peered with CymbalBank2 and CymbalBank3. In that scenario, CymbalBank2 and CymbalBank3 are not directly connected. VPC network CymbalBank2 cannot communicate with VPC network CymbalBank3 over a peered connection. If CymbalBank1 offered SaaS services to CymbalBank2 and CymbalBank3, this situation could be critical. Next, let's explore the steps involved in initiating a VPC peering connection. Before you begin, you must have the name of the VPC network to which you will peer with. If that VPC network is located in another project, you must also have the project ID and network name. A peering configuration establishes the intent to connect to another VPC network. The VPC networks are not connected until each one has a peering configuration for the other. After the other network has a corresponding configuration to peer with your network, the peering state changes to active in both networks. At that point, the VPC networks are connected through VPC Network Peering. After peering is established, the two networks automatically exchange subnet routes. The peering state remains inactive. An inactive peering state indicates that there is not yet a full VPC Network Peering connection. Suppose you want to peer the two VPC networks shown on the slide. Let’s begin with the Cymbal-Rahway VPC network. You must know the name of the other VPC network, which is Cymbal-Kampala. Because Cymbal-Kampala is not in the same project as Cymbal-Rahway, you must also have the project ID. Cymbal-Kampala is in the Cymbal-bank2 project, whose project ID is cymbal-10101. Custom routes help achieve a desired granularity that cannot be achieved with a default route. Sharing custom routes and dynamic routes with peered VPC networks let networks learn routes directly from their peered networks. For example, if a custom route in a peered network is updated, your VPC network automatically learns and uses the updated custom route. You are not required to configure any additional settings in your VPC network. When you create or modify a peering configuration, you can choose to import routes, export routes, or both. The peer network administrator must similarly configure their peering configuration before routes are exchanged. This process ensures that both network administrators explicitly agree to exchange custom routes before they are exchanged. Let’s consider a sample scenario. Consider you are connecting your on-premises environment through a VPN tunnel or a Cloud Interconnect connection. Cloud Interconnect establishes direct, private connections between your on-premises network and your Google Cloud Virtual Private Cloud (VPC) network. VPN on the other hand provides a secure remote access that establishes an encrypted connection over the public internet. When using either of these connections, you can share dynamic routes. Sharing these routes enables peered networks to reach your on-premises network, as shown in the graphic. For dynamic routes, you must add Cloud Router custom route advertisements in your VPC network. These advertisements announce peered network subnets to your on-premises network. Local routes are always preferred over dynamic routes that are learned by using VPC Network Peering.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.