Introduction

Before going into details about how the Aruba vGW is deployed and operated, it’s important to set some basic design principles to understand how vGWs fit into the networking architecture in Google Cloud.

vGW in Public Cloud Infrastructure

Aruba Branch Gateways support standard IPsec tunnels and could therefore establish direct communication with GCP Cloud VPN or even into the Network Connectivity Center (NCC) Hub. So, why would an Aruba Virtual Gateway be needed to integrate with GCP?

The GCP VPN Concentrators don’t support the SD-WAN capabilities of an Aruba VPNC (or vGW, in the case of Public Cloud infrastructure). The most relevant would be:

• Reverse Path Pinning, which ensures the traffic always returns through the same path of origin as it came from, allowing for Branch Gateways (BGWs) to perform Uplink load-balancing and Dynamic Path Steering.

• Forward Error Correction, to protect critical traffic flows from potential network issues between the branches and the cloud, especially when traversing the Internet.

• Tunnel Orchestration, which automates the establishment of IPsec tunnels from all BGWs to all relevant VPNCs (including the vGW).

• Orchestrated Routing, which automates the exchange of routes across the SD-WAN.

• End-to-End visibility of all the SD-WAN network under a single application (Aruba Central).

On top of these capabilities, SD-Branch Virtual Gateways also provide connectivity for other types of environments, like the Virtual Internet Access (VIA) VPN Client or the Microbranch solution based on Aruba Remote Access Points.

In summary, the use of the vGW to connect the branch locations to the Public Cloud is encouraged in those situations where the connectivity between branches and the cloud needs a more advanced solution that what could be achieved by establishing an IPsec tunnel over the Internet. With the end-to-end visibility and orchestration, as well as the path optimization mechanisms available in SD-Branch, it truly brings the Public Cloud environment into the SD-WAN network as if it were another Data Center.

Virtual Gateway Sizing

Aruba Virtual Gateways can serve multiple functions in the Edge to Cloud communication, from terminating tunnels from only SD-Branch Gateways to also enabling other use-cases like Micro-Branch or VPN making use of the VIA client.

From the perspective of establishing an SD-WAN overlay, the following table describes the performance delivered by the different models (and the corresponding GCP Machines).

For other use-cases such as IAP-VPN, AOS 10 Micro-Branch or VIA, some additional factors need to be considered:

When a vGW is performing multiple functions simultaneously, the recommendation is to consider the impact relative to the maximum it can provide. For example, on a vGW-500 terminating tunnels from VIA, IAP-VPN and SD-Branch Gateways:

Step 1 200 IAP-VPN branches consume 50% of the capacity of the gateway (400).

Step 2 400 SD-WAN tunnels consume a further 25% of the capacity of the gateway (1600)

Step 3 As a result, there’s only 25% left of the total capacity for VIA clients (800); No more than 200 clients should be expected to connect at any time.

Related Documentation

Even though it’s not strictly the objective of this Technical Note, the main purpose of a vGW in GCP is to facilitate the connectivity of branch locations, teleworkers, and remote clients to the VPCs. To do so, the SD-Branch, Teleworker and VPN solutions depend on other elements such as the SD-WAN Orchestrator. If you’re not familiar with how these solutions work, the resources below should be of great help:

• Aruba SD-Branch Design and Deployment Guide
• Aruba SD-WAN Orchestrator Tech note
• Micro-Branch for Teleworkers Solution guide
• VIA Remote Users Solution Guide

---