The most common use-case for integrating any SD-WAN solution with a Cloud IaaS solution is precisely to facilitate the communication between the physical locations and the Virtual Private Cloud environments, allowing users to reach workloads hosted in said VPCs through the SD-WAN network. In this type of deployment, Aruba vGWs working as NCC Spokes would have an interface in a transit VPC to peer with the Cloud Router in their same region.
Once the vGWs are peering with the Cloud router, connecting a VPC to the SD-WAN is as simple as following two quick steps:
Step 1 Create the VPC peering between the transit-vpc and the VPCs where we have our workloads.
Step 2 Add Custom routes in the Cloud router for those VPCs that have to be reached. These routes are automatically advertised to the Aruba vGWs through BGP.
Another interesting use-case for integrating SD-Branch with GCP is precisely to make use of Google’s global networking infrastructure as a “Backbone as a Service”, not so much to connect branch locations to workloads running in GCP but to use it for site-to-site connectivity between branch locations. As opposed to what happens when traffic traverses the Internet, communication between GCP nodes goes through a private backbone that can offered SLEs, Quality of Service, etc. This allows for lower latencies, more predictable communications, and an overall more robust user experience.
Enabling this is as simple as connecting Aruba vGWs defined as NCC spokes to their regional cloud routers and peering using BGP. Once this is done, the NCC hub takes care of distributing those prefixes across the network to ensure the connectivity of any branch location to any other branch location through the CGP backbone.
When it comes to defining the Internet-facing interface of the Aruba vGWs, GCP offers two different Network Service Tiers. In the standard offering, the vGW would be assigned a public IP address from the GCP region where it is located. Tunnels coming into the vGWs would reach it through all the Internet hops that may be on the way. This is adequate in most situations where the SD-Branch locations may be relatively close to the GCP region, or when latency requirements are not too restrictive.
For those situations where routing through the Internet could lead to unacceptable delays in the communication, GCP provides the option to assign a “Premium Tier” public IP address to the vGW. When doing so, Google assigns a global Anycast IP address that is advertised from all of GCP’s points presence (PoPs). Once the communication from the branch location reaches their nearest PoP, traffic is routed through the GCP backbone.
Aruba vGWs can be deployed using both modes of operation. However, when using a “Hub and Spoke” SD-WAN topology, all cloud-to-cloud communications should go over the GCP backbone. Establishing IPsec tunnels between “Premium Tier” IP addresses is not currently supported by GCP, meaning that customers willing to use a “Hub MESH” topology between Aruba vGWs should refrain from using Premium Tier IPs. More details about GCP Networking Tiers can be found in the GCP documentation.