Aruba EdgeConnect SD-Branch Solution Fundamentals

This section reviews Aruba Central, Gateway devices, and Orchestration details to provide an overview of EdgeConnect SD-Branch components and offer guidance for device selection.

Table of contents

• Aruba EdgeConnect SD-Branch Solution Fundamentals
  • Aruba Central
  • SD-WAN Orchestrator
    • Overlay Tunnel Orchestrator
    • Overlay Route Orchestrator
    • Orchestrator and Group Design
  • Device Overview
    • Device Onboarding
      • System IP
    • Security Capabilities

Aruba Central

Aruba Central is a powerful cloud networking solution. As the management and orchestration console for Aruba ESP (Edge Services Platform), Central provides centralized cloud-based management for devices, policy, and templates to enable deployment of branch sites quickly, with group-based configuration. For more detail on groups, see the “Orchestrator and Group Design” section.

Aruba Central offers key insights on WAN health and optimization to help organizations determine the best path for traffic on per-user, per-device, or per-application policies. Historical data reports, monitoring for PCI compliance, and troubleshooting for regional and global locations can all be viewed in the Central dashboard.

Aruba Central also hosts the cloud-based Orchestrators that allow dynamic building and scaling of IPsec tunnels as needed.

SD-WAN Orchestrator

The SD-WAN Orchestrator automates site-to-site tunnels and route propagation between Branch Gateways (BGW) and VPN Concentrators. The SD-WAN Orchestrator has two components: Overlay Tunnel Orchestrator (OTO) and Overlay Route Orchestrator (ORO).

The Aruba SD-WAN Orchestrator delivers the following features and functions:

• The IPsec overlay is automatically created using Overlay Tunnel Orchestration.
• Automatic route propagation is managed by Overlay Route Orchestrator. Route redistribution can be performed at the group configuration level.
• Hub preference enables an administrator to prefer one hub site to another site by setting routing costs that are translated into the data center’s dynamic routing process.
• Devices dynamically adopt the group overlay configuration, build the tunnels, and enforce route policy.
• Scalability is built into the orchestration, to assist organizations with building robust and cost-effective routing designs.

This section reviews the differences between each of the Orchestrator components and describes how the two components work together to automate tunnel orchestration. Additional details about the Orchestrator and other SD-Branch features can be found here .

Overlay Tunnel Orchestrator

The Overlay Tunnel Orchestrator automatically generates and manages IPsec configuration between devices and identifies where devices should tunnel.

The Orchestrator identifies where to build tunnels using labels on interfaces. Labels include a combination of Uplink Types and Link Names configured on the WAN uplink page within Aruba Central. This enables the Orchestrator to grab interface IP addresses dynamically to build IPsec tunnels between branch gateways and VPN Concentrators.

Supported uplink types currently available include MetroEthernet, INET, MPLS, and LTE. The combination of both labels (Uplink Types and Link Names) applied to an interface identifies the interface as a WAN Uplink. If no WAN uplink is identified, tunnels are not built.

In order for a BGW to build a tunnel to a headend site, the uplink types should match, with some caveats. For uplink naming, MPLS uplink types must have the same uplink type and link name for the tunnel to be built. INET, MetroEthernet, and LTE uplink types prioritize building a tunnel to a device with the same link name; however, if the criteria do not match, a tunnel is built to the next available INET, MetroEthernet, or LTE uplink type regardless of link name. When deploying an EdgeConnect SD-Branch, it is important to maintain a consistent expandable naming convention so tunnels can be built between devices.

Note: VPNCs only support MPLS and INET uplink types. If a branch gateway uses MetroEthernet or LTE uplink types, they connect to the INET uplink type of the VPNC using the uplink name as an additional matching criteria. If there is no matching name, the tunnel is built to any available INET uplink of the VPNC .

Note: The slow_INET has an uplink name that does not match the headend, but due to INET uplink type, the tunnel is created between the two endpoints

Overlay Route Orchestrator

The Aruba Overlay Route Orchestrator enables the distribution of routing information between branches and VPN concentrators. It provides route distribution across sites using the Control Connection Overlay Agent Protocol (OAP). The OAP runs in a separate process on each device and interacts with the underlay routing stack to exchange and advertise prefixes with the Route Orchestrator that distribute routes to branches and VPN Concentrators.

The Route Orchestrator learns routing information by redistributing routes into the SD-WAN overlay. Administrators can select one or more of the routing sources (connected, static routes, OSPF, BGP) to determine the routes that enter the SD-WAN overlay.

The main functions of Aruba Route Orchestrator include:

• Learning routes from headend and branch sites

• Advertising routes across the SD-WAN network with appropriate costs

• Redistributing routes into the LAN side with appropriate costs.

Orchestrator and Group Design

The previous two sections described the Aruba Orchestrator components and the parameters required for user input. However, it is important to note that users do not need to input parameters for every device brought into the SD-WAN fabric. The Orchestrator works hand-in-hand with Aruba Central, which has a two-tiered hierarchy for group and device level configuration. Configurations for DNS, Route Redistribution, WAN uplinks, and other options are defined a single time at the group level. Specific configuration, such as IP addresses and hostname, is required at the device level.

Any devices brought into the group inherit the configuration parameters as soon as they are online. This enables administrators to configure a group a single time. When creating groups, it is important to decide the routes to be included in the fabric and the interfaces to be used.

Device Overview

The gateway can be deployed physically or virtually for WAN connectivity. Aruba uses two different types of gateways: a Headend Gateway and Branch Gateways.

The same model device can be a headend gateway or a branch gateway, depending on the scale of the SD-WAN fabric. The difference between a branch gateway and headend gateway depends on its function or deployment.

In addition to gateways, access points can participate in the SD-WAN fabric. They are referred to as Microbranch access points and fall under the branch category. The following list covers the definition of Microbranch, Headend, Branch, and Virtual gateways, as well as the role the device performs.

VPN Concentrator (VPNC) - The VPN Concentrator, also called a hub or headend gateway, acts as a VPN concentrator terminating IPsec tunnels, from branch gateways, Microbranch APs and VIA clients. The headend also advertises routes from the data center or campus environment to the branch gateways using redistribution of Connected, Static, OSPF, or BGP prefixes .

Virtual Gateways (VGW) - The virtual gateway extends the SD-WAN overlay services to the public cloud infrastructure. Virtual gateways function as VPN concentrators and terminate tunnels from branch gateways, Instant APs, and VIA clients. Like the hardware VPN concentrators, virtual gateways support routing, security, and tunneling features. Virtual gateways are supported in Amazon Web Services and Microsoft Azure.

Note: The design considerations for using a physical headend gateway versus a virtual gateway are reviewed in the Hub Design section.

Branch Gateways (BGW) - The branch gateway is the appliance at each remote site that terminates its IPsec tunnels to a headend gateway. The branch gateway also can provide dynamic segmentation by serving as a policy enforcement point for wired, wireless, security, and WAN policies including routing. The gateway functions include stateful firewall, web content classification, hybrid WAN connectivity, IPsec VPN, QoS, and WAN path monitoring and selection.

Microbranch - Is a very small branch deployment that uses access points that support building an IPsec tunnel to a headend gateway.

The topology illustration below shows gateway and their placements in a WAN topology. LAN devices also are shown. The specific types of devices needed on the LAN side of a branch or headend site vary depending on the needs of the organization. Details are provided in the “Hub and Branch” design sections.

The table below shows some of the scale numbers for gateway. For complete scale numbers, refer to this page.

Note: For details on switching and access points, refer to the respective data sheets.

Device Onboarding

Users have three methods to onboard gateways: One Touch Provisioning (OTP), Zero Touch Provisioning (ZTP) and the installer application. All methods can be used in combination; however, using a consistent deployment procedure is recommended when setting up branch sites.

OTP and ZTP both require an admin user to place the gateways in the proper groups for configuration after onboarding in Central. The installer app automatically places onboard devices into the appropriate group during onboarding.

One Touch Provisioning is typically used for sites when DHCP is not available for connected uplinks, usually a headend site or a branch site. One touch provisioning requires using the CLI or Web UI to configure the uplinks of a gateway for internet reachability. The gateway is then directed to Central for the remaining configuration.

Zero Touch Provisioning is good to use for deployments where DHCP is available. After a gateway receives DHCP, it reaches out to Central for its configuration.

Installer Application allows an authorized installer to select a group and scan a brand new device to be added into the selected group. The admin must specify the device groups the installer is authorized to access.

System IP

The system IP (system-ip) is a critical configuration element for each gateway operating as a VPNC or BGW. When onboarding one VLAN interface as its system IP. By default, the Aruba Gateway uses this interface to communicate with network services such as RADIUS, syslog, TACACS+, and SNMP. The VLAN interface selected for the system-ip on each gateway must have an IPv4 address assigned for the gateway to be fully functional. A gateway cannot initialize fully unless the assigned VLAN interface is active and operational. Central does not allow a gateway to obtain addressing dynamically from Internet service providers using DHCP or PPPoE as the system IP.

Gateway pools can be used to allocate system IP addresses automatically to a dedicated VLAN interface, which is then designated as the System IP address. Each pool includes a unique name along with starting and ending IPv4 addresses. The range of addresses defined for each pool cannot overlap. Aruba recommends configuring one gateway pool for each group, since IP addresses are configured and applied to VLAN interfaces on a per-group basis. The gateway pool must include enough IPv4 addresses to support all the Aruba gateways assigned to the group. Although a group can support multiple gateway pools, specific IP addressing should not be applied dynamically.

Security Capabilities

Security in EdgeConnect SD-Branch is built in layers, from the hardening of the operating system to the integration with best-of-breed security partners. ArubaOS, running on gateways and microbranch, is a tightly hardened platform that includes:

• Secure Boot — Requires Aruba-issued certificate (TPM) to load ArubaOS.
• Secure Zero Touch Provisioning (ZTP) — ZTP leverages the TPM loaded in the Aruba gateways to secure communications with Aruba Central.
• AES 256 encryption — Encryption is used for SD-WAN overlay tunnels.
• Aruba Role-Based Stateful Firewall — The firewall supports scalable configuration using firewall aliases, ALGs, and role-based policies.
• Deep Packet Inspection — Qosmos’s application engine and signatures provide the capacity to identify almost 3500 applications.
• Web Content, Reputation and Geo-location Filtering — WebRoot’s machine learning technology classifies content, reputation, and geolocation for billions of URLs.
• Aruba Threat Defense — Powered by ProofPoint’s Threat Intelligence, Aruba 9000 series gateways can perform IDS/IPS functions for all branch traffic.

The Aruba ESP solution can integrate with ClearPass (or any other AAA server) to form a true policy-driven branch. This model dynamically assigns policies based on users, devices and applications, as opposed to the traditional method of assigning these policies manually based on ports, VLANs, and IP addresses. The policy-driven branch can be enhanced further by integrating with more than 140 partners in the ClearPass Exchange program, to take advantage of Aruba ESP’s cumulative AI/ML-driven Client Insights.

---

Table of contents

• SD-Branch Overlay Design
• SD-Branch Hub Design
• SD-Branch Branch Design
• Microbranch Design

---