Routes and route preferences
1. Routes and route preferences
Welcome to the Network Routing and Addressing module. In this module, we will explore foundational elements that guide traffic through the Google Cloud network. We'll start with the building blocks, routing, IPv4, and BYOIP. We'll also explore Cloud DNS. Before we cover routes, let's cover IP addresses. Speaking of IP addresses of a subnet, Google Cloud VPCs let you increase the IP address space of any subnets without any workload shutdown or downtime. This diagram illustrates a network with subnets that have different subnet masks, allowing for more instances in some subnets than others. This gives you flexibility and growth options to meet your needs. But there are some things to remember. The new subnet must not overlap with other subnets in the same VPC network in any region. Each IP range for all subnets in a VPC network must be a unique valid CIDR block. Also, the new subnet IP address ranges are regional internal IP addresses and have to fall within valid IP ranges. Subnet ranges cannot match, be narrower, or be broader than a restricted range. Subnet ranges cannot span a valid RFC range and a privately used public IP address range. Subnet ranges cannot span multiple RFC ranges. The new network range must be larger than the original, which means the prefix length value must be a smaller number. In other words, you cannot undo an expansion. Now, auto mode subnets start with a /20 IP range. They can be expanded to a /16 IP range, but no larger. Alternatively, you can convert the auto mode subnetwork to a custom mode subnetwork to increase the IP range further. A route is created when a network or subnet is created, enabling traffic delivery from anywhere. Routes define the paths that network traffic takes from a virtual machine, or VM, instance to other destinations. These destinations can be inside your Google Cloud Virtual Private Cloud (VPC) network for example, in another VM, or outside of it. Routes match packets by destination IP address. Forward traffic to highest priority or specific route. However, no traffic will flow without also matching a firewall rule. A route is created when a network is created, which enables traffic delivery from anywhere. Also, a route is created when a subnet is created. This is what allows VMs on the same network to communicate. Network tags fine-tune which route is picked. If a route has a network tag, it can be applied only to instances that have the same network tag. Routes without network tags can apply to all instances in the network. This slide shows a simplified routing table. A route can be of many types. There are system-generated, custom peering, NCC, and policy based routes. System-generated routes are simple and can be used by default. When they do not provide the desired granularity, create custom routes. For example, custom routes can be used to route traffic between subnets through a network virtual appliance. Peering routes are used for network peering. VPC Network Peering routes in a different VPC network connected using peering. NCC routes that represent a subnet IP range in a VPC spoke. Policy based routes apply to packets based on source IP, destination IP, protocol, or a combination thereof. Next, you'll learn more about system generated and custom route types. Peering Network Connectivity Center routes and policy-based routes are covered in another module. When you create a VPC network, it includes a system-generated IPv4 default route, 0.0.0.0/0. When you create a dual-stack subnet with an external IPv6 address range in a VPC network, a system generated IPv6 default route (::/0) is added. If the default route doesn't exist, it isn't added. The IPv4 and IPv6 default routes that serve these purposes define a path out of the VPC network to external IP addresses on the Internet. If you access Google APIs and services without using a private service connect endpoint, the default system-generated route can serve as the path to Google APIs and services. Private Service Connect enables you to publish and consume services by using the internal IP addresses that you define. You'll learn more about Private Service Connect later in this course. For more information, in the Google Cloud documentation, refer to configuring Private Google Access and accessing APIs from VMs with external IP addresses. Google Cloud only uses a default route if a route with a more specific destination does not apply to a packet. For information about how destination specificity and route priority influence route selection, see routing order in the Google Cloud documentation. To completely isolate your network from the Internet, or to replace the default route with the custom route, you can delete the default route. For IPv4 only, to route Internet traffic to a different next hop, you can replace the default route with a custom static or dynamic route. For example, you could replace it with a custom static route whose next hop is a proxy VM. If you delete the default route and you do not replace it, packets to IP ranges not covered by other routes are dropped. If you don't have custom static routes that meet the routing requirements for Private Google Access, deleting the default route might disable Private Google Access. Some organizations do not want a default route pointing to the Internet. Instead, they want the default route to point to an on-premises network. To do that, you can create a custom route. You will learn about custom routes later in this module. When you create a subnet, system-generated subnet routes are automatically created. Subnet routes always have the most specific destination and cannot be overridden by higher priority routes. Recall that lower priority number indicates higher priority, so 1 would have a higher priority than 10. Each subnet has at least one subnet route whose destination matches the primary IP range of the subnet. If the subnet has secondary IP ranges, each secondary IP address range has a corresponding subnet route. Custom static routes forward packets to a static route next hop and are useful for all topologies. Dynamic routing generally provides quicker routing performance. Unlike dynamic routing, no processing power is devoted to maintaining and modifying the routes, hence the quicker performance. Custom static routing is more secure than dynamic routing because there's no route advertisement. Note these custom static routing limitations. A custom static route cannot point to a VLAN attachment. It also requires more maintenance because routes are not dynamically updated. For example, a topology change on either network requires you to update static routes. Also, if a link fails, static routes can't reroute traffic automatically. Manually configured routes, which are called custom learned routes, can be used to overcome this limitation. For small, stable topologies, this is not always a significant concern. Here we have two VMs, Pekoe and Oolong, set up in two different VPC, VPC1 and VPC2. A VPN gateway is set up between these two VPCs and two IPSec tunnels have been created. A static route has been created for Pekoe to be able to ping Oolong and enable traffic to flow through the tunnel. A static tunnel forwards packets to a static route next hop and supports various destinations. The supportive static route next hop are instances, internal passthrough Network Load Balancers, and Classic VPN tunnel next hops. Each VM instance has a controller that is kept informed of all routes from the network's routing table. Route changes are propagated to the VM controllers. When you add or delete a route, a set of changes is propagated to the VM controllers. In this example, if you change any of the routes to the Oolong VM, Pekoe can still route packets to Oolong. You can create custom static routes either manually or automatically. To create custom static routes manually, use the Google Cloud app, the Google Cloud CLI compute routes create command, or the routes.insert API. When creating a Classic VPN tunnel without dynamic routing in the Google Cloud console, Cloud VPN may automatically generate static routes. To create the routes, you can also use the Google Cloud app to create a Classic VPN tunnel with policy-based routing, or as a route-based VPN. For more information, see Cloud VPN networks and tunnel routing. Another code-based approach would be to use an IaC system such as Terraform. For large organizations that turn up several networks and test them, static routes can be painful. In the above topology, VMs in the Google VPC route traffic to the VPN gateway through static routes. The VPN gateway encrypts traffic to and from the on-premises network. The on-premises environment has a firewall and a router that knows how to route traffic to the Cloud VPN gateway. As the on-premises network expands through the server network, routes have to be manually configured to route traffic to the resource in the server network. A topology change on either network requires you to manually update static routes. Also, static routes cannot automatically reroute traffic when there is a link failure. A solution is for a network to automatically and rapidly discover topology changes and then route traffic accordingly to minimize disruption. This is exactly the function of Cloud Router. Whenever a link fails, Cloud Router will automatically reroute traffic if another path is possible. Cloud Router peers with an on-premises VPN gateway or router. The router exchanges topology information through a border gateway protocol, or BGP. Cloud Router advertises subnets from its VPC network to the on-premises gateway via BGP. Then, topology changes automatically between your VPC and on-premises network. Dynamic routes are managed by Cloud Routers in the VPC network. Their destinations always represent IP address ranges outside of your VPC network, which are advertised from a BGP peer router. BGP peer routers are typically outside the Google network, like on-premises or on another cloud provider. Dynamic routes are used by: Dedicated Interconnect, Partner Interconnect, Cross-Cloud Interconnect, HA VPN tunnels, Classic VPN tunnels that use dynamic routing, and NCC Router appliances. Routes are added and removed automatically by Cloud Routers in your VPC network. The routes apply to VMs according to the VPC network's dynamic routing mode. This example shows a VPC network connected to an on-premises network that uses Dedicated Interconnect. Cloud Router handles the BGP advertisements and adds them as custom routes. Cloud Router creates a BGP session for the VLAN attachment and its corresponding on-premises peer router. The Cloud Router receives the routes that your on-premises router advertises. These routes are added as custom dynamic routes in your VPC network. The Cloud Router also advertises routes for Google Cloud resources to the on-premises peer router.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.