Link Search Menu Expand Document
calendar_month 03-Apr-24

EdgeConnect SD-WAN Branch Design

This section provides the basics for designing and orchestrating an SD-WAN deployment for branches, with considerations specific to the branch network design.

The above video summarizes the information in this chapter of the VSG.

Table of contents

Design Overview

This section describes design details for the SD-WAN gateways, switches, and access points required to design branch networks. The design elements of the branch include:

  • EdgeConnect SD-WAN gateways provide the default gateway for all VLANs, as well as connectivity to the SD-WAN fabric and Internet services.
  • Wireless APs operate in bridge mode to eliminate the need for a wireless gateway at the branch, reducing the number of total infastructure devices.
  • Wired access is provided by stacked 6200/6300 switches for ease of management.
  • A collapsed core is provided with VSX or VSF with multi-chassis LAGs to the access, providing a non-blocking Layer 2 domain for effective bandwidth usage in the large branch.
  • Segmentation between VLANs is provided by the EdgeConnect SD-WAN gateways using role-based policies, application-aware policies, and IP address policies.

The topologies below illustrate large and small branch samples.

Large Branch Topology

Large Branch Overview

Small Branch Topology

Small Branch Overview

SD-WAN Gateways

This section covers details of the SD-WAN gateway design at the branch.

Inline Topology

Inline is the preferred method for deploying EdgeConnect SD-WAN Appliances to connect two or more network segments at the branch.

The “appliance” is the device placed between the WAN and LAN network segments.

For inline deployment, the assigned appliances serve as the routers for locally attached subnets and can provide pass-through capability for local traffic flow. In addition to pass-through, the appliances can exchange route updates using OSPF or BGP (LAN side) and BGP (WAN side) with non-EdgeConnect SD-WAN devices to accommodate various topologies.

When deployed inline, appliances perform functions typically allocated to a traditional branch router, such as performing NAT translations, acting as a DHCP server, and providing a variety of interfaces for different connectivity types.

High Availability

High Availability (HA) at the branch is achieved using a feature called EdgeHA. EdgeHA provides fault tolerance for both WAN connectivity and equipment. The classic SD-WAN use of “hybrid WAN” enables the flow of customer traffic over multiple underlay networks (MPLS, Internet, 4G, etc.), a beneficial feature for maintaining customer traffic if a single underlay network experiences issues such as degradation or downtime.

In the diagram below, a branch deployment shows with two EdgeConnect instances, each connected with a single WAN link to two different underlay networks. Note that no WAN-side switches are required. The EdgeConnect appliances are interconnected with an EdgeHA link that enables tunnels for each underlay network to connect to both appliances. On the LAN side, protocols such as Virtual Router Redundancy Protocol (VRRP) or standard routing protocols are used to direct customer traffic to the EdgeConnect appliances.


LAN Routing Integration

At the branch, LAN integration may be Layer 2 or Layer 3. Layer 2 LAN integration is recommended because it enables the SD-WAN Gateways to act as the policy enforcement point between VLANs.

For Layer 3, when advertising routes into the LAN, set the OSPF metric higher on the standby appliance to ensure that traffic is sent there only during an outage of the first appliance and to avoid ECMP. This maintains flows symmetry to help ensure that features such as Boost function properly.

For Layer 2, ensure that all redundant links are port-channeled. The EdgeConnect SD-WAN appliances do not participate in spanning tree, so connect their interfaces to switchports with spanning-tree loop prevention mechanisms such as BPDU-guard enabled. When using Layer 2, the gateways serve as the default-gateway for all VLANs. VRRP should be configured to provide gateway redundancy.

WAN Routing Integration: Provider

For private circuits such as MPLS, it is important to consider if underlay routing is required. Underlay routing enables direct branch-to-branch traffic flows between SD-WAN sites and traditional sites and enables reachability to underlay services, such as SIP trunks, possibly used in the future.

If underlay services are not required and there is limited branch-to-branch communication, consider removing the provider BGP connections at the branch and establish a default route. This causes all spoke-to-spoke traffic to traverse through the hub.

BGP adjacency can be maintained during migration, if required, but removing BGP is recommended after all sites are on the SD-WAN solution, when possible. This ensures that the MPLS circuit is used only for underlay tunnel establishment and pushes all traffic into the overlay.

WAN Routing Integration: Overlay

The main goal when designing overlay WAN routing is to simplify the design while achieving the desired outcome. Aruba recommends that each branch advertises a summary route and covers the prefixes at that branch. A static default route should be configured on Internet circuits for Internet egress traffic and establishment of overlay tunnels.


The size of most branch networks requires the use of a collapsed core topology. The sections below describe what to consider at each layer of the switching infrastructure. Many of these topics are covered in more depth in the Campus Design section of the VSG.

Collapsed Core

The collapsed core can function as a Layer-3 point in the network, terminating the VLANs, or act as a Layer-2 point. The recommended design is Layer-2, allowing the default-gateway to reside at the EdgeConnect SD-WAN gateways where advanced policy can be enforced. In a small branch, this is the only switching block. In a large branch, the collapsed core interconnects the access switches and the SD-WAN gateways.

Chassis Virtualization

Selecting the chassis virtualization technique at the collapsed core is critical for effective design. CX 8000 series switches run VSX, while CX 6000 series switches run VSF.

VSX provides increased resiliency by separating the control and management planes. VSX also enables in-service software upgrades (ISSU) that can help avoid downtime at the branch. The main challenge with VSX is that all ports on the CX 8000 series switches ship in the shutdown state and are configured as Layer 3 ports. Deploying VSX pairs requires a one-touch procedure, instead of zero-touch, to pre-configure the switch for reachability to Central.

VSF, which is the default on CX 6000 series switches, unifies the control, data, and management planes for slightly reduced resiliency, but easier management. Software upgrades generally require an outage. VSF stacks enable full zero-touch provisioning.


Use Aruba CX switches that support VSF stacking for simplified growth in the network closet. For Layer 2 access designs, use uplink ports on different VSF stack members, one into each MC-LAG configured aggregation switch. This ensures efficient, fault-tolerant Layer 2 bandwidth up from the access layer.

Enable Aruba ESP Colorless Ports by configuring port policies to allow 802.1x dynamic authentication and network configuration.

Enable Layer 2 protection mechanisms such as Loop Protection, BPDU Filter, Root Guard, and BPDU Protection.


Wireless access is provided using a bridge mode deployment. In this mode, the AP bridges traffic from the WLAN onto the correct user VLAN. AP-connected switch ports must trunk all wireless user VLANs. For more detail on this deployment mode, refer to the WLAN Design section of the VSG.

Bridge Mode Wireless

Zero Touch Provisioning

Zero Touch Provisioning (ZTP) is critical for the branch. For many deployments, prestaging all the equipment with configurations is not feasible and non-IT resources must be called to do the physical deployment.

EdgeConnect SD-WAN

ZTP enables the EdgeConnect SD-WAN appliance to communicate with the Aruba Cloud Portal. The Cloud Portal redirects the appliance to and registers it with the customer’s Orchestrator, which enables remote configuration of the device by an operator or a configuration push from Orchestrator using a YAML file.

To accommodate ZTP, an Internet circuit with public DNS is recommended at the branch. This enables direct, unrestricted communication with the Cloud Portal and Orchestrator. Sites without a local Internet circuit likely are unable to use ZTP, and prestaging of the devices is required.

The EdgeConnect SD-WAN appliances should be configured to provide DHCP on a management VLAN to LAN network infrastructure to accommodate the ZTP process.


Switching and Wireless

The APs and switches must receive IP addressing and domain name server (DNS) information from the SD-WAN gateways before they can communicate with Central. Switches and APs should be connected after the SD-WAN gateways are online and fully functional. The SD-WAN gateway must provide the following items to the APs and switches:

  • DHCP addressing
  • DHCP options 3 (Router) and 5 (Name Server)
  • Internet access


Management of APs and switches is handled by Aruba Central. Management of SD-WAN gateways is handled by Aruba Orchestrator. Although both solutions have an on-premises option, the cloud-hosted option is recommended.

These platforms offer integrations to ease the management and reporting between them, and will continue to be integrated more fully. For more information on the integrations, see the Aruba SD-WAN Docs.

Segmentation and Policy

This section describes how to segment traffic within the branch, across the WAN, and to the Internet.

Within a Branch

Within the branch, Layer 2 VLANs are used to segment the traffic. This provides a course-grain level of segmentation. Devices within a VLAN can communicate directly, but communication outside a VLAN must be route between the SD-WAN gateways.

The SD-WAN gateways act as the default-gateway for all VLANs. The SD-WAN gateways provide zone-based stateful firewalling, IPS/IDS, and role based policy to filter traffic between the VLANs.

Across the WAN

Across the VRFs, which are referred to as “segments” in Orchestrator, are used to provides layer 3 isolation and a dedicated route table. VLANs at the branch are mapped into segments. Common segments include Guest, IoT, and Corporate.

VRF Example


Internet egress design at the branch is very flexible. On-box IPS/IDS and stateful firewalling can be used for on-box policy of traffic destined to the Internet. For more advanced cloud-based filtering integrations, use Secure Serviced Edge (SSE) providers such as Axis and Zscaler.

Internet egress designs vary based on requirements. A common Internet egress design is shown below.

  • Guest BIO has direct Internet access, with limited or no on-box policy applied to move the traffic out of the network as fast as possible.
  • Business traffic is sent to an SSE for further logging and policy enforcement.
  • Sensitive traffic, which may be subject to compliance, is back-hauled to a centralized DC for additional logging and inspection.
  • Other traffic is subjected to IPS/IDS and basic on-box policy before being routed directly to the Internet.

VRF Example

Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.