Silver Peak SD-WAN: Architecture, Models, Licensing, and Management

An intermediate-level guide to how Aruba/HPE Silver Peak (EdgeConnect) SD-WAN works, its hardware and virtual models, licensing tiers, and centralized management with Orchestrator.

Table of Contents

• Chapter 1: Introduction to SD-WAN and the Silver Peak Story
• Chapter 2: Core Architecture and Components
• Chapter 3: How It Works: Tunnels, Path Selection, and Dynamic Path Control
• Chapter 4: Business Intent Overlays and Policy
• Chapter 5: EdgeConnect Models and Hardware Platforms
• Chapter 6: Boost, WAN Optimization, and Performance Features
• Chapter 7: Licensing Models and Subscription Tiers
• Chapter 8: Orchestrator and Centralized Management
• Chapter 9: Security, Segmentation, and SASE Integration
• Chapter 10: Deployment, Operations, and Best Practices

Chapter 1: Introduction to SD-WAN and the Silver Peak Story

Learning Objectives

• Explain what SD-WAN is and the WAN problems it solves compared to traditional MPLS and router-based WANs
• Describe Silver Peak’s evolution from WAN optimization to the Unity EdgeConnect SD-WAN platform and its acquisition by Aruba/HPE
• Identify the core value propositions of the Silver Peak SD-WAN solution

Every organization with more than one location faces the same fundamental challenge: how do you connect a headquarters, a handful of data centers, dozens of branch offices, and a growing pile of cloud applications into one network that is fast, reliable, secure, and affordable? For roughly two decades, the standard answer was MPLS — a private, carrier-managed circuit that delivered predictable performance at a premium price. But the way businesses use their networks has changed dramatically, and the old WAN model has struggled to keep up.

This chapter sets the stage for the rest of the book. We begin with the problems that traditional wide-area networks create, then explain how software-defined WAN (SD-WAN) re-architects the WAN to solve them. Finally, we trace the story of Silver Peak — a company that started in WAN optimization, pivoted to SD-WAN with its Unity EdgeConnect platform, and was ultimately absorbed into Aruba (Hewlett Packard Enterprise). Understanding this history is not trivia: the technical DNA of today’s product, including its distinctive WAN optimization heritage, comes directly from this journey.

A note on terminology before we start. The WAN (wide-area network) is the part of your network that connects geographically separate sites — as opposed to the LAN (local-area network) inside a single building. Everything in this chapter is about the WAN.

The WAN Problem Space

Limitations of MPLS and traditional branch routing

To appreciate why SD-WAN exists, you first need a clear picture of what it replaced. For years, the default enterprise WAN was built on MPLS (Multiprotocol Label Switching) — a private, carrier-provided service that forwards traffic between sites using labels rather than relying on the public Internet. MPLS earned its dominance honestly: it offers predictable latency, contractual service-level agreements (SLAs), and a private path that never touches the open Internet. For voice, video, and business-critical applications, that predictability was worth paying for.

The trouble is what it cost and how it was managed. In a classic MPLS design, each branch has a traditional router, connectivity is mostly or entirely MPLS (often a single or dual circuit per site), and routing decisions are based on IP prefixes, metrics, and static QoS configured router-by-router through the command line. This architecture creates several recurring pain points:

1. High cost per megabit. MPLS bandwidth is significantly more expensive than broadband or dedicated Internet access (DIA) at equivalent speeds. Scaling a branch from 10 Mbps to 100 Mbps across many sites can be cost-prohibitive.
2. Rigid, slow change management. Adding a site, changing QoS priorities, or prioritizing a new application requires router-by-router configuration changes and telco coordination. New MPLS circuits can take weeks or months to provision.
3. Limited path choices. Sites are typically locked into one primary transport, perhaps with a passive Internet VPN as backup. Using multiple links actively and intelligently is difficult in a pure router/MPLS design.
4. Operational complexity. Device-by-device configuration leads to inconsistent policies and error-prone manual changes. Monitoring is fragmented by site and transport, so correlating a performance problem to a specific application or path is hard. [Source: https://www.paloaltonetworks.com/cyberpedia/what-is-sd-wan]

Real-world analogy: Think of MPLS as a private toll highway built exclusively between your offices. It is smooth, reliable, and you never sit in public traffic — but you pay a steep toll per mile, adding a new on-ramp takes the highway authority months, and you only have the one road. Meanwhile, the public roads (the Internet) have gotten dramatically faster and cheaper, and most of where your employees now want to go — the cloud — is reachable from those public roads anyway.

Cloud and SaaS traffic growth driving WAN change

The MPLS model assumed a hub-and-spoke world: applications lived in a central data center, and branches reached them by hauling traffic across the private WAN. That assumption no longer holds. As enterprise traffic shifted toward SaaS (Software-as-a-Service) and IaaS (Infrastructure-as-a-Service) — Microsoft 365, Salesforce, Zoom, AWS, Azure — the destination moved from the corporate data center to the public cloud.

This created a fundamental mismatch. In a traditional design, Internet and SaaS traffic is often backhauled: a branch sends its Microsoft 365 or Zoom traffic across MPLS to a central data center, out through the data center’s Internet firewall, and back again. Every packet takes a long, congested detour. For a video call that needs sub-100-millisecond latency, that detour is the difference between a smooth meeting and a frozen, stuttering one.

Figure 1.1: Backhaul vs. Local Breakout. A side-by-side diagram. On the left, “Traditional Backhaul”: a branch office sends Microsoft 365 traffic over an MPLS line to a central data center, then out to the cloud and all the way back — a long looping path. On the right, “SD-WAN Local Breakout”: the same branch sends Microsoft 365 traffic directly to the cloud over a local Internet circuit, a short direct path, while still being centrally monitored.

flowchart LR
    subgraph Backhaul["Traditional Backhaul"]
        direction LR
        B1["Branch Office"] -->|"MPLS"| DC1["Central Data Center"]
        DC1 -->|"DC Internet Firewall"| C1["Microsoft 365 / Cloud"]
        C1 -.->|"return path"| DC1
        DC1 -.->|"MPLS"| B1
    end
    subgraph Breakout["SD-WAN Local Breakout"]
        direction LR
        B2["Branch Office"] -->|"Local Internet (direct)"| C2["Microsoft 365 / Cloud"]
        B2 -.->|"telemetry"| ORCH["Central Orchestrator (monitoring)"]
    end

Two trends made the mismatch untenable. First, encryption became the default — most modern applications run over HTTPS/TLS, which limited the kind of deep traffic inspection older optimization techniques relied on. Second, Internet broadband and DIA became cheap and ubiquitous, often delivering ten times the bandwidth of an MPLS circuit for a fraction of the price. Enterprises looked at the bill for backhauling cloud traffic over expensive private circuits and asked the obvious question: why not let the branch reach the cloud directly?

Cost, agility, and application performance pressures

These shifts converged into three sustained pressures on network teams. Cost: finance wanted WAN spending down even as bandwidth demand climbed. Agility: the business wanted new sites turned up in days, not months, and new applications prioritized instantly. Application performance: users — increasingly working with cloud and real-time apps — expected LAN-quality experience regardless of which office they sat in.

Traditional router-based WANs could not satisfy all three at once. You could keep MPLS for performance, but cost and agility suffered. You could move to cheap Internet links, but the public Internet offers no SLA and traditional routers had no good way to react when a link degraded mid-call. The market needed a new approach that decoupled application policy from the underlying transport — and that approach is SD-WAN.

Key Takeaway: Traditional MPLS WANs deliver reliable, predictable performance but at high cost, with slow change management, limited path flexibility, and poor support for cloud-bound traffic that must be backhauled inefficiently. The explosive growth of SaaS and IaaS, combined with cheap, abundant broadband, exposed these limits and created sustained pressure for a more cost-effective, agile, and application-aware WAN.

What SD-WAN Delivers

Software-defined control and abstraction of transport

SD-WAN (software-defined wide-area network) applies the principles of software-defined networking (SDN) to the WAN. The central idea is to separate the control plane (the decisions about how traffic should flow) from the data plane (the actual forwarding of packets), and to build an intelligent software overlay that rides on top of whatever physical links — the underlay — happen to be available. [Source: https://www.paloaltonetworks.com/cyberpedia/what-is-sd-wan]

An SD-WAN deployment has three conceptual pieces:

• Edge devices (physical or virtual) at branches, data centers, and clouds, which terminate links and forward traffic.
• A centralized controller or orchestrator — the “brain” — where policy is defined and where network-wide telemetry is collected.
• Encrypted overlay tunnels (typically IPsec) built between edges across one or more underlay transports: MPLS, broadband, DIA, LTE/5G, and so on.

The phrase to internalize is transport independence. In an SD-WAN, the underlay links are treated as interchangeable “transport circuits,” each with measurable characteristics (latency, loss, jitter, available bandwidth). The overlay tunnels and the policies that govern them do not care whether a given packet rides MPLS or cable broadband — they care only whether the path meets the application’s requirements. This is a profound shift from the traditional WAN, where MPLS was effectively the only trusted path and Internet links were second-class citizens used for guest Wi-Fi or passive backup.

Worked example — transport-independent policy. Suppose a branch has two circuits: a 20 Mbps MPLS line and a 100 Mbps cable broadband line. In the legacy world you would hand-configure the router to send “important” subnets over MPLS and everything else over broadband, and that mapping would be static. In an SD-WAN, you instead write a policy in transport-agnostic terms:

“Use any link that satisfies latency < 100 ms, loss < 1%, jitter < 20 ms. Prefer MPLS for ERP traffic, but allow broadband if MPLS is congested.”

The edge device continuously measures both links and enforces this rule per application, automatically. If MPLS degrades during a busy period, ERP traffic shifts to broadband without anyone touching a router. The policy is bound to the intent, not to a fixed circuit.

Centralized policy and orchestration

The single largest operational difference between SD-WAN and a router-based WAN is where intelligence lives. In a traditional WAN the control plane is distributed: every router runs its own routing protocols and is configured individually, and no single entity has a real-time, multi-transport, per-application view of the whole network. In SD-WAN, a centralized orchestrator manages network-wide policies (routing, QoS, security, segmentation), maintains topology and health for all sites and transports, pushes configuration templates to the edges, and aggregates telemetry into one dashboard. [Source: https://www.paloaltonetworks.com/cyberpedia/what-is-sd-wan]

This centralization unlocks two capabilities that traditional WANs lack. The first is zero-touch provisioning (ZTP): you ship an unconfigured edge device to a branch, a non-technical person plugs it in, and it “phones home” to the orchestrator, downloads its configuration, and joins the fabric automatically. The second is policy that scales: changing QoS for a new application becomes one edit in the orchestrator rather than fifty individual router changes.

Worked example — rolling out a new application centrally. Imagine the business adopts a new video-based training platform across 50 branches.

1. The business announces the rollout.
2. The network team defines one policy in the orchestrator: classify this app as “Video-Training,” assign it medium priority, permit it on DIA and broadband but not on MPLS, and cap it at 10 Mbps per branch.
3. The orchestrator pushes the policy to all 50 edges.
4. Each edge begins identifying the application (via deep packet inspection or URL category) and enforces the policy automatically.

In a router-based WAN, step 3 would mean logging into 50 devices and editing access lists and QoS by hand — a multi-day project with real risk of inconsistency. With centralized orchestration it is a single change applied uniformly.

Real-world analogy: A traditional WAN is like a fleet of taxis where every driver decides their own route with no coordination. SD-WAN is a modern ride-hailing platform: a central dispatcher sees every vehicle, every road’s live traffic conditions, and routes each trip optimally — and you change the rules for the entire fleet from one console.

Transport independence and active-active links

Because the overlay abstracts the underlay, SD-WAN can use all available links simultaneously rather than keeping one in cold standby. This is active-active link usage, and it directly attacks the “limited path choices” weakness of MPLS WANs.

The edge devices continuously measure each path’s latency, jitter, loss, and availability, then steer traffic dynamically. Several behaviors follow from this:

• Load sharing across links when desired, increasing aggregate usable bandwidth.
• Application-aware routing using deep packet inspection to identify thousands of applications and route each according to its SLA — voice over the lowest-jitter path, bulk backups over the cheapest path, payment-card traffic over a specific secure overlay.
• Fast failover and brownout detection. Traditional routing reacts only when a link goes fully down. SD-WAN detects degradation — a link that is still up but suffering loss or jitter — and moves affected flows away before users notice.

Worked example — a failover policy. A typical SD-WAN policy for voice might read: “If voice jitter exceeds 30 ms on broadband, move voice flows to MPLS within 300 ms; if MPLS fails entirely, use LTE as emergency backup.” No human intervention, no late-night call to the carrier — the edge enforces it in real time.

The cost implications are significant. Instead of upgrading a 20 Mbps MPLS circuit to an expensive 100 Mbps MPLS circuit, an organization might keep the 20 Mbps MPLS for voice and critical ERP and add a cheap 100 Mbps DIA circuit for everything else — managing both as a single logical WAN. The result is often more total bandwidth per site at lower total cost. Over a multi-year horizon, enterprises with many sites and heavy MPLS use frequently see lower total cost of ownership with SD-WAN, even after accounting for new license and hardware costs. [Source: https://www.paloaltonetworks.com/cyberpedia/what-is-sd-wan]

Figure 1.4: Traditional MPLS WAN vs. SD-WAN Overlay. A contrast diagram. On the left, a traditional WAN where each branch reaches the data center over a single fixed MPLS path with an idle backup. On the right, an SD-WAN where a transport-independent overlay rides active-active across MPLS, broadband, and LTE, steering each flow by its real-time SLA.

flowchart LR
    subgraph Traditional["Traditional MPLS / Router WAN"]
        direction LR
        TB["Branch Router"] ==>|"MPLS (primary, fixed)"| TDC["Data Center"]
        TB -.->|"Internet VPN (idle backup)"| TDC
    end
    subgraph SDWAN["SD-WAN Overlay"]
        direction LR
        SB["Branch Edge"] ==>|"overlay: voice -> lowest jitter"| SDC["Data Center / Cloud Edge"]
        SB ==>|"overlay: bulk -> cheapest path"| SDC
        SB --- U1["MPLS"]
        SB --- U2["Broadband / DIA"]
        SB --- U3["LTE / 5G"]
        U1 -. active-active .- SDC
        U2 -. active-active .- SDC
        U3 -. active-active .- SDC
    end

The table below summarizes the contrast that runs through this entire section.

Figure 1.2: SD-WAN Architecture Overview. A layered diagram. At the top, a centralized “Orchestrator” cloud connecting down to multiple edge devices. The middle layer shows three sites (branch, data center, cloud VPC), each with an edge device. The bottom layer shows the underlay transports (MPLS, broadband, LTE) with encrypted overlay tunnels drawn as a separate logical mesh riding on top of the physical links.

graph TD
    subgraph Control["Control Plane"]
        ORCH["Centralized Orchestrator (policy + telemetry)"]
    end
    subgraph Edges["Edge Layer (sites)"]
        E1["Branch Edge Device"]
        E2["Data Center Edge Device"]
        E3["Cloud VPC Edge Device"]
    end
    subgraph Underlay["Underlay Transports"]
        MPLS["MPLS Circuit"]
        BB["Broadband / DIA"]
        LTE["LTE / 5G"]
    end
    ORCH -->|"config + ZTP"| E1
    ORCH -->|"config + ZTP"| E2
    ORCH -->|"config + ZTP"| E3
    E1 -.->|"encrypted overlay tunnel"| E2
    E2 -.->|"encrypted overlay tunnel"| E3
    E1 -.->|"encrypted overlay tunnel"| E3
    E1 --> MPLS
    E1 --> BB
    E1 --> LTE
    E2 --> MPLS
    E2 --> BB
    E3 --> BB

Key Takeaway: SD-WAN abstracts the physical WAN into a software-controlled overlay governed by a centralized orchestrator, making the network transport-independent. It uses all available links active-active, routes each application by its real-time SLA needs, enables zero-touch provisioning and one-touch policy changes, and breaks cloud traffic out locally — delivering more bandwidth, more agility, and lower cost than traditional MPLS WANs.

The Silver Peak Journey

A note on sources: The factual narrative in this section reflects the public record of Silver Peak’s history and the HPE/Aruba acquisition. Specific figures such as the founding year and the acquisition price should be verified against authoritative sources — HPE/Aruba press releases, the archived Silver Peak site, and trade press such as SDxCentral, CRN, and Network World [Source: https://en.wikipedia.org/wiki/Silver_Peak_Systems].

From NX/VX WAN optimization appliances to Unity EdgeConnect

Silver Peak did not begin life as an SD-WAN company. It was founded in 2004 by David Hughes as a WAN optimization (also called WAN acceleration) company [Source: https://en.wikipedia.org/wiki/Silver_Peak_Systems]. In the mid-2000s, the dominant WAN pain was not the cloud — it was getting acceptable performance out of expensive, bandwidth-constrained MPLS links between data centers and branches. Silver Peak’s early mission was to accelerate TCP-based applications over the WAN, cut bandwidth consumption on costly MPLS, and speed up “chatty” protocols like file sharing (CIFS/SMB), backups, and data replication.

Its early product lines reflected this focus:

• NX — hardware appliances deployed in data centers and larger branches.
• VX — virtual appliances that ran on hypervisors such as VMware, which later proved crucial for cloud and virtualized deployments.
• GMS (Global Management System) — centralized management for the appliances.

The techniques these boxes used define WAN optimization to this day: byte-level deduplication (recognizing repeated byte patterns and sending a small reference instead of resending the full data), compression of data streams, and TCP acceleration (window scaling and acknowledgment spoofing to overcome the throughput penalty of long round-trip times). In this market, Silver Peak competed with Riverbed and Cisco WAAS.

Real-world analogy: WAN optimization is like a pair of people who talk on the phone every day. Instead of repeating the same long story each time, they develop shorthand — “you know, the usual” — and skip the back-and-forth. Deduplication is that shorthand for data: if both ends have already seen a block of bytes, you send a tiny pointer rather than the whole block again.

As the 2010s arrived, the macro picture shifted. Traffic moved from the data center to SaaS and IaaS; encryption became standard, which limited how much deep optimization could help; and enterprises wanted to use multiple link types actively with simple central management. Silver Peak’s response was the Unity architecture — the idea of a single, “unified” WAN fabric connecting data centers, branches, and cloud locations, bringing together physical and virtual appliances, visibility into cloud applications, and path conditioning across multiple transports. Unity was the conceptual stepping stone from point optimization to network-wide overlay control.

Around 2014–2015, that vision crystallized into Unity EdgeConnect, a full SD-WAN platform. Crucially, Silver Peak built EdgeConnect by reusing its existing strengths — virtualization expertise from the VX line, its WAN optimization algorithms, and its path-conditioning techniques for lossy links. The Unity platform settled into three core components, a structure that persists in the product today:

This is the defining characteristic of the platform and the reason the company’s history matters technically. Where most SD-WAN vendors bolted on basic optimization (or none), Silver Peak folded mature, battle-tested WAN optimization into the SD-WAN edge as Boost. It also kept path conditioning — forward error correction (FEC), which sends extra parity packets so lost packets can be reconstructed, and packet-order correction, which resequences out-of-order packets — as a distinct, always-available capability. Path conditioning operates at the network/transport level without deep data inspection, which is what distinguishes it from Boost’s deeper optimization. Together, these let EdgeConnect deliver good real-time performance even over imperfect broadband links.

Figure 1.3: The Silver Peak Evolution Timeline. A horizontal timeline with five milestones: 2004 (founded, WAN optimization with NX/VX/GMS); early 2010s (cloud/SaaS shift challenges data-center-centric optimization); ~2014–2015 (Unity EdgeConnect SD-WAN launches, optimization becomes the Boost add-on); 2020 (HPE/Aruba acquisition); 2023 (consolidation under “HPE Aruba Networking” branding). Each milestone annotated with the corresponding product names.

timeline
    title Silver Peak Evolution: WAN Optimization to SASE
    2004 : Founded by David Hughes : WAN optimization with NX / VX appliances and GMS
    Early 2010s : Cloud and SaaS shift : Data-center-centric optimization challenged ; Unity fabric concept emerges
    2014-2015 : Unity EdgeConnect SD-WAN launches : Optimization becomes the optional Boost add-on
    2020 : HPE / Aruba acquisition : Rebranded Aruba EdgeConnect and Aruba Orchestrator
    2023 : HPE Aruba Networking branding : Axis Security SSE added ; EdgeConnect becomes SD-WAN pillar of SASE

Acquisition by Aruba (HPE) in 2020 and rebranding

In 2020, Hewlett Packard Enterprise (HPE), through its Aruba networking business, acquired Silver Peak for approximately US$925 million in cash (a figure worth verifying against the official press release) [Source: https://en.wikipedia.org/wiki/Silver_Peak_Systems]. The strategic logic was to combine Silver Peak’s mature, application-aware WAN overlay with Aruba’s campus and branch wireless LAN, wired LAN, and security portfolio, creating a unified “edge” platform and accelerating Aruba’s Intelligent Edge strategy.

For existing customers, the transition was evolutionary rather than disruptive. Silver Peak ceased to exist as a standalone company; its engineering teams moved into Aruba’s WAN/edge organization, but development continued on the same EdgeConnect code base. Support contracts and entitlements were honored, appliances and virtual images stayed compatible, and software upgrades followed an evolutionary path with no forklift replacement. What changed was branding and SKUs. The product-name lineage maps cleanly:

Knowing this mapping is practically important: older deployment guides and device configurations still say “Unity,” while newer datasheets and licensing use the HPE Aruba Networking names — but the technology underneath is one continuous lineage [Source: https://www.hpe.com].

Position in the SASE and SSE landscape

The acquisition was not an end point; it positioned EdgeConnect within a larger architectural trend: SASE (Secure Access Service Edge). SASE combines SD-WAN networking with cloud-delivered security services — such as a secure web gateway (SWG), cloud access security broker (CASB), zero-trust network access (ZTNA), and firewall-as-a-service (FWaaS) — into a single, converged fabric. A closely related term, SSE (Security Service Edge), refers specifically to the security half of SASE, delivered from the cloud without necessarily owning the SD-WAN.

EdgeConnect supplies the SD-WAN, or “networking,” pillar of HPE Aruba Networking’s SASE story: branch edge devices that steer and optimize traffic, terminate tunnels into security clouds or directly to applications, and enforce segmentation at the WAN edge. To complete the security side, HPE acquired Axis Security (and its Atmos SSE platform) in 2023, which became the foundation of HPE Aruba Networking SSE. Combined, EdgeConnect SD-WAN plus HPE Aruba Networking SSE form HPE Aruba Networking SASE [Source: https://www.hpe.com]. The full lineage, then, runs: Silver Peak Unity EdgeConnect → Aruba EdgeConnect → HPE Aruba Networking EdgeConnect, now serving as the SD-WAN component of a broader SASE platform.

This positioning explains why Silver Peak/EdgeConnect occupies a distinctive spot among SD-WAN vendors. Competitors include Cisco SD-WAN (Viptela), Cisco Meraki, VMware SD-WAN (formerly VeloCloud), Fortinet Secure SD-WAN, and Palo Alto Networks Prisma SD-WAN (formerly CloudGenix). What sets EdgeConnect apart is its WAN optimization heritage: it is one of the few SD-WAN platforms born from WAN optimization, with mature, tightly integrated Boost optimization and advanced path conditioning alongside rich SD-WAN policy. That lineage pays off most at high-latency or bandwidth-constrained sites, for heavy data-center-to-data-center or branch-to-data-center bulk traffic, and for legacy applications that genuinely benefit from acceleration.

Key Takeaway: Silver Peak began in 2004 as a WAN optimization vendor (NX/VX appliances), evolved its expertise into the Unity EdgeConnect SD-WAN platform around 2014–2015, and was acquired by HPE’s Aruba business in 2020 for roughly $925 million. The product was rebranded from Silver Peak Unity EdgeConnect to HPE Aruba Networking EdgeConnect and now serves as the SD-WAN foundation of HPE Aruba Networking’s SASE portfolio, distinguished by its deeply integrated WAN optimization heritage.

Chapter Summary

The wide-area network sits at the center of every multi-site organization, and for two decades MPLS defined what that network looked like. MPLS delivered reliable, predictable, SLA-backed performance, but it did so at a high cost per megabit, with slow router-by-router change management, limited use of alternative links, and a hub-and-spoke design that forced cloud traffic to be backhauled inefficiently through a central data center. As applications migrated to SaaS and IaaS, as encryption became universal, and as broadband grew cheap and fast, the mismatch between the old WAN and modern traffic patterns became impossible to ignore. Network teams faced simultaneous pressure on cost, agility, and application performance that traditional designs could not relieve all at once.

SD-WAN answers these pressures by re-architecting the WAN as a centrally orchestrated software overlay. By separating policy from transport, it becomes transport-independent: it rides any mix of MPLS, broadband, DIA, and LTE/5G, treats them as interchangeable measured circuits, and uses them active-active. A centralized orchestrator turns network management from per-device CLI work into one-touch policy changes and zero-touch provisioning, while application-aware routing steers each flow by its real-time SLA — moving voice off a degrading link before users notice, sending backups over the cheapest path, and breaking SaaS traffic out locally instead of backhauling it. The net result for organizations with many sites is typically more bandwidth, more agility, and lower total cost of ownership.

Silver Peak’s story is the story of one company riding this entire wave. Founded in 2004 as a WAN optimization vendor with its NX hardware and VX virtual appliances, it used deduplication, compression, and TCP acceleration to wring performance out of expensive MPLS. When traffic shifted to the cloud, Silver Peak reused that expertise to build the Unity EdgeConnect SD-WAN platform — pairing EdgeConnect edge appliances with the Unity Orchestrator and offering its legacy optimization as the optional Unity Boost license. HPE’s Aruba business acquired Silver Peak in 2020 for roughly $925 million, rebranding the line through Aruba EdgeConnect to today’s HPE Aruba Networking EdgeConnect and folding it into the HPE Aruba Networking SASE portfolio alongside the Axis-Security-derived SSE. The chapters ahead build on this foundation, examining how the platform actually works, the hardware and virtual models available, how it is licensed, and how it is managed and orchestrated.

Key Terms

Chapter 2: Core Architecture and Components

Learning Objectives

By the end of this chapter, you will be able to:

• Describe the EdgeConnect appliance, the Orchestrator, and the Unity Cloud Portal, and explain how these three components interact to form a managed SD-WAN.
• Explain the distinct roles of the management plane, the control plane, and the data plane in the Silver Peak (now Aruba/HPE EdgeConnect) fabric, and predict how the system behaves when one of them is disrupted.
• Diagram a basic Silver Peak SD-WAN topology, distinguishing the physical underlay transports from the logical overlays built on top of them.

In Chapter 1 you learned why SD-WAN exists and where Silver Peak fits in the market. This chapter opens the hood. We will look at the three building blocks of every EdgeConnect deployment, how responsibility is divided across three “planes” of operation, and how the system separates the physical circuits you pay your carrier for from the intelligent virtual network that runs on top of them.

The Three Pillars

Every Silver Peak EdgeConnect SD-WAN deployment rests on three logical components. Get these clear and the rest of the architecture falls into place. The three pillars are the EdgeConnect appliance (the device at each site that actually moves traffic), the Orchestrator (the central brain where administrators define policy and watch the network), and the Unity Cloud Portal (the cloud service that handles onboarding and licensing) [Source: https://www.arubanetworks.com/products/sd-wan/].

A useful analogy: think of a national delivery company. The EdgeConnect appliances are the local depots in each city that receive and dispatch packages. The Orchestrator is the head-office operations center that sets the rules — which routes to use, how fast each package class must be delivered, who is allowed to ship what. The Unity Cloud Portal is the corporate registration desk where a new depot is enrolled, given its credentials, and told which operations center it reports to. Once a depot is up and running, it talks to the operations center every day; it only revisits the registration desk for licensing and account matters.

EdgeConnect Appliances: Physical, Virtual, and Cloud

The EdgeConnect appliance is the SD-WAN endpoint deployed at every location in the fabric. It comes in three form factors so that the same logical role can be filled anywhere [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect/]:

• Physical appliances — purpose-built hardware shipped to branches, retail stores, and data centers.
• Virtual appliances — software images that run on a hypervisor (VMware ESXi, KVM, Microsoft Hyper-V) on a customer’s own server.
• Cloud appliances — images deployed inside public-cloud infrastructure such as AWS, Microsoft Azure, or Google Cloud Platform, so that cloud workloads join the same fabric as physical sites.

Regardless of form factor, the appliance performs the same core jobs:

• Terminates WAN underlay links. Each appliance physically connects to one or more transports — an MPLS circuit, a broadband Internet line, an LTE/5G modem — and treats each as a usable path.
• Builds encrypted overlay tunnels. It establishes IPsec tunnels to other EdgeConnect appliances, creating the secure virtual network described later in this chapter.
• Runs local routing. It behaves as the site’s router, supporting static routes plus dynamic protocols such as OSPF and BGP to exchange routes with the LAN and the rest of the network.
• Enforces intent-based policy. It applies the application-aware rules pushed down from the Orchestrator, classifying traffic with deep packet inspection (DPI) and steering each flow onto the best available path.
• Performs path conditioning and optimization. It continuously measures loss, latency, and jitter on each path, and can “heal” a degraded link using Forward Error Correction (FEC), packet order correction, and jitter buffering. With the optional Boost license it adds WAN optimization — TCP acceleration, deduplication, and compression.

Example. A retail chain ships a physical EdgeConnect to a new store. A technician racks it, plugs in the broadband line and an LTE backup, and powers it on. No CLI configuration is needed on site — the appliance discovers its policy automatically (covered in the next section). Meanwhile, the same company runs a virtual EdgeConnect inside its Azure tenant so that cloud-hosted applications sit directly on the fabric. Both are the same logical component playing the same role.

Orchestrator: The Management Plane (Formerly GMS)

The Orchestrator is the centralized management system for the entire EdgeConnect fabric — the “single pane of glass” through which administrators configure, monitor, and troubleshoot every appliance [Source: https://www.arubanetworks.com/techdocs/sdwan-docs/]. It was originally called the Global Management System, or GMS, under the Silver Peak brand; after the HPE/Aruba acquisition the product was renamed Orchestrator. You will still encounter “GMS” in older documentation, training materials, and command output, so it is worth remembering the two names refer to the same thing.

The Orchestrator can be deployed on-premises as a virtual machine, in cloud IaaS, or consumed as a vendor-hosted SaaS instance reached through the Unity Cloud Portal. Its responsibilities include:

• Intent-based policy management — defining Business Intent Overlays (BIOs) that group applications into classes (voice, video, SaaS, ERP, backup, guest) and map each class to the paths, SLAs, QoS, and security it should receive. The Orchestrator translates these high-level intents into the low-level device configuration the appliances actually run.
• Zero-touch provisioning (ZTP) — bringing new appliances online with no manual CLI work at the site.
• Monitoring and analytics — real-time and historical views of tunnel status, application performance, bandwidth use, and SLA compliance, with flow browsers, alarm dashboards, and map views.
• Lifecycle management — centralized software image management, configuration templates, backup and restore, role-based access control (RBAC) and multi-tenancy for large organizations and managed service providers (MSPs).
• Integrations — Syslog, SNMP, and REST APIs that connect the fabric to external NMS, SIEM, and ITSM tools.

A defining property — and one of the most important facts in this chapter — is that the Orchestrator is not in the data path. It configures and monitors the appliances, but user packets never flow through it. We will return to the consequences of this in the next section.

Unity Cloud Portal: Onboarding and Cloud Services

The Unity Cloud Portal is a vendor-operated, cloud-hosted service that acts as the “phone-home” front end for the fabric [Source: https://www.arubanetworks.com/products/sd-wan/]. Its primary jobs are:

• Zero-touch onboarding. When a brand-new EdgeConnect first reaches the Internet, it contacts the Cloud Portal, authenticates with its serial number and activation token, and the portal returns the appliance’s license status and the address of the Orchestrator it should join. The appliance then opens a secure management session directly with that Orchestrator.
• License and subscription management. The portal maintains the central pool of appliance licenses, Boost licenses, and feature bundles, lets administrators see which devices are licensed, and allows entitlements to be transferred between appliances when hardware is replaced or moved.
• Orchestrator-as-a-Service access. For SaaS deployments, administrators log into the Cloud Portal to reach their cloud-hosted Orchestrator instance(s), with SSO, multi-tenant separation, and regional instance selection.

The key thing to internalize is that the Cloud Portal is mostly involved at onboarding and licensing time. Once an appliance has been adopted by its Orchestrator, day-to-day configuration and telemetry flow directly between the appliance and the Orchestrator — not through the Cloud Portal.

Figure 2.1: The Three Pillars and Their Interactions. A diagram showing three boxes — EdgeConnect appliances (bottom, multiple sites), Orchestrator (top center), and Unity Cloud Portal (top right, in a cloud). Arrows show: appliance → Cloud Portal labeled “1. phone home for license + Orchestrator address”; appliance ↔ Orchestrator labeled “2. config down, telemetry up (ongoing)”; Cloud Portal ↔ Orchestrator labeled “appliance-to-Orchestrator mapping, licensing.”

flowchart LR
    subgraph Sites["Customer Sites"]
        EC1["EdgeConnect Appliance: Branch A"]
        EC2["EdgeConnect Appliance: Branch B"]
    end
    ORCH["Orchestrator: central management plane (formerly GMS)"]
    PORTAL["Unity Cloud Portal: cloud onboarding and licensing"]

    EC1 -->|"1. Phone home for license + Orchestrator address"| PORTAL
    EC2 -->|"1. Phone home for license + Orchestrator address"| PORTAL
    EC1 <-->|"2. Config down, telemetry up (ongoing)"| ORCH
    EC2 <-->|"2. Config down, telemetry up (ongoing)"| ORCH
    PORTAL <-->|"Appliance-to-Orchestrator mapping, licensing"| ORCH

Key Takeaway: Silver Peak EdgeConnect rests on three pillars — the EdgeConnect appliance (the per-site device that forwards traffic), the Orchestrator (the central management system, formerly GMS, that defines policy and monitors the fabric but never carries user data), and the Unity Cloud Portal (the cloud service that onboards new appliances and manages licensing). The Cloud Portal matters at enrollment; the Orchestrator matters every day; the appliance does the real work.

Planes of Operation

Network architectures are commonly described in terms of three planes — management, control, and data. The power of this model is that it separates who decides what from what actually moves packets. In EdgeConnect each plane lives in a specific place, and understanding that placement tells you exactly how the network will behave under failure [Source: https://www.arubanetworks.com/techdocs/sdwan-docs/].

Management, Control, and Data Planes Defined

The management plane is where the network is configured, monitored, and maintained. In EdgeConnect it lives almost entirely in the Orchestrator: defining policy, running ZTP, collecting analytics, managing software images, and enforcing RBAC. Each appliance also exposes a local management interface (web UI, CLI, API) for bootstrap and emergency access, but the system of record is the Orchestrator.

The control plane is where decisions about how to reach destinations and which path to use are made. In EdgeConnect the control plane is distributed across the appliances. Each appliance discovers and maintains its overlay tunnels, runs routing protocols (BGP, OSPF, static) to learn and advertise routes, continuously measures the quality of each path, and selects paths for each traffic class in real time. The Orchestrator shapes control-plane behavior — it defines the topology, the overlays, and the SLA thresholds, and distributes that policy and route/subnet information to the appliances — but it does not make the packet-by-packet path decision. That happens locally, at the edge.

The data plane is where user traffic is actually forwarded. It runs only on the appliances. Every packet arriving on a LAN interface is classified by application, user, and zone; mapped to a Business Intent Overlay; steered onto one or more tunnels; optionally optimized; and encrypted for transit. The receiving appliance reverses the process. As noted earlier, the Orchestrator is never in the data path — it sees summarized flow records and statistics, never the user packets themselves.

The table below summarizes the division of labor.

How Appliances Register and Receive Policy

Bringing a new branch online ties all three planes together. The sequence runs as follows:

1. Management plane — bootstrap and ZTP. The new EdgeConnect boots, obtains an IP address (typically via DHCP), and phones home to the Cloud Portal. After authenticating, it learns its Orchestrator address and opens a secure management session. The Orchestrator authenticates the appliance, assigns it a site name and role, and pushes a configuration template plus the site-specific policy — Business Intent Overlays, segmentation, and security rules.
2. Control plane — build overlays and learn routes. Using that pushed policy, the appliance forms IPsec tunnels to its hub(s) and mesh peers across each available underlay, establishes BGP/OSPF sessions, learns local LAN prefixes, advertises them into the fabric, and installs remote prefixes in its routing table.
3. Data plane — forward traffic. Users generate traffic; the appliance classifies each flow, applies the relevant overlay policy, and forwards packets onto the chosen path(s). The remote appliance decapsulates, reorders if necessary, and delivers to its LAN.

The most important architectural consequence of this separation is resilience through independence. Because the management plane is out of the data path, if the Orchestrator or Cloud Portal becomes unreachable, the existing control and data planes keep operating on last-known policy. You lose the ability to push new configuration and to see fresh analytics, but traffic keeps flowing and the appliances keep making local path decisions.

Example — diagnosing a “down” site. Suppose users at a branch report everything works fine, yet the Orchestrator dashboard shows the appliance as offline or stale. Because the data plane is independent of the management plane, this pattern points to a management-path problem — a firewall rule, proxy, DNS issue, or an NTP/certificate mismatch breaking the TLS session to the Orchestrator — not a traffic-forwarding problem. The recommended troubleshooting order follows the planes: management plane first (does the Orchestrator see the device?), then control plane (routing and tunnel state), then data plane (QoS, optimization, loss).

Zero-Touch Provisioning Flow

Zero-touch provisioning (ZTP) is the process that lets a non-technical person at a remote site stand up an appliance without ever touching a command line. The orchestrated flow is:

1. The appliance is shipped to the site preloaded with factory defaults and (optionally) an activation key.
2. On site, someone racks, cables, and powers it on, and ensures it can reach the Internet.
3. The appliance contacts the Unity Cloud Portal, authenticating with its serial number / activation token.
4. The Cloud Portal validates the license and returns the target Orchestrator address.
5. The appliance opens a secure session to that Orchestrator, which pushes the full configuration.
6. The appliance builds its tunnels and begins forwarding — fully operational.

When ZTP fails, the cause is usually on one of two sides. On the Cloud Portal / ZTP side: the device was never registered or licensed, the activation key is wrong or missing, DNS/HTTPS to the portal is blocked, or a clock/NTP problem is causing TLS certificate failures. On the Orchestrator side: the Orchestrator is unreachable from the branch, a license or capacity limit has been hit, or the appliance is mapped to the wrong Orchestrator. Knowing which plane and which component owns each step turns a vague “it won’t come up” into a targeted investigation.

Figure 2.2: Zero-Touch Provisioning Sequence. A left-to-right sequence diagram with four actors — Appliance, Internet/DHCP, Cloud Portal, Orchestrator — showing the numbered message exchange from power-on through “fully operational,” with the license check at the Cloud Portal and the configuration push from the Orchestrator highlighted.

sequenceDiagram
    participant A as EdgeConnect Appliance
    participant N as Internet / DHCP
    participant P as Unity Cloud Portal
    participant O as Orchestrator

    A->>N: 1. Power on, request IP address (DHCP)
    N-->>A: Assign IP, gateway, DNS
    A->>P: 2. Phone home (serial number + activation token)
    P->>P: 3. Validate license and entitlement
    P-->>A: 4. Return target Orchestrator address
    A->>O: 5. Open secure management session
    O-->>A: 6. Push full configuration (BIOs, segmentation, security)
    Note over A,O: Appliance builds tunnels and begins forwarding (fully operational)

Key Takeaway: EdgeConnect cleanly separates the management plane (Orchestrator — configure and monitor), the control plane (distributed across appliances — decide paths and routes from Orchestrator-supplied policy), and the data plane (appliances only — forward and optimize packets). Because management is out of the data path, an Orchestrator or Cloud Portal outage stops new configuration and visibility but never stops existing traffic — and that fact dictates the order in which you troubleshoot.

Overlays and Underlays

The final architectural idea in this chapter is the separation of the physical network you rent from your carriers from the intelligent virtual network EdgeConnect builds on top of it. These two layers are the underlay and the overlay [Source: https://www.arubanetworks.com/techdocs/sdwan-docs/].

Underlay Transports: MPLS, Broadband, and LTE

The underlay is the real, physical/IP network that provides basic reachability between appliances. It is everything below SD-WAN:

• Transport types — MPLS circuits, broadband Internet links, private Ethernet, LTE/5G cellular, and even satellite.
• The IP layer — the WAN interface addresses on each appliance and whatever routing or provisioning exists with the ISP or upstream device.
• Measurable characteristics — bandwidth, latency, jitter, loss, MTU, and (for MPLS) committed information rate.

Two facts about the underlay are essential. First, EdgeConnect does not change how the underlay works; it uses whatever IP connectivity exists. Second, if underlay reachability between two appliances is broken — by routing, an ACL, NAT, or a blocked port — overlay tunnels cannot form over that path. The underlay sets the raw performance envelope; SD-WAN can steer around bad links and heal them somewhat, but it cannot create bandwidth that the underlay does not provide.

A common gotcha lives here: EdgeConnect tunnels use IPsec, so underlay firewalls and NAT devices must permit the required traffic (UDP 4500 and related IPsec packets) between WAN IP addresses, or the Orchestrator cannot auto-build tunnels.

Business Intent Overlays as Logical Fabrics

The overlay is the virtual SD-WAN network built on top of the underlay: encrypted IPsec tunnels plus the logical topologies and policies that ride them. The central policy abstraction is the Business Intent Overlay (BIO).

A BIO answers a single question: given a certain type of traffic, how should the fabric treat it? Each BIO typically defines:

1. Traffic classification — which applications (via DPI), subnets, ports, or user groups it matches.
2. Topology — any-to-any (full mesh), hub-and-spoke, or a regional mesh.
3. Path preferences and SLA thresholds — which transports to prefer, which are allowed, and the maximum latency/jitter/loss before the policy switches paths or applies FEC and packet duplication.
4. QoS treatment — DSCP marking, prioritization, and bandwidth guarantees.
5. Security and segmentation — the zone the traffic belongs to and how it may cross zones or break out to the Internet.

A crucial subtlety: multiple BIOs share the same physical tunnels. A BIO is not a separate IPsec tunnel — it is a logical overlay distinguished by policy and segmentation. The “Voice” BIO and the “Backup” BIO may both ride the same Internet-to-Internet tunnel; the fabric keeps them separate through policy, QoS, and zones, not through separate plumbing. This is why a BIO is best understood as a logical fabric: all traffic matching it experiences the same topology, path rules, QoS, and security posture, even though it physically shares tunnels with every other BIO.

The whole system — every appliance, every tunnel, and every BIO — is collectively the SD-WAN fabric: a single, transport-independent virtual WAN with centralized control and distributed enforcement. You set intent once in the Orchestrator; each appliance enforces it locally and steers flows in real time as link conditions change.

The analogy worth remembering: the underlay is the roads (MPLS, Internet, LTE), and the overlay is the set of virtual lanes painted on top of those roads, each lane carrying a different class of traffic under different rules.

Fabric Tunnels Between EdgeConnect Nodes

A tunnel is an IPsec-encrypted overlay connection between two appliances, anchored on a specific local WAN interface and a specific remote WAN interface. Typically there is one tunnel per transport pair between any two sites — MPLS↔MPLS, Internet↔Internet, LTE↔LTE — with cross-transport tunnels added if configured. Tunnels are auto-discovered and auto-built by the Orchestrator once sites and WAN links are defined, and then continuously probed for latency, jitter, loss, and — for voice — a Mean Opinion Score (MOS) estimate.

Tunnel health and the underlay are linked but distinct. If the underlay loses IP connectivity on a path (a provider outage, mis-routing, or a firewall blocking IPsec), the tunnel goes down. If the underlay is up but degraded, the tunnel stays up but is flagged as not meeting SLA, which lets the fabric prefer a healthier tunnel for sensitive traffic.

End-to-end example. Consider HQ (with a 50 Mbps MPLS circuit and a 200 Mbps broadband link) and Branch A (10 Mbps MPLS, 100 Mbps broadband). Once the WAN interfaces are defined, the Orchestrator auto-builds an MPLS↔MPLS tunnel (say ~20 ms, under 0.1% loss) and an Internet↔Internet tunnel (~40 ms, occasional 1% loss). A “Real-Time Voice” BIO prefers MPLS while latency stays under 50 ms and loss under 0.5%, with the Internet tunnel as backup using packet duplication. When a voice packet arrives at Branch A, it is classified as voice, the BIO selects the healthy MPLS tunnel, and HQ delivers it to the PBX. If MPLS later starts dropping packets, the appliance’s local control plane detects the SLA violation and shifts the flow to the Internet tunnel with packet duplication — all within the overlay, without touching a single carrier router and even if the Orchestrator happens to be unreachable at that moment.

Figure 2.3: Basic SD-WAN Topology with Overlays and Underlays. A topology diagram showing HQ and Branch A, each with two WAN interfaces (MPLS and broadband) drawn as the underlay layer at the bottom. Above them, two parallel IPsec tunnels (MPLS↔MPLS and Internet↔Internet) form the overlay. Color-coded logical flows (“Voice,” “Backup,” “Guest”) ride across the shared tunnels to illustrate that multiple BIOs share the same physical plumbing.

flowchart TB
    subgraph Overlay["Overlay: logical Business Intent Overlays (Voice, Backup, Guest)"]
        BIO["BIOs share the same tunnels, separated by policy, QoS, and zones"]
    end

    subgraph Tunnels["Overlay Tunnels: IPsec, auto-built and probed"]
        T1["MPLS to MPLS tunnel (~20 ms, low loss)"]
        T2["Internet to Internet tunnel (~40 ms, occasional loss)"]
    end

    subgraph HQ["HQ EdgeConnect"]
        HQ_MPLS["WAN: MPLS 50 Mbps"]
        HQ_BB["WAN: Broadband 200 Mbps"]
    end

    subgraph BR["Branch A EdgeConnect"]
        BR_MPLS["WAN: MPLS 10 Mbps"]
        BR_BB["WAN: Broadband 100 Mbps"]
    end

    BIO --> T1
    BIO --> T2
    T1 --- HQ_MPLS
    T1 --- BR_MPLS
    T2 --- HQ_BB
    T2 --- BR_BB

Key Takeaway: The underlay is the physical transport (MPLS, broadband, LTE) that provides raw reachability; the overlay is the encrypted IPsec fabric built on top of it. Tunnels are per-transport IPsec connections the Orchestrator auto-builds and continuously probes, while Business Intent Overlays are logical fabrics that map each traffic class to paths, QoS, and security — many BIOs sharing the same tunnels. Fix path behavior by changing the BIO, not the underlay.

Chapter Summary

This chapter dissected the core architecture of Silver Peak EdgeConnect SD-WAN. The fabric rests on three pillars: the EdgeConnect appliance, available as physical, virtual, or cloud form factors, which terminates underlay links, builds encrypted tunnels, routes locally, and enforces intent-based policy with optional Boost optimization; the Orchestrator (formerly GMS), the single-pane-of-glass management system that defines Business Intent Overlays, runs zero-touch provisioning, and monitors the fabric while staying out of the data path; and the Unity Cloud Portal, the cloud service that onboards new appliances and manages licensing.

Responsibility is divided across three planes. The management plane lives in the Orchestrator. The control plane is distributed across the appliances, which make real-time path decisions from Orchestrator-supplied policy. The data plane runs only on the appliances and carries every user packet. Because management sits out of the data path, an Orchestrator or Cloud Portal outage stops new configuration and visibility but never stops existing traffic — a principle that also dictates the management-then-control-then-data troubleshooting order. Zero-touch provisioning ties the planes together, letting an appliance phone home to the Cloud Portal, learn its Orchestrator, receive policy, and begin forwarding with no on-site CLI work.

Finally, EdgeConnect separates the underlay — the physical MPLS, broadband, and LTE transports that provide raw reachability — from the overlay, the virtual network of IPsec tunnels and Business Intent Overlays. Tunnels are per-transport connections the Orchestrator auto-builds and probes; BIOs are logical fabrics that map traffic classes to paths, QoS, and security while sharing the same physical tunnels. Together, all appliances, tunnels, and BIOs form the SD-WAN fabric: one transport-independent virtual WAN with centralized control and distributed enforcement. With these components and planes in hand, you are ready to examine Silver Peak’s specific appliance models and deployment options in the chapters that follow.

Key Terms

Chapter 3: How It Works: Tunnels, Path Selection, and Dynamic Path Control

The first two chapters explained why SD-WAN exists and what Silver Peak EdgeConnect is. This chapter opens the hood. We trace a packet from the moment two appliances discover each other, through the encrypted tunnels they build, to the real-time decisions that pick which tunnel carries which packet — and how the system rescues a flow when a link quietly starts to fail. By the end you should be able to explain not just that EdgeConnect “self-heals,” but the specific mechanisms that make that claim true.

Learning Objectives

After completing this chapter, you will be able to:

• Explain how EdgeConnect builds IPsec tunnels and forms the SD-WAN fabric, including auto-discovery, automatic tunnel creation, and the common topology options.
• Describe Dynamic Path Control and how per-packet and per-flow steering decisions are made, including the role of Business Intent Overlays.
• Explain how the system measures link quality (loss, latency, jitter) and reacts to brownouts and blackouts with subsecond failover.
• Describe how tunnel bonding, Forward Error Correction (FEC), and Packet Order Correction (POC) work together to mask WAN impairments from applications.

Building the Fabric

Before EdgeConnect can make any clever forwarding decisions, it needs something to forward across. That “something” is the SD-WAN fabric: a web of encrypted tunnels connecting your sites over whatever physical circuits you happen to own.

Three layers: underlay, fabric, and overlays

It helps to picture the architecture as three stacked layers [Source: https://www.advizex.com/post/hpe-aruba-edgeconnect-a-technical-deep-dive]:

A useful analogy: the underlay is the set of physical roads (a toll highway, a free surface street, a backup gravel road). The fabric is the set of armored delivery routes you’ve pre-mapped on top of those roads. The overlays are your shipping policies — “perishable goods take the fastest clean route; bulk freight takes whatever is cheapest.” Dynamic Path Control, which we meet in the next section, is the dispatcher who reads the policy and assigns each shipment to a route in real time.

An IPsec tunnel is an encrypted, authenticated connection between two appliances that protects traffic as it crosses an untrusted network like the public Internet. EdgeConnect builds these tunnels automatically and keeps them up continuously, which — as we’ll see — is the secret behind its fast failover.

Auto-discovery and automatic tunnel creation

In a traditional WAN, an engineer configures every tunnel by hand: define endpoints, agree on encryption parameters, configure NAT traversal, repeat for every site pair. For a 100-site mesh that is thousands of tunnels and a configuration nightmare. EdgeConnect replaces this with orchestration.

The process runs roughly as follows [Source: https://www.lanoasis.kr/resource/file/sdwan/05_EdgeConnect_Solution_Enterprise_(Data_Sheet).pdf]:

1. Site definition and WAN uplinks. Each EdgeConnect appliance registers with Orchestrator (the central management plane). You declare each WAN interface, assign it a label (MPLS, INET, LTE), and set its addressing — static IP, DHCP, or behind NAT.
2. Topology selection. In Orchestrator you choose a topology — full mesh, hub-and-spoke, or regional hubs. Orchestrator then computes which sites should tunnel to which others, over which labels. This is the auto-discovery step: you express intent (“all branches mesh with each other”), and Orchestrator figures out the individual peerings.
3. Automatic IPsec tunnel creation. For each site pair and each allowed WAN label, Orchestrator pushes the local and remote endpoints, the IKE/IPsec parameters (version, encryption, authentication), and NAT-traversal settings to the appliances. The appliances initiate IKE negotiation, build the IPsec security associations (SAs), bring the tunnels up, and register each one as a logical “WAN path” in the fabric.
4. Tunnel health monitoring. Every tunnel is then continuously monitored for latency, loss, jitter, and availability. This live picture is what feeds path selection.
5. Route distribution. LAN networks learned via static routes, OSPF, or BGP are advertised across the fabric. Crucially, the fabric becomes the transport, but it is DPC — not the routing protocol — that decides which tunnel carries which flow.

The end result is that between any two sites you typically have multiple parallel IPsec tunnels, one per underlay, all up at once and all monitored. A branch with MPLS and Internet has two tunnels to its hub, both live, both measured, both ready.

Figure 3.1: The three-layer EdgeConnect model. A horizontal stack diagram: at the bottom, three labeled circuit icons (MPLS, INET, LTE) representing the underlay; in the middle, two parallel encrypted-tunnel lines connecting a Branch appliance to a Hub appliance, representing the fabric; at the top, two colored bands (“RealTime” and “BestEffort”) representing Business Intent Overlays that ride across the fabric.

graph TD
    subgraph Overlays["Overlays (Business Intent)"]
        RT["RealTime overlay (voice/video)"]
        BE["BestEffort overlay (backups)"]
    end
    subgraph Fabric["Fabric (IPsec tunnels)"]
        Branch["Branch appliance"]
        Hub["Hub appliance"]
    end
    subgraph Underlay["Underlay (physical circuits)"]
        MPLS["MPLS circuit"]
        INET["INET broadband circuit"]
        LTE["LTE/5G circuit"]
    end

    RT -.rides across.-> Branch
    BE -.rides across.-> Branch
    Branch ==IPsec tunnel over MPLS==> Hub
    Branch ==IPsec tunnel over INET==> Hub
    Branch -.runs on.-> MPLS
    Branch -.runs on.-> INET
    Branch -.runs on.-> LTE

Topology options: hub-and-spoke, mesh, and regional mesh

Orchestrator supports several topology models, and the right one depends on traffic patterns and scale:

Consider a retailer with 200 stores and two data centers. A full mesh would mean every store maintaining tunnels to all 199 others — administratively heavy and rarely justified, since stores mostly talk to the data centers, not to each other. Hub-and-spoke keeps tunnel counts manageable. But if those stores also run a lot of voice between regional offices, a regional mesh lets nearby sites talk directly while still controlling the overall tunnel count.

Key Takeaway: EdgeConnect organizes the network into underlay (physical circuits), fabric (automatically built IPsec tunnels — typically one per underlay per peer), and overlays (policy). Orchestrator auto-discovers peerings from your chosen topology and builds the tunnels for you. Because tunnels over every transport stay up continuously, the system is always ready to switch paths without renegotiating anything.

Dynamic Path Control (DPC)

With the fabric in place, the question becomes: of the several tunnels available between two sites, which one should carry a given packet right now? Answering that question continuously is the job of Dynamic Path Control — the engine that matches application traffic to policy and steers it onto the tunnel that currently meets the application’s needs [Source: https://www.thenetworkdna.com/2022/12/aruba-sd-wan-dynamic-path-control.html].

Business Intent Overlays: expressing what you want

DPC does not steer traffic arbitrarily; it steers according to Business Intent Overlays (BIOs). A BIO is a policy statement that reads, in effect: “For traffic of this type, use these transports, with this behavior.” Each BIO specifies [Source: https://www.thenetworkdna.com/2022/12/aruba-sd-wan-dynamic-path-control.html]:

• What traffic matches — by Layer-7 application ID, FQDN, IP prefixes, ports, subnets, DSCP markings, VLANs, or user groups.
• Path preferences — which WAN labels are allowed, their priority order, primary/secondary/backup roles, and whether to break out to the Internet locally or backhaul through a hub.
• SLA thresholds — maximum acceptable latency, jitter, and loss, plus how aggressively to react to a degraded path.
• Forwarding behavior — per-flow versus per-packet, whether to apply FEC, packet duplication, retransmission, and QoS marking.

The power of this model is that you describe business intent once (“voice must stay under 80 ms and under 1% loss, preferring MPLS”), and DPC enforces it everywhere, automatically choosing tunnels to satisfy it.

Path conditioning and link monitoring

To make good decisions, DPC needs accurate, current data about every tunnel. It collects this by sending frequent, timestamped health-check packets between peers and by reading sequence numbers in the overlay traffic itself [Source: http://media.techtarget.com/Webcasts/2016/07/72616_SilverPeak/media/Broadband_QoS_with_SilverPeak_Whitepaper.pdf]. We cover the measurement math in detail in the brownout section below; for now, the key point is that DPC maintains a real-time, per-tunnel, per-direction picture of loss, latency, and jitter, and continuously asks: does this tunnel still meet each overlay’s SLA?

Per-flow versus per-packet steering

This is one of the most important distinctions in EdgeConnect, so it’s worth slowing down.

Per-flow steering (the default). A flow is identified by its 5-tuple: source IP, destination IP, source port, destination port, and protocol. With per-flow steering, DPC filters out tunnels not allowed by the BIO or violating its SLA, ranks the survivors by priority and current health, then hashes each new flow to the single best tunnel and pins it there until that tunnel fails or breaks SLA [Source: https://www.thenetworkdna.com/2022/12/aruba-sd-wan-dynamic-path-control.html]. Because every packet of the flow takes the same path, packets arrive in order — which is exactly what TCP and most applications prefer.

Example. A branch has MPLS and Internet. A VoIP call matches the “RealTime” BIO (SLA < 80 ms, < 1% loss) and is pinned to MPLS because MPLS meets the SLA. Meanwhile a large file upload matches “BestEffort” and is hashed onto the Internet link. Two flows, two different tunnels, each chosen by policy.

Per-packet steering (tunnel bonding). Here DPC stripes the packets of a single flow across multiple tunnels at once. This aggregates bandwidth and adds resiliency, but because packets now travel different paths with different latencies, they can arrive out of order — so the receiver must resequence them. We treat tunnel bonding in depth in the next section.

Figure 3.4: The Dynamic Path Control decision flow. A flowchart: a new flow is matched to a Business Intent Overlay, candidate tunnels are filtered to those allowed and meeting SLA (measured loss, latency, jitter), survivors are ranked, and the flow is steered per-flow or per-packet; a brownout or blackout on the chosen path loops back to re-steer the flow.

flowchart TD
    Start(["New flow arrives"]) --> Match["Match flow to Business Intent Overlay"]
    Match --> Measure["Read live tunnel metrics: loss, latency, jitter"]
    Measure --> Filter{"Tunnels allowed by BIO and meeting SLA?"}
    Filter -->|"None"| Best["Fall back to least-degraded allowed tunnel"]
    Filter -->|"One or more"| Rank["Rank survivors by priority and health"]
    Rank --> Mode{"Bonding mode for overlay?"}
    Best --> Steer
    Mode -->|"Per-flow (default)"| Steer["Pin flow to single best tunnel"]
    Mode -->|"Per-packet (bonding)"| Stripe["Stripe packets across tunnels"]
    Steer --> Monitor["Monitor chosen path continuously"]
    Stripe --> Monitor
    Monitor --> Health{"Path healthy?"}
    Health -->|"Yes"| Monitor
    Health -->|"Brownout or blackout"| Measure

Brownout and blackout detection and failover

A link can fail in two very different ways, and EdgeConnect distinguishes them [Source: https://www.silver-peak.com/sites/default/files/infoctr/packet-loss-torture-test-041417.pdf]:

• A blackout is a hard failure: probes stop returning entirely, the tunnel is declared down, and it is immediately removed from the candidate set for any overlay using it.
• A brownout is the insidious case: the tunnel is still up — probes and traffic pass — but one or more metrics breach the SLA (say, loss climbs above 2% or latency past 150 ms). The path is marked degraded, not down. Brownouts can even be direction-specific.

Each path therefore lives in one of three states — Healthy, Degraded, or Down — and DPC re-steers traffic accordingly. New flows are immediately directed to a healthier transport. Existing flows are handled per policy: real-time flows like voice can migrate almost instantly (sometimes with a brief burst of packet duplication for a hitless switch), while long-lived TCP sessions may be left in place to avoid mid-session disruption unless the degradation is severe.

Figure 3.5: Path state machine — Healthy, Degraded, and Down. A state diagram: a tunnel starts Healthy; an SLA breach on loss, latency, or jitter transitions it to Degraded (brownout); probes ceasing transitions it to Down (blackout); recovery plus a hold-down timer returns it to Healthy. Each state drives a different re-steering action.

stateDiagram-v2
    [*] --> Healthy
    Healthy --> Degraded: SLA breached (brownout)
    Healthy --> Down: Probes stop (blackout)
    Degraded --> Down: Probes stop
    Degraded --> Healthy: Metrics back within SLA + hold-down elapsed
    Down --> Healthy: Probes return + hold-down elapsed

    Healthy: Healthy\nCarries flows normally
    Degraded: Degraded\nNew flows re-steered; voice migrates
    Down: Down\nRemoved from candidate set

Key Takeaway: DPC matches each flow to a Business Intent Overlay, filters tunnels to those allowed and meeting the SLA, and steers traffic onto the best path. Per-flow steering (the default) pins a flow to one tunnel to preserve order; per-packet steering (tunnel bonding) spreads packets across tunnels for bandwidth and resiliency. DPC tells a hard blackout apart from a degraded brownout and re-steers traffic for both.

Tunnel Bonding and Resiliency

The previous section introduced per-packet steering by name. This section explains the machinery that makes it work — and that lets EdgeConnect deliver what Miercom and Silver Peak’s own testing call “carrier-grade” quality even over messy broadband.

Tunnel bonding policy modes

Tunnel bonding is EdgeConnect’s term for using multiple IPsec tunnels together for a single overlay, on a per-packet basis [Source: http://media.techtarget.com/Webcasts/2016/07/72616_SilverPeak/media/Broadband_QoS_with_SilverPeak_Whitepaper.pdf]. The bonding policy you choose for an overlay decides what goal the bonding serves:

The trade-offs are real. Striping packets across links of different latency increases the chance of reordering, adds buffering delay at the receiver, and the parity/duplication adds bandwidth overhead. So latency-sensitive, reorder-fragile traffic is usually left on per-flow steering with a single stable path, while bonding is reserved for flows that genuinely benefit.

Forward Error Correction (FEC)

Forward Error Correction (FEC) trades a little extra bandwidth for a lot of reliability. The sending appliance groups outbound packets into blocks, computes one or more redundant parity packets for each block, and transmits the parity alongside the originals — in parallel with the data stream, so the receiver can reconstruct a lost packet without waiting for a retransmission [Source: https://www.silver-peak.com/sites/default/files/infoctr/silver-peak-solution-brief-performance-matters.pdf].

Mechanism (illustrative). Take four data packets D1–D4 and compute one parity packet P (think XOR of the four). Transmit D1, D2, D3, D4, P. If any single Dx is lost but P and the other three arrive, the receiver rebuilds the missing packet from the parity — no retransmission, no TCP slow-start penalty. (A simple 4+1 scheme cannot recover two losses in the same block; that’s why ratios are adjustable, e.g., 4+1, 8+2.) [Source: https://www.thenetworkdna.com/2022/12/aruba-edgeconnect-path-conditioning.html]

EdgeConnect makes this adaptive: it raises the FEC ratio when loss is high and lowers it when the link is clean, minimizing overhead while still protecting against degradation. In Orchestrator you set minimum and maximum FEC percentages. Both sliders at 100% approximates HA-style 1:1 FEC — effectively a full parity stream on a second link, so packets lost on one path are rebuilt from parity on the other. Both sliders at 0% disables FEC for maximum efficiency. With only a single tunnel available, FEC overhead caps around 20% even if the sliders are set higher [Source: https://www.thenetworkdna.com/2022/12/aruba-edgeconnect-path-conditioning.html].

FEC pays off most on Internet, LTE, and satellite links with roughly 1–5% loss, and for real-time UDP traffic — voice, video, VDI, market feeds — where retransmission is useless because the packet would arrive too late to matter. On clean MPLS or for bulk data, you’d use little or none.

Figure 3.2: FEC reconstructing a lost packet. A sequence diagram: the sender emits D1, D2, D3, D4, and a parity packet P across the tunnel. D3 is shown being dropped mid-path (a red X). At the receiver, D1, D2, D4, and P arrive; an arrow shows P combining with the survivors to regenerate D3, which is then delivered in order to the LAN — with no retransmission request sent back.

sequenceDiagram
    participant S as Sender appliance
    participant W as WAN path
    participant R as Receiver appliance
    participant L as LAN

    S->>W: D1
    S->>W: D2
    S->>W: D3
    S->>W: D4
    S->>W: P (parity = XOR of D1..D4)
    W->>R: D1
    W->>R: D2
    Note over W: D3 dropped in transit (X)
    W->>R: D4
    W->>R: P
    Note over R: Rebuild D3 from P + D1, D2, D4
    R->>L: Deliver D1, D2, D3, D4 in order
    Note over R,L: No retransmission requested

Packet Order Correction (POC)

FEC fixes lost packets. Packet Order Correction (POC) fixes out-of-order packets, which are an unavoidable side effect of per-packet steering across links with different latencies, ISP-core ECMP, and asymmetric routing. To TCP, out-of-order delivery looks like loss: it triggers duplicate ACKs, spurious fast-retransmits, and needless congestion-window reductions — all of which crater throughput [Source: https://www.thenetworkdna.com/2022/12/aruba-edgeconnect-path-conditioning.html].

POC solves this with a resequencing buffer on the receiving appliance. EdgeConnect stamps each overlay packet with its own sequence identifier — independent of the IP or TCP sequence numbers — caches out-of-order packets, and uses a configurable, RTT-based packet reorder wait time to decide how long to wait for a late packet before giving up on it. Packets are then delivered to the LAN in correct order [Source: https://www.thenetworkdna.com/2022/12/aruba-edgeconnect-path-conditioning.html].

Example. Path A has 20 ms latency, Path B has 60 ms. The sender stripes packets 1→A, 2→B, 3→A. They arrive in the order 1, 3, 2. Without POC the LAN sees “1, 3, 2” and TCP may fast-retransmit. With POC, the receiver holds packet 3, waits briefly for 2, then delivers 1, 2, 3 in order — trading a few-to-tens of milliseconds of buffering for a clean, in-order stream.

Tuning the reorder wait time is a balance. Too short, and reordering leaks through on jittery or asymmetric links. Too long, and the added latency hurts interactive traffic. The rule of thumb: a shorter wait for voice and real-time (codecs tolerate a little loss but hate delay), a longer wait for TCP and high-throughput flows (where avoiding retransmissions matters more than a few extra milliseconds) [Source: https://www.thenetworkdna.com/2022/12/aruba-edgeconnect-path-conditioning.html].

Path Conditioning: FEC and POC together

FEC and POC together are what Silver Peak calls path conditioning — applied inside the overlay to make a messy WAN path look clean to the application [Source: https://asicmind.wordpress.com/2019/11/07/dst-silver-peak-products-and-technology/]. On a typical Internet path, loss and reordering coexist; FEC handles the loss, POC handles the reordering, and the endpoints experience something close to a private, in-order WAN.

The independent proof point comes from Miercom, whose EdgeConnect test report attributes carrier-grade quality over broadband to HA tunnel bonding plus path conditioning. In one striking result, path conditioning preserved acceptable voice MOS (Mean Opinion Score) with up to roughly 55% aggregate underlay loss — 50% loss on one link and 5% on another — because the parity stream on the second link reconstructed what the first link dropped [Source: https://miercom.com/pdf/reports/170421C.pdf] [Source: https://www.westconcomstor.com/content/dam/wcgcom/Global/CorpSite/pdfs/Silver-Peak-Unity-EdgeConnect-SD-WAN-Solution-Miercom-report-EN.pdf].

Key Takeaway: Tunnel bonding uses multiple tunnels per overlay for bandwidth aggregation or high availability. Inside the overlay, path conditioning combines FEC (rebuilds lost packets from parity, no retransmission) and POC (resequences out-of-order packets using each packet’s EdgeConnect sequence ID and a tunable reorder wait). Together they let EdgeConnect deliver clean voice and video even over links suffering severe, independently validated levels of loss.

How Subsecond Failover Actually Works

It’s worth pulling the threads together to answer a question intermediate learners often ask: how can failover possibly be subsecond? In a legacy WAN, failover means routing reconvergence — seconds to minutes. EdgeConnect avoids almost all of that work.

Measuring link quality

Failover starts with measurement. For every tunnel, in each direction, EdgeConnect continuously computes [Source: http://media.techtarget.com/Webcasts/2016/07/72616_SilverPeak/media/Broadband_QoS_with_SilverPeak_Whitepaper.pdf]:

• Latency — peers exchange timestamped keepalives at a short interval (often hundreds of milliseconds); RTT is the receive time minus the send time, kept both as a current sample and as a smoothed moving average.
• Loss — overlay packets and probes carry sequence numbers; loss percentage is the count of missing-and-not-recovered sequences over a sliding window.
• Jitter — the variation between successive RTT samples; high jitter is flagged even when average latency looks fine.

Smoothing over a sliding window is what lets DPC react quickly to real problems without flapping on momentary transients.

Why the switch is fast

Two design choices make subsecond failover possible [Source: https://www.silver-peak.com/sites/default/files/infoctr/packet-loss-torture-test-041417.pdf] [Source: https://www.lanoasis.kr/resource/file/sdwan/05_EdgeConnect_Solution_Enterprise_(Data_Sheet).pdf]:

1. Fast detection. Probes are sent very frequently — often every 200–500 ms — and a small number of consecutive misses declares a path down. Detection time is roughly the missed-probe count times the probe interval; for example, 3 misses × 300 ms ≈ 900 ms. Brownouts are caught equally fast through threshold crossings over the smoothing window.
2. Pre-built secure tunnels. Because IPsec tunnels over every transport are already up, failover requires no IKE renegotiation and no routing reconvergence. DPC simply updates the per-flow forwarding decision, and the very next packet leaves through the alternate tunnel.

For critical traffic, EdgeConnect can briefly duplicate packets on both the old and new paths during the cutover (the receiver de-duplicates and reorders), and FEC and POC mask any residual impairment — yielding a hitless or near-hitless switch. Hold-down timers then prevent the path from flapping back prematurely after it recovers.

Example. MPLS runs at 25 ms / 0% loss / 3 ms jitter; Internet at 80 ms / 0.5% loss / 8 ms jitter. The Voice SLA is latency ≤ 120 ms, loss ≤ 1%, jitter ≤ 20 ms, preferring MPLS. Voice normally rides MPLS. When MPLS develops 5% loss, EdgeConnect computes loss over the last 10–20 probes, sees 5% > 1%, and marks MPLS degraded for the voice overlay. Within a subsecond-to-low-second window, new calls move to the Internet (still within SLA) and existing calls migrate if policy allows. After a stability period, DPC moves new calls back to MPLS [Source: https://www.thenetworkdna.com/2022/12/aruba-sd-wan-dynamic-path-control.html].

The Aruba/Silver Peak Enterprise Data Sheet lists Tunnel Bonding, Path Conditioning, Load Balancing, Dynamic Path Control, and Sub-second Failover as standard EdgeConnect functions, and the “Application Performance Torture Test” report confirms that when one underlay in a bonded tunnel fails or degrades, DPC steers traffic to the remaining link(s) in less than a second [Source: https://www.silver-peak.com/sites/default/files/infoctr/packet-loss-torture-test-041417.pdf] [Source: https://www.lanoasis.kr/resource/file/sdwan/05_EdgeConnect_Solution_Enterprise_(Data_Sheet).pdf].

Figure 3.3: Subsecond failover timeline. A horizontal timeline showing voice traffic on the MPLS tunnel; at t=0 ms MPLS loss spikes to 5%; over the next ~900 ms the smoothing window crosses the SLA threshold and MPLS is marked degraded; an arrow shows new and existing calls shifting to the pre-established Internet tunnel with no renegotiation; a later marker shows MPLS recovering and a hold-down timer elapsing before traffic returns.

timeline
    title Subsecond failover of a voice flow
    Before t=0 : Voice rides MPLS (25 ms, 0% loss)
    t=0 ms : MPLS loss spikes to 5%
    t=0 to 900 ms : Smoothing window crosses 1% SLA threshold : MPLS marked Degraded
    ~900 ms : New and existing calls shift to pre-established Internet tunnel : No IKE renegotiation, no route reconvergence
    Recovery : MPLS loss clears : Hold-down timer running to prevent flapping
    After hold-down : New calls returned to MPLS

Key Takeaway: Subsecond failover is not magic — it’s the payoff of two earlier design choices. Frequent timestamped probes detect loss, latency, and jitter problems in well under a second, and because backup tunnels are already established, switching paths only changes a forwarding decision. No IKE renegotiation, no routing convergence — and for critical flows, packet duplication plus FEC/POC make the switch effectively seamless.

Chapter Summary

EdgeConnect structures the network in three layers: the underlay of physical, labeled WAN circuits; the fabric of IPsec tunnels (typically one per underlay per site pair); and the Business Intent Overlays that express application policy. Orchestrator auto-discovers peerings from your chosen topology — hub-and-spoke, full mesh, or regional mesh — and builds and maintains the encrypted tunnels automatically, keeping every transport’s tunnel up at all times.

Dynamic Path Control is the engine that matches each flow to an overlay, filters tunnels to those allowed and currently within SLA, and steers traffic to the best path. Its default is per-flow steering, which pins a flow to a single tunnel to preserve packet order; per-packet steering, or tunnel bonding, stripes packets across tunnels for bandwidth aggregation or high availability at the cost of reordering that must be repaired.

That repair is path conditioning — FEC, which rebuilds lost packets from parity without retransmission, and POC, which resequences out-of-order packets using EdgeConnect’s own per-packet sequence IDs and a tunable reorder wait. Independent Miercom testing showed path conditioning preserving acceptable voice quality under roughly 55% aggregate underlay loss.

Finally, EdgeConnect distinguishes a degraded brownout from a hard blackout by continuously measuring loss, latency, and jitter per tunnel and per direction. Because backup tunnels are pre-established, reacting to a failing path is just a change of forwarding decision — enabling the subsecond failover that vendor and independent testing both confirm.

Key Terms

Chapter 4: Business Intent Overlays and Policy

Learning Objectives

By the end of this chapter, you will be able to:

• Define Business Intent Overlays (BIO) and explain how they translate business policy into network behavior across an EdgeConnect SD-WAN fabric.
• Configure overlay matching criteria, topology choices, and link bonding policy at a conceptual level.
• Explain how routing segmentation and regions interact with overlays to provide isolation and scalability.

In Chapters 1 through 3 you learned what SD-WAN is, how the Silver Peak (now Aruba/HPE) EdgeConnect appliances and Unity Orchestrator fit together, and how the underlay transports are abstracted into a single virtual WAN. This chapter is where those pieces come together into policy. The central question is: how does an administrator tell the fabric “voice must always take the best path and never wait behind a backup job,” and how does that single sentence become thousands of consistent device-level rules across the network? The answer is the Business Intent Overlay.

The Business Intent Model

From Business Intent to Network Policy

A Business Intent Overlay (BIO) is a high-level, intent-based policy object that defines how a particular class of traffic should use the SD-WAN fabric. Rather than hand-building hundreds of per-site access control lists (ACLs), quality-of-service (QoS) queues, and routing statements, the administrator describes the business intent once, and Unity Orchestrator compiles that intent into the detailed configuration pushed to every EdgeConnect appliance [Source: https://www.arubanetworks.com/products/sd-wan/].

Think of a BIO as a contract for a category of traffic. A single BIO bundles all of the following into one object:

• Topology — who is allowed to talk to whom (mesh, hub-and-spoke, or regional mesh).
• Path selection and link bonding — which underlay transports may be used and how multiple links are combined.
• QoS — priority, queuing, bandwidth reservation, shaping, and DSCP marking.
• Security and segmentation — the encrypted overlay and its separation from other overlays.
• Optimization — Forward Error Correction (FEC), packet duplication, and WAN optimization.

The defining feature is the level of abstraction. The administrator does not configure tunnels, route maps, and schedulers individually. They define a small number of overlays tied to business purposes, such as Real-Time (voice, video, collaboration), Transactional (ERP, CRM, database access), Bulk or Best-Effort (backups, software distribution), and Internet or Guest (direct internet access). Common practice is to maintain only three to six core overlays for an entire enterprise [Source: https://www.arubanetworks.com/techdocs/].

Analogy: A BIO is like a shipping service tier. When you choose “overnight, signature required, insured” for a package, you do not specify which trucks, planes, and sorting facilities handle it — the carrier translates your intent into a chain of operational steps. A BIO is the “overnight tier” for a class of network traffic; Orchestrator is the carrier that turns that choice into routing, queuing, and tunnels everywhere.

This is why Aruba calls Orchestrator a policy compiler. You write intent in a human-readable form; Orchestrator derives the fabric-wide design (the tunnel matrix per overlay, site roles, and primary/backup paths), generates device-level configuration (IPsec tunnels and keys, routing and segmentation entries, path-control SLA policies, QoS schedulers, and optimization features), and then continuously enforces and monitors that behavior [Source: https://www.arubanetworks.com/techdocs/sdwan/].

Matching Traffic to Overlays

Defining an overlay is only half the job; the fabric must also decide which flows belong to which overlay. This classification is configured in Orchestrator and evaluated on a first-match, ordered basis. Orchestrator evaluates the overlay list in sequence, and the first overlay whose criteria match a flow takes ownership of that flow. A default or catch-all overlay (often named something like “Default-WAN” or “Internet”) handles any traffic that matches nothing above it.

The matching criteria fall into three broad groups:

Because the policy is first-match, order is load-bearing. A broad rule placed in a higher-priority overlay can “steal” traffic that you intended for a more specific overlay below it. The standard ordering is therefore: critical real-time apps first, transactional line-of-business apps next, bulk and file-transfer traffic after that, then guest and internet, with everything else falling through to the default overlay.

Example: Suppose you place a Transactional overlay that matches the entire data-center subnet 10.0.0.0/8 above a Real-Time overlay that matches the voice application Microsoft Teams. Because Teams media also originates from inside 10.0.0.0/8, the broad subnet rule matches first and Teams traffic ends up in the Transactional tier — losing its EF priority. The fix is to order the specific Real-Time match above the broad subnet match. Orchestrator’s flow-monitoring view lets you confirm which overlay a given flow actually hit, which is the first place to look when classification surprises you.

A key design rule follows from this: avoid overlapping or conflicting criteria between critical overlays, and use the monitoring views to verify intent rather than assuming it.

Preferred and Backup Transport Assignment

Once a flow is assigned to an overlay, the BIO’s path policy decides which underlay transports it may use and in what order of preference. A typical overlay might say “prefer MPLS; move to broadband internet only if the MPLS path violates its SLA.” EdgeConnect appliances continuously measure each path’s latency, loss, and jitter, and they steer flows away from a path the moment it breaches the per-class thresholds defined in the BIO — without waiting for the link to fail outright [Source: https://www.arubanetworks.com/products/sd-wan/].

The administrator expresses preferred and backup transports in business terms:

• Allowed transports — which underlays (MPLS, broadband, dedicated internet access, LTE/5G) this overlay may touch at all.
• Preference order — the primary path and the fallback sequence.
• SLA thresholds — maximum acceptable latency, loss, and jitter for this class, which trigger a path change when violated.
• Prohibited paths — for example, “guest traffic must never use the MPLS circuit,” to protect a paid link from low-value traffic.

Example: A Real-Time overlay may be configured to prefer MPLS, fall back to broadband, and never use LTE except during a full failure, with an SLA ceiling of 150 ms latency and 1% loss. The instant MPLS jitter spikes past the threshold, voice flows shift to broadband; when MPLS recovers, they shift back — all transparently to the user mid-call.

Figure 4.3: From Traffic Match to Transport Selection — an ordered first-match flow that classifies a flow into an overlay, then applies the overlay’s path policy to choose a preferred transport and fall back when the SLA is breached.

flowchart TD
    START(["Incoming flow"]) --> M1{"Matches Real-Time<br/>overlay criteria?"}
    M1 -->|Yes| OV["Assign to overlay"]
    M1 -->|No| M2{"Matches Transactional<br/>overlay criteria?"}
    M2 -->|Yes| OV
    M2 -->|No| DEF["Default / catch-all overlay"]
    DEF --> OV
    OV --> PATH{"Preferred transport<br/>meets SLA?"}
    PATH -->|Yes| PRIMARY["Send via preferred<br/>(e.g. MPLS)"]
    PATH -->|"No (latency/loss/jitter breach)"| BACKUP["Steer to backup<br/>(e.g. broadband)"]
    PRIMARY --> RECHECK{"SLA recovers?"}
    BACKUP --> RECHECK
    RECHECK -->|Yes| PRIMARY
    RECHECK -->|No| BACKUP

Key Takeaway: A Business Intent Overlay is a single intent object that bundles topology, path selection, QoS, security, and optimization for one class of traffic. Orchestrator compiles that intent into fabric-wide device configuration, while ordered first-match classification decides which flows each overlay owns and the path policy decides which transports they prefer.

Overlay Configuration Elements

With the model in hand, we now examine the concrete elements an administrator sets inside each overlay: its topology, its bonding and QoS behavior, and how it handles internet-bound traffic.

Topology: Mesh, Hub-and-Spoke, Regional

Every BIO specifies an overlay topology, which determines which sites build tunnels to which other sites. Orchestrator combines the chosen topology with each site’s role (branch, hub, data center, internet gateway, cloud gateway) to automatically build only the tunnels that are required — the administrator never configures individual tunnel pairs [Source: https://www.arubanetworks.com/techdocs/sdwan/].

Figure 4.4: Overlay Topology Patterns — the tunnel patterns produced by the three topology choices: full mesh (every site to every site), hub-and-spoke (spokes only to a hub), and regional mesh (full mesh within regions, joined by core hubs).

graph TD
    subgraph Mesh["Full mesh"]
        A1["Site A"] --- B1["Site B"]
        B1 --- C1["Site C"]
        A1 --- C1
    end

    subgraph HubSpoke["Hub-and-spoke"]
        H2(("Hub"))
        H2 --- S1["Spoke 1"]
        H2 --- S2["Spoke 2"]
        H2 --- S3["Spoke 3"]
    end

    subgraph Regional["Regional mesh"]
        subgraph AMER["AMER region"]
            R1["Site"] --- R2["Site"]
        end
        subgraph EMEA["EMEA region"]
            R3["Site"] --- R4["Site"]
        end
        CORE(("Core hub"))
        AMER --- CORE
        EMEA --- CORE
    end

Full mesh gives the lowest latency because no traffic detours through a hub, but its tunnel count is the classic scaling problem: 300 sites in a single global mesh would need roughly 300 × 299 / 2 ≈ 44,850 tunnels [Source: https://www.arubanetworks.com/techdocs/sdwan/]. Hub-and-spoke is the choice when traffic should pass through a central point — for example, when every internet-bound flow must traverse a data-center firewall, or when branches mostly talk to centralized ERP and rarely to each other. Regional mesh, covered in detail in the next section, is the compromise for global networks.

Link Bonding Policy and QoS

Inside each BIO, the link bonding strategy defines how multiple WAN transports are combined for that traffic class. EdgeConnect supports three broad modes [Source: https://www.arubanetworks.com/products/sd-wan/]:

• High availability (active/standby) — the primary circuit carries the traffic; the secondary is used only on failure or SLA breach. Suited to transactional apps where predictability matters more than raw throughput.
• Load sharing / high throughput (active/active) — traffic is spread across multiple circuits simultaneously. Ideal for bulk transfers, backups, and large file synchronization where aggregate bandwidth is the goal.
• Real-time performance — for loss-sensitive flows, EdgeConnect can duplicate packets across two paths so that the first copy to arrive is used, or apply Forward Error Correction (FEC) on a single path to reconstruct lost packets without retransmission.

The administrator can also bound the minimum and maximum number of tunnels per overlay between sites and prohibit specific paths for sensitive traffic.

Layered on top of bonding is the overlay’s QoS policy — the rules that govern relative priority and bandwidth. QoS within a BIO covers three areas:

Because Orchestrator pushes one unified QoS policy to every appliance, a flow classified into the Real-Time overlay is treated identically — same priority, same reservation, same DSCP — whether it originates in a New York branch or a Singapore data center. This fabric-wide consistency is one of the central advantages of the intent model over per-site hand configuration.

Figure 4.1: Anatomy of a Business Intent Overlay — a single overlay object shown as a stack of layers (Topology → Path/Bonding Policy → QoS → Security/Segment → Optimization), with arrows showing Orchestrator compiling the stack into per-appliance tunnel, routing, QoS, and SLA configuration.

graph LR
    subgraph BIO["Business Intent Overlay (intent object)"]
        direction TB
        L1["Topology<br/>(mesh / hub-spoke / regional)"]
        L2["Path & Bonding Policy<br/>(allowed transports, preference, SLA)"]
        L3["QoS<br/>(priority, bandwidth, DSCP marking)"]
        L4["Security & Segment<br/>(encrypted overlay, isolation)"]
        L5["Optimization<br/>(FEC, packet duplication, WAN opt)"]
        L1 --> L2 --> L3 --> L4 --> L5
    end

    ORCH["Unity Orchestrator<br/>(policy compiler)"]

    BIO --> ORCH

    ORCH --> C1["Per-appliance IPsec tunnel matrix"]
    ORCH --> C2["Routing & segmentation entries"]
    ORCH --> C3["QoS schedulers & DSCP rules"]
    ORCH --> C4["Path-control SLA policies"]

Internet Breakout and Service Chaining

Not all traffic stays inside the corporate overlay. Internet-bound flows require a separate decision: should they break out locally at the branch, be sent to a cloud security provider, or be backhauled to a data center for inspection? EdgeConnect makes this decision per flow using the overlay’s internet breakout policy.

The fabric first determines whether a destination is “corporate” or “internet.” Corporate prefixes are those learned via the overlay from other EdgeConnect devices, configured statically, or learned from local routing (BGP/OSPF/MPLS). Any destination not matching a known corporate prefix is treated as internet [Source: https://www.arubanetworks.com/techdocs/sdwan/]. The BIO then applies one of these breakout options:

• Local internet breakout (direct) — egress out the local broadband or dedicated-internet-access (DIA) link, with source NAT performed on the branch appliance. Best for trusted, latency-sensitive SaaS such as Microsoft 365 and Zoom, where backhauling would add needless delay.
• Breakout via cloud security — traffic enters an IPsec or GRE tunnel to a cloud security provider such as Zscaler or Palo Alto Prisma Access, which applies URL filtering, IPS, and SSL inspection before forwarding to the internet [Source: https://help.zscaler.com/zia/aruba-edgeconnect-deployment-guide].
• Backhaul to hub or data center — internet traffic rides the SD-WAN overlay to a hub that performs inspection on a next-generation firewall, then breaks out. Simpler to secure centrally, but adds latency.
• No breakout (deny) — for sensitive internal-only applications.

Service chaining is the term for steering selected traffic through an external security service. With Zscaler, for example, the administrator creates a Cloud Security profile in Orchestrator (customer ID and authentication token, preferred ZEN locations, and the tunnel type such as IPsec/Z-Tunnel), and Orchestrator then automates redundant tunnel creation from each branch to the chosen enforcement nodes [Source: https://help.zscaler.com/zia/aruba-edgeconnect-deployment-guide]. The BIO breakout setting then decides which traffic enters those tunnels. A common split is: Office 365 → direct local breakout for performance; general web browsing → Zscaler; guest VLAN → always Zscaler.

A more granular control, Policy-Based Forwarding (PBF), can override the overlay’s default path. PBF matches on source, destination, application, DSCP, or time of day, and forces a specific overlay, a specific underlay, or a specific next-hop or tunnel. The order of evaluation is: security/policy rules first, then BIO mapping, then PBF, then the routing table — so a PBF rule that says “high-risk URL categories always go to Zscaler” takes precedence over the BIO’s default breakout [Source: https://www.arubanetworks.com/techdocs/sdwan/].

Example: A branch with both DIA and MPLS uses Zscaler for security. The Office 365 BIO breaks out locally and directly; the Web-Browsing BIO forwards into the Zscaler tunnel; the Internal-Apps BIO uses MPLS with no breakout at all. A PBF rule adds nuance: any traffic from the Guest VLAN, regardless of application, is always forced into the Zscaler tunnel.

Key Takeaway: Each overlay specifies a topology (mesh, hub-and-spoke, or regional), a link-bonding mode (HA, load sharing, or real-time duplication/FEC), a QoS profile, and an internet-breakout behavior. Service chaining via Orchestrator-built tunnels and per-flow PBF rules let traffic reach cloud security providers or local breakout exactly as policy dictates.

Segmentation and Regions

The final layer of policy concerns isolation and scale. Segmentation answers “who is allowed to reach whom at the routing level,” and regions answer “how do we keep tunnel counts manageable in a global network.” These are distinct from overlays, and understanding the relationship between the three is essential.

Routing Segments (VRF-Like Zones)

A routing segment behaves like a VRF (virtual routing and forwarding instance): it is a completely separate routing table on each appliance, with its own default route, its own learned prefixes, and its own dynamic routing instances (BGP or OSPF) [Source: https://www.arubanetworks.com/techdocs/sdwan/]. Because each segment has an independent routing table, segments may even reuse overlapping IP ranges — two tenants can both use 10.0.0.0/8 without conflict. There is always a default or global segment (often segment ID 0); additional segments carry names such as Corp, Guest, PCI, or IoT.

The binding rules are precise:

• Every LAN-side interface, sub-interface, or VLAN is assigned to exactly one segment. That assignment determines which routing table the traffic uses and which set of overlay tunnels it may use.
• WAN/underlay ports are not segmented. Segmentation happens at the overlay level, not on the physical internet/MPLS port.
• Dynamic routing is per-segment: a BGP neighbor in the Guest segment advertises and receives only Guest routes.

By design, segments are isolated — there is no automatic route leaking between them. To allow controlled communication between, say, Corp and PCI, you route both segments into an external firewall or security gateway that enforces inter-zone policy. The EdgeConnect appliance is deliberately not a general inter-segment router [Source: https://www.arubanetworks.com/techdocs/sdwan/]. This is why troubleshooting in EdgeConnect always begins with the question, “which segment is this interface, route, or overlay in?”

Analogy: Routing segments are like separate, sealed mail systems in one building. The Corp mailroom and the Guest mailroom share the same physical building (the appliance and its WAN links) but never exchange letters directly. If a letter must cross between them, it goes out to a central post office (the firewall) that checks credentials and decides whether to forward it.

Figure 4.5: Routing Segmentation as VRF-Like Zones — LAN interfaces bind to isolated segments, each with its own routing table and overlays; segments never leak routes directly and are bridged only through an external firewall.

graph TD
    V1["Corp VLAN"] --> SC["Corp Segment<br/>(routing table A)"]
    V2["PCI VLAN"] --> SP["PCI Segment<br/>(routing table B)"]
    V3["Guest VLAN"] --> SG["Guest Segment<br/>(routing table C)"]

    SC --> OC["Corp overlays"]
    SP --> OP["PCI overlay (hub-spoke)"]
    SG --> OG["Guest overlay (local breakout)"]

    SC -. "no direct route leaking" .- SP
    SP -. "no direct route leaking" .- SG

    SC --> FW["External firewall<br/>(inter-segment policy)"]
    SP --> FW
    SG --> FW

Regional Mesh and Hierarchy

Recall that a full mesh scales as N(N−1)/2 tunnels — unmanageable for hundreds of global sites. Regions are the scaling mechanism that solves this. Sites are grouped into regions (for example AMER, EMEA, APAC); for a given overlay, the administrator selects regional mesh instead of global full mesh. Sites then form a full mesh only within their region, while inter-region connectivity flows through designated hub or core sites that belong to multiple regions [Source: https://www.arubanetworks.com/techdocs/sdwan/].

The tunnel savings are dramatic:

The mapping hierarchy ties everything together. It reads: Interface → Segment → one or more Overlays → tunnels constrained by Regions. An overlay is always bound to a single segment, but a single segment can host multiple overlays. For instance, the Corp segment might carry a Corp-Data overlay (regional mesh) and a Corp-Voice overlay (prefer MPLS, strict SLA) at the same time — both share the Corp routing table, so routes can be redistributed between them, yet each uses a different topology and policy [Source: https://www.arubanetworks.com/techdocs/sdwan/].

Figure 4.2: The Interface-to-Region Hierarchy — a left-to-right diagram: a LAN VLAN binds to one Segment (Corp); the Segment hosts two Overlays (Corp-Data regional mesh, Corp-Voice MPLS-preferred); each overlay’s tunnels are constrained by Regions (AMER/EMEA/APAC meshes joined by core hubs).

graph LR
    IF["LAN VLAN / Interface"] --> SEG["Corp Segment<br/>(VRF-like routing table)"]

    SEG --> OV1["Corp-Data Overlay<br/>(regional mesh)"]
    SEG --> OV2["Corp-Voice Overlay<br/>(prefer MPLS, strict SLA)"]

    OV1 --> R1["AMER region mesh"]
    OV1 --> R2["EMEA region mesh"]
    OV1 --> R3["APAC region mesh"]
    OV2 --> R1
    OV2 --> R2
    OV2 --> R3

    R1 --- HUB["Core Hub sites<br/>(interconnect regions)"]
    R2 --- HUB
    R3 --- HUB

In a typical regional design, branches belong to exactly one region; regional data centers belong to their home region and possibly a dedicated “Core” region. Inter-region traffic follows the pattern Branch → Regional Hub/DC → Other Regional Hub/DC → Destination Branch. Regional DCs often act as route-reflector-like central points where inter-region routes meet, advertising summarized prefixes and per-region default routes so that both the tunnel count and the routing tables stay manageable.

Security Policy per Segment

Because each segment is an isolated routing domain, segmentation is also the foundation of the network’s security posture. Hard separation requirements — PCI cardholder data, operational technology (OT/IoT) kept apart from IT, guest kept apart from corporate — map naturally onto separate segments, each with its own overlays and its own breakout behavior [Source: https://www.arubanetworks.com/products/sd-wan/].

Example: A retailer places point-of-sale terminals in a PCI segment whose overlay is hub-and-spoke to a hardened data center with no local internet breakout, while guest Wi-Fi sits in a Guest segment whose overlay breaks out locally to the internet through Zscaler and can never reach corporate prefixes. The two never exchange routes on the appliance; any required interaction passes through an inspecting firewall.

Design guidance favors restraint: a typical enterprise uses only two to five segments (Corp, Guest, and perhaps PCI, OT/IoT, or per-tenant for managed service providers). Over-segmentation multiplies complexity, and heavy inter-segment traffic is a signal that the separation boundary may be drawn in the wrong place. Regions should reflect genuine latency domains and organizational boundaries, and small networks (under roughly 50 sites) often need no regions at all.

Key Takeaway: Routing segments provide VRF-style isolation per LAN interface and are bridged only through external firewalls, while regions scale overlays by meshing within regions and interconnecting through hubs. The hierarchy — Interface → Segment → Overlays → Region-constrained tunnels — is the mental model for both designing and troubleshooting an EdgeConnect fabric.

Chapter Summary

This chapter examined how Silver Peak / Aruba EdgeConnect turns business policy into network behavior through Business Intent Overlays. A BIO is a single intent object that bundles topology, path selection and bonding, QoS, security/segmentation, and optimization for one class of traffic. Unity Orchestrator acts as the policy compiler: administrators define a small number of high-level overlays (commonly three to six), and Orchestrator derives the per-overlay tunnel matrix and pushes the detailed IPsec, routing, path-control, QoS, and optimization configuration to every appliance.

Traffic is classified into overlays by ordered first-match rules using DPI application signatures, network attributes, and Layer-4/QoS markers, with a catch-all default overlay; because matching is first-match, overlay order is critical. Each overlay specifies a topology (full mesh, hub-and-spoke, or regional mesh), a link-bonding mode (high availability, load sharing, or real-time duplication/FEC), a QoS profile (priority, guaranteed/ceiling bandwidth, DSCP marking), and an internet-breakout behavior (local direct, cloud-security service chaining, backhaul, or deny). Policy-Based Forwarding can override these defaults per flow.

Finally, routing segments deliver VRF-style isolation — separate routing tables bound to LAN interfaces, bridged only through external firewalls — while regions and regional mesh dramatically reduce tunnel counts and control-plane overhead for global networks. The hierarchy Interface → Segment → Overlays → Region-constrained tunnels is the unifying model for the EdgeConnect policy plane and the starting point for any troubleshooting effort.

Key Terms

Chapter 5: EdgeConnect Models and Hardware Platforms

In the previous chapters, you learned how Silver Peak EdgeConnect builds an SD-WAN overlay, steers traffic across multiple transports, and applies business intent to every flow. All of that intelligence has to run somewhere. That “somewhere” is the EdgeConnect appliance — a physical box in a wiring closet, a virtual machine on a hypervisor, or a cloud instance in a virtual private cloud. This chapter is about choosing the right somewhere.

Picking the wrong appliance is one of the most common and most expensive mistakes in an SD-WAN rollout. Under-size a data center hub and it becomes a bottleneck that throttles every branch behind it. Over-size a tiny retail outlet and you have paid for a rack-mount server to do the work a deskside appliance could handle. The good news is that EdgeConnect comes in a tidy, predictable family of models that scale cleanly from a closet-sized branch to a multi-gigabit data center, plus virtual and cloud editions that run the very same software.

By the end of this chapter you will be able to name every member of the EdgeConnect family, read and compare their key specifications, and match a model to a real deployment scenario.

Learning Objectives

After completing this chapter, you will be able to:

• Identify the EdgeConnect hardware families (EC-XS, EC-S, EC-M, EC-L, EC-XL, and the Boost option) and their target deployment sizes.
• Compare throughput, simultaneous-connection scale, port counts, and form factors across models.
• Select an appropriate model for a given branch, campus, or data center scenario.

The EdgeConnect Appliance Family

EdgeConnect appliances all run the same operating system and present the same management experience through Orchestrator (covered in a later chapter). What differs from model to model is capacity — how much encrypted traffic the box can push, how many simultaneous connections it can track, and what kind of physical ports it offers. Think of the family like a line of delivery trucks from a single manufacturer: a compact van, a box truck, and an 18-wheeler all drive the same way and obey the same rules, but each is built for a different size of load.

The physical family spans five named classes, from smallest to largest [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

• EC-XS (Extra-Small)
• EC-S (Small)
• EC-M (Medium)
• EC-L (Large)
• EC-XL (Extra-Large)

The naming is deliberately T-shirt-sized, which makes the line easy to reason about: as you move from XS toward XL, throughput, connection scale, and physical port options all increase.

Figure 5.1: The EdgeConnect appliance family arranged smallest-to-largest, showing the deployment role of each class (small branch → data center / large hub).

graph TD
    Family["EdgeConnect Appliance Family"]

    Family --> Branch["Branch class<br/>256K connections"]
    Family --> Hub["Hub / data-center class<br/>2M connections"]
    Family --> Virtual["Virtual / cloud<br/>EC-V"]

    Branch --> XS["EC-XS: 2-200 Mbps<br/>small / remote branch"]
    Branch --> S["EC-S: 10-1000 Mbps<br/>large branch"]

    Hub --> M["EC-M: 50-2000 Mbps<br/>head office / small hub"]
    Hub --> L["EC-L: 1-5 Gbps<br/>data center / large hub"]
    Hub --> XL["EC-XL: 2-10 Gbps<br/>high-end data center"]

    Virtual --> V["EC-V: throughput-tier licensed<br/>ESXi / KVM / Hyper-V / AWS / Azure / GCP"]

EC-XS and EC-S: small branches

The two smallest members anchor the family at the branch edge.

The EC-XS is the entry point — the form factor (the physical size, shape, and mounting style of an appliance) is a compact, fan-cooled desktop-class unit rather than a rack server. It is built for very small or remote sites: a single retail outlet, a small office, or a kiosk with a modest WAN connection. It carries WAN bandwidth in the 2–200 Mbps range (with all features and encryption enabled), tracks up to 256,000 simultaneous connections, and presents 4 × RJ45 10/100/1000 Mbps copper datapath interfaces [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. Those four copper ports are typically enough to land one or two WAN circuits (say, a broadband Internet line and an LTE backup) and connect to the local LAN switch.

The EC-S (datasheet part identifier EC-S-P) steps up to larger branches. It supports WAN bandwidth from 10–1000 Mbps, the same 256,000 simultaneous connections as the EC-XS, but doubles the port count to 8 × RJ45 10/100/1000 Mbps copper interfaces [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. The extra ports matter at a busy branch that has multiple circuits — MPLS plus two Internet links plus LTE — and several internal network segments to connect.

A useful way to picture the difference: the EC-XS is the espresso machine for a one-person coffee cart, while the EC-S is the machine behind the counter of a busy café. Same coffee, very different volume.

EC-M and EC-L: medium and large sites

As sites grow into regional offices, large branches, head offices, and small data center hubs, two things change: aggregate bandwidth climbs into the gigabit range, and the appliance needs to track far more concurrent sessions. The EC-M and EC-L answer that need, and they also introduce fiber connectivity.

The EC-M (Medium; part identifiers EC-M-B and EC-M-P) targets a head office or small hub. It supports 50–2000 Mbps of WAN bandwidth and — a major jump from the branch models — up to 2,000,000 simultaneous connections [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. That eight-fold leap in connection scale (from 256,000 to 2,000,000) is what separates a branch box from a hub-capable box: a hub terminates traffic from many branches at once, so it must hold a far larger session table. On ports, the EC-M offers 4 × RJ45 1 GbE copper interfaces plus 2 × 1/10 GbE fiber interfaces [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. The fiber pair comes in two flavors that correspond to the model suffix, discussed under “B and P variants” below.

The EC-L (Large; part identifiers EC-L-B and EC-L-P) is positioned for data centers and large hubs. It raises WAN bandwidth to 1–5 Gbps, keeps the 2,000,000 simultaneous-connection scale, and uses the same port layout as the EC-M — 4 × RJ45 1 GbE plus 2 × 1/10 GbE fiber [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. In practice the EC-L is the workhorse for a regional hub or a mid-sized data center that aggregates dozens of branches.

EC-XL: high-end data center platform

At the top of the line sits the EC-XL (Extra-Large; part identifiers EC-XL-B and EC-XL-P), built for data centers and large hubs. It delivers 2–10 Gbps of WAN bandwidth with all features and encryption enabled, tracks 2,000,000 simultaneous connections, and offers the richest port options in the family [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

• EC-XL-B: 4 × 1/10 GbE fiber ports with fail-to-glass bypass.
• EC-XL-P: 6 × 1/10 GbE SFP+ ports, or 6 × 1/10/25 GbE SFP28 cages — the only model in the family that reaches 25 GbE [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

The EC-XL is a 1U rack-mount platform (approximately 1.7 in H × 17.3 in W × 31.3 in D, about 37 lb) and supports data-center-grade features the smaller boxes do not, including dual-redundant power supplies and optional NVMe “Network Memory” for WAN optimization [Source: https://www.silver-peak.com/sites/default/files/infoctr/sp-specificationssheet-edgeconnect-xl.pdf]. A later variant, the EC-XL-H-10G, supports up to 6 × 1/10 GbE SFP+ (no 25 GbE) while keeping the same 2–10 Gbps SD-WAN bandwidth and up to 5 Gbps of WAN optimization as the EC-XL-H [Source: https://ironbow.com/hubfs/OMNIA-OEM-List-Pricing/ARUBA.xlsx].

Understanding the B, P, and -NM variants (and Boost)

Across the EC-M, EC-L, and EC-XL classes you will see suffix letters that describe the physical interface and optimization options rather than a different capacity tier [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

• -B variants use fixed fiber ports with fail-to-glass bypass — if the appliance loses power, the optical path closes through so the link stays up (analogous to a mechanical relay that “fails closed”). This protects an inline data center deployment from a single appliance outage.
• -P variants use pluggable optics (SFP+ or, on the EC-XL, SFP28), giving you the flexibility to choose transceivers and reach.
• -NM variants add NVMe Network Memory, the high-speed local storage that powers Aruba Boost WAN optimization.

Boost is not a separate appliance model; it is an optional WAN-optimization capability (deduplication, compression, and TCP acceleration) layered onto the hardware. The datasheet lists a recommended Boost (WAN-opt) capacity per class, which scales with the platform: 50 Mbps on EC-XS, 500 Mbps on EC-S and EC-M, 1 Gbps on EC-L, and 5 Gbps on EC-XL [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. When you enable Boost, plan for the -NM hardware and remember that optimization consumes processing headroom (more on that in the next section). Boost is covered in more detail in the licensing chapter; here, treat it as a capability that rides on top of the platform you select.

Key Takeaway: EdgeConnect ships in five T-shirt-sized hardware classes — EC-XS and EC-S for small and large branches, EC-M and EC-L for head offices and hubs, and EC-XL for high-end data centers — plus a Boost WAN-optimization option. The suffixes (B, P, -NM) describe interface and optimization choices, not capacity tiers, and connection scale jumps eight-fold (256K → 2M) when you move from branch-class to hub-class models.

Specifications and Selection

Reading EdgeConnect specifications well is the heart of model selection. The most important columns are WAN bandwidth, simultaneous connections, datapath ports, and form factor. The table below consolidates the authoritative datasheet figures for the physical family.

Comparison table: EdgeConnect physical models

Figure 5.2: Side-by-side specification comparison of the EdgeConnect physical appliance family.

All figures above are from the official Aruba EdgeConnect SD-WAN Edge Platform datasheet, except the EC-XL physical dimensions and redundant-PSU/NVMe details, which come from the EdgeConnect XL specifications sheet [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf] [Source: https://www.silver-peak.com/sites/default/files/infoctr/sp-specificationssheet-edgeconnect-xl.pdf].

A note on precision: newer QuickSpecs occasionally publish slightly different bounds for the same class (for example “2–1000 Mbps” for the EC-S or “50 Mbps–5 Gbps” for the EC-L) depending on software version and test profile [Source: https://www.hpe.com/us/en/collaterals/collateral.a50004289enw.html]. Always confirm against the current datasheet for the software release you intend to run rather than memorizing a single number.

Throughput and tunnel scale per model

Two specifications govern how many sites and how much traffic a box can handle: throughput and connection scale.

Throughput is not a single number. The same appliance reports very different figures depending on what you ask it to do. The order, from highest to lowest, is always:

1. Maximum throughput (unencrypted, large packets) — the headline lab figure under ideal conditions.
2. Encrypted (IPsec) throughput — lower and more realistic, because encryption costs CPU.
3. Encrypted throughput with Boost / WAN-OP — lower still, because optimization adds processing.
4. IMIX throughput — measured with a realistic mix of packet sizes rather than all-large packets.

For sizing you should use the sustained encrypted IMIX throughput with all required features enabled, because that is closest to real traffic [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. The datasheet’s “WAN bandwidth (all features + encryption)” column in Figure 5.2 already reflects this realistic, features-on view, which is why it is the right column to size against.

Connection (session) scale is the published metric for how many concurrent flows the box can track: 256,000 for the branch-class EC-XS and EC-S, and 2,000,000 for the hub-class EC-M, EC-L, and EC-XL [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

A word on tunnels: the public datasheets do not publish an explicit “tunnels per appliance” number. Instead they expose simultaneous connections as the scale metric, and the exact overlay tunnel counts live in Aruba’s detailed sizing guides rather than the marketing datasheet [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. In real designs the tunnel count is rarely the bottleneck at a branch — even branch-class boxes carry hundreds of tunnels, far more than a normal branch needs. Throughput and enabled features almost always run out first. (Where a precise tunnel limit matters for a large hub design, consult the current Aruba sizing tool and sizing guide; do not assume a number the datasheet does not state.)

Interface options, LTE, and PoE

Beyond raw speed, the kind of ports a model offers shapes where it fits:

• Copper RJ45 (10/100/1000 Mbps) is the only datapath media on the EC-XS (4 ports) and EC-S (8 ports), which is exactly right for branches where every circuit and LAN is copper Ethernet [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].
• Fiber (1/10 GbE) appears on the EC-M and EC-L as a pair of ports alongside the copper interfaces, and dominates the EC-XL, which is fiber-only [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].
• High-speed pluggable optics (SFP+ and SFP28) reach 25 GbE only on the EC-XL-P, the right choice for a data center spine that already runs 25G [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

On LTE and PoE: the research datasheets confirm that EdgeConnect appliances commonly land an LTE circuit as one of their WAN transports (the LTE-plus-broadband-plus-MPLS branch is a standard EdgeConnect design pattern), but the available datasheet sources here do not publish a per-model table of built-in cellular modems or Power-over-Ethernet port specifications. Treat LTE as a supported transport — typically via a cellular uplink — and verify any requirement for an integrated modem or PoE on the specific SKU and software release in the current QuickSpecs before committing, rather than assuming a given model includes it.

Sizing guidance by users and bandwidth

Selecting a model is a methodical process, not a guess [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

1. Gather requirements — access bandwidth per site, traffic direction (mostly Internet breakout versus heavy hub/data-center traffic), topology (hub-and-spoke, partial mesh, full mesh), number of branches per hub, and expected growth.
2. Determine the real performance requirement — take peak expected WAN utilization, assume encryption is on, and add 20–40% headroom.
3. Define the feature set — encryption (almost always yes), Boost/WAN-OP, segmentation, firewall, IDS/IPS, URL filtering. Every added feature lowers effective throughput on the same box.
4. Estimate tunnel/connection scale — branches connect to hubs, cloud, and sometimes other branches; a hub’s load is roughly branches × hubs-per-branch plus cloud/partner tunnels. Add growth headroom (often 2× the current count).
5. Map to a hardware class — XS/S for very small to large branches, M/L for head offices and hubs, XL for campus and data center cores.
6. Add redundancy — single appliance at most branches; an HA pair at large or critical sites, sized so one unit can carry the full site load on failover.
7. Validate with vendor tools — confirm Mbps and tunnel limits against the current datasheet and Aruba’s official EdgeConnect sizing tool before ordering.

Two worked examples make this concrete:

• Branch example. A site has 2 × 100 Mbps direct Internet access (DIA), for 200 Mbps total. You expect ~150 Mbps peak. Apply 30% headroom and you should size for ~200 Mbps encrypted — which lands on a small-branch EC-XS or low-end EC-S [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].
• Data center example. 100 branches each peaking at ~100 Mbps create roughly 10 Gbps of aggregate WAN at the hub. With headroom you want ~15 Gbps+ of encrypted capacity — which exceeds a single EC-XL’s 2–10 Gbps range, so the right answer is two or more data-center-class EdgeConnects in an HA or scale-out cluster, not one bigger box [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

Figure 5.4: Model-selection decision flow — map required encrypted, features-on throughput (plus 20-40% headroom) to a recommended EdgeConnect class.

flowchart TD
    Start["Required encrypted throughput<br/>(peak + 20-40% headroom)"] --> Q1{"Under 200 Mbps?<br/>small / remote branch"}
    Q1 -->|Yes| XS["EC-XS<br/>2-200 Mbps, 256K conn"]
    Q1 -->|No| Q2{"Up to ~1 Gbps?<br/>large branch"}
    Q2 -->|Yes| S["EC-S<br/>10-1000 Mbps, 256K conn"]
    Q2 -->|No| Q3{"Up to ~2 Gbps?<br/>head office / small hub"}
    Q3 -->|Yes| M["EC-M<br/>50-2000 Mbps, 2M conn"]
    Q3 -->|No| Q4{"Up to ~5 Gbps?<br/>data center / large hub"}
    Q4 -->|Yes| L["EC-L<br/>1-5 Gbps, 2M conn"]
    Q4 -->|No| Q5{"Up to ~10 Gbps?"}
    Q5 -->|Yes| XL["EC-XL<br/>2-10 Gbps, 2M conn"]
    Q5 -->|No| ScaleOut["Scale out: multiple<br/>EC-XL / EC-V hubs"]

That second example illustrates a core design principle: at hubs, scale out, not just up. Use multiple moderate hubs, regional hubs, or cloud-hosted virtual EdgeConnects rather than betting everything on a single maximum-sized appliance. And when a site’s throughput is borderline between two classes, either move up to the next class or offload on-box features (for example, push branch-to-cloud traffic to a virtual hub).

Key Takeaway: Size by encrypted, features-on throughput plus 20–40% headroom — never by the unencrypted headline number. Connection scale (256K branch / 2M hub) and port media further narrow the choice. When aggregate hub demand exceeds a single EC-XL’s 2–10 Gbps, scale out with multiple appliances rather than reaching for a single bigger box.

Virtual and Cloud Form Factors

Not every SD-WAN endpoint is a physical box. A site in a public cloud has no wiring closet, and many organizations prefer to run network functions as software on infrastructure they already own. EdgeConnect answers both needs with EC-V.

EC-V virtual appliance on hypervisors

EC-V (Unity EdgeConnect Virtual) is the virtual form factor of EdgeConnect — functionally equivalent to the hardware appliances for routing, SD-WAN, optimization, and security integration, but running as a virtual machine that draws its CPU, RAM, disk, and NICs from the underlying hypervisor or cloud instead of dedicated hardware [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. It is packaged as a VM image (OVA, VHD/VHDX, or QCOW2-style, depending on the platform) and licensed per instance, sized by a throughput tier.

If the physical appliances are delivery trucks, EC-V is the same delivery service running on rented vehicles — you choose how big a vehicle to rent (the throughput tier and instance size), but the cargo and the rules of the road are identical.

EC-V runs on the major type-1 enterprise hypervisors [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

• VMware ESXi / vSphere — delivered as an OVA; import it, assign port groups, set vCPU/RAM to match the chosen throughput tier, and power on. Works on standalone ESXi, vCenter-managed clusters, and vSphere private clouds.
• KVM — provided as a KVM-compatible image, commonly used with Linux virtualization stacks and OpenStack, deployed via libvirt/virt-manager or OpenStack.
• Microsoft Hyper-V — delivered as a VHD/VHDX image for Hyper-V on Windows Server, deployed as a virtual machine with the appropriate vNICs and resources for the tier.

The same EC-V software image family is used across these hypervisors, with packaging and drivers tailored to each; the feature set and SD-WAN behavior are aligned across ESXi, KVM, and Hyper-V.

Cloud marketplace deployments (AWS, Azure, GCP)

EC-V is also available as a cloud-native virtual appliance in the major IaaS platforms, generally offered as BYOL (Bring Your Own License) with a chosen bandwidth tier, where you match the cloud instance/VM size to the tier [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

• Amazon Web Services (AWS) — deployed as an EC2-based virtual appliance from the AWS Marketplace or a shared AMI. Pick a supported EC2 instance family/size (general-purpose or network-optimized) plus a throughput-tier license. Common in transit-VPC hubs, regional hubs, and VPC-to-VPC SD-WAN designs.
• Microsoft Azure — delivered as a pre-built image via the Azure Marketplace and deployed as an Azure VM (for example a DSv2/DSv3 or F-series size) mapped to the desired tier. Often used in hub-and-spoke virtual-network topologies for branch-to-Azure and multi-cloud connectivity.
• Google Cloud Platform (GCP) — deployed as a Compute Engine VM from a public image or marketplace listing, with a machine type sized for the tier plus the EC-V license. Used as a regional hub or gateway for VPC-to-branch and inter-cloud connectivity.

The Aruba datasheet confirms EC-V availability on all major hypervisors and public cloud marketplaces, including AWS and Azure [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

EC-V throughput tiers are graduated software-licensed levels that map to a recommended vCPU/RAM profile on-premises or a minimum instance size in the cloud [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]:

Figure 5.3: EC-V throughput tiers and their rough alignment to physical EdgeConnect classes.

You scale up by redeploying or resizing to a higher tier and, where needed, a larger instance type. Note that the exact tier names and Mbps/Gbps values vary by software release and entitlement; the canonical reference for precise tier-to-instance mapping is Aruba’s EC-V Deployment Guide and QuickSpecs rather than a fixed table [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. The tier-to-class alignment in Figure 5.3 is approximate guidance, not a published SKU equivalence.

Ruggedized and specialized variants

For the physical line, the available datasheet sources here document interface and optimization variants — the -B (fixed fiber, fail-to-glass bypass), -P (pluggable SFP+/SFP28), and -NM (NVMe Network Memory for Boost) suffixes described earlier — as the main specialization axis, along with the EC-XL-H and EC-XL-H-10G high-end data center variants [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf] [Source: https://ironbow.com/hubfs/OMNIA-OEM-List-Pricing/ARUBA.xlsx]. The research material does not document a distinct ruggedized (extended-temperature or hardened) EdgeConnect SKU; if an industrial or outdoor deployment requires a hardened appliance, that is a requirement to confirm directly against the current HPE Aruba SKU list and QuickSpecs rather than assume from the standard family. In short, the primary way EdgeConnect “specializes” within a capacity class is through media type (copper/fiber/SFP+/SFP28), bypass behavior, optimization memory, and the virtual/cloud form factor — and, of course, the choice between hardware and EC-V itself.

Key Takeaway: EC-V brings the full EdgeConnect feature set to VMware ESXi, KVM, and Hyper-V on-premises and to AWS, Azure, and GCP as a marketplace BYOL appliance, sized by throughput tier rather than by physical model. Cloud and virtual hubs are the recommended way to scale out reach without adding hardware — though exact tier values and any ruggedized variants should be confirmed in current Aruba QuickSpecs and deployment guides.

Chapter Summary

EdgeConnect’s hardware lineup is intentionally simple to reason about. Five T-shirt-sized physical classes climb in capacity from the EC-XS (small branch, 2–200 Mbps, 4 × 1 GbE copper, 256K connections) and EC-S (large branch, 10–1000 Mbps, 8 × 1 GbE copper, 256K connections), through the hub-capable EC-M (50–2000 Mbps, 2M connections) and EC-L (1–5 Gbps, 2M connections) with their copper-plus-fiber port layouts, up to the data-center-grade EC-XL (2–10 Gbps, 2M connections, fiber/SFP+/SFP28 up to 25 GbE, redundant power, optional NVMe). Suffixes (B, P, -NM) select interface and optimization options, and Boost is an optional WAN-optimization layer whose recommended capacity scales with the class (50 Mbps up to 5 Gbps).

Selection comes down to disciplined sizing: size against encrypted, all-features-on throughput plus 20–40% headroom, account for connection scale and port media, plan HA so one unit can carry the full load, and scale out at large hubs rather than relying on a single maximum-sized box. Where the endpoint lives in software or in the cloud, EC-V delivers the same capabilities on ESXi, KVM, and Hyper-V and across AWS, Azure, and GCP, licensed by throughput tier. Throughout, the discipline is the same: confirm exact numbers against the current Aruba datasheet, QuickSpecs, and sizing tool, and never invent a spec the documentation does not publish.

With the right platform chosen, the next chapters turn to how these appliances are licensed and centrally managed.

Key Terms

Chapter 6: Boost, WAN Optimization, and Performance Features

Learning Objectives

By the end of this chapter, you will be able to:

• Explain the EdgeConnect Boost add-on and describe its relationship to legacy Silver Peak WAN optimization (the NX and VX appliances).
• Describe the core optimization techniques Boost employs: TCP acceleration, protocol acceleration, Network Memory deduplication, and compression.
• Determine when Boost and WAN optimization deliver measurable value versus when standard SD-WAN path control and tunnel bonding are sufficient on their own.

A recurring theme in earlier chapters has been that Aruba (formerly Silver Peak) EdgeConnect makes a collection of ordinary, often cheap, internet circuits behave like a single resilient enterprise WAN. Path selection, dynamic path conditioning, and business-intent overlays do that by choosing where packets go and protecting them from loss and jitter. But none of those features change a fundamental limitation: the speed of light, the round-trip time (RTT) of a long-haul link, and the chattiness of older application protocols. A backup job replicating across an ocean, or a user opening a large file over a 150-millisecond link, can crawl even when there is plenty of bandwidth and almost no packet loss. This is the problem WAN optimization solves, and on EdgeConnect it is delivered through a licensed add-on called Boost. This chapter explains what Boost is, how it works under the hood, and—just as importantly—when it is not worth turning on.

Note on sources: The chapter draws on documented EdgeConnect and Silver Peak behavior. Where a claim should be confirmed against primary documentation, it is cited to the authoritative vendor sources—Aruba/HPE EdgeConnect SD-WAN product documentation, the Silver Peak Unity Boost and Network Memory datasheets, and the Aruba Orchestrator administration and licensing guides [Source: Aruba/HPE EdgeConnect SD-WAN documentation, https://www.arubanetworks.com/products/sd-wan/].

What Boost Adds

Boost as a Licensed Performance Tier

Throughout this textbook, EdgeConnect has been described as the SD-WAN platform—physical appliances or virtual machines that build overlay tunnels, perform routing, steer applications across underlay circuits, and apply quality of service (QoS). Boost is not a different product or a separate box. It is a software feature license you apply to an EdgeConnect appliance to unlock its WAN optimization capabilities: TCP acceleration, data deduplication, and compression [Source: Silver Peak Unity Boost datasheet, https://www.arubanetworks.com/].

It helps to picture the EdgeConnect appliance as a car that already ships with a capable engine—routing, path selection, segmentation. Boost is like a performance package you license after the fact: the chassis does not change, but you switch on a higher-output mode that was always latent in the hardware. Without the Boost license, an EdgeConnect runs SD-WAN only: it routes, applies QoS, and performs path conditioning (forward error correction and packet-order correction), but it does not terminate TCP sessions locally or maintain a deduplication cache. With Boost licensed and enabled, the same appliance gains the full WAN optimization engine.

Key Term — Boost: A licensed software add-on for EdgeConnect that enables WAN optimization functions (TCP acceleration, deduplication, compression) on an appliance that is already performing SD-WAN. It is a feature tier, not a separate device.

Key Term — WAN optimization: A family of techniques (TCP/protocol acceleration, data reduction, latency mitigation) that make a wide-area link behave more like a fast, clean local network by sending fewer bytes and hiding loss and latency from applications.

Two characteristics define how Boost is consumed. First, it is a performance tier layered on the same hardware—you do not redesign your topology to add it. Second, it is symmetric by requirement: optimization between two sites only happens when both EdgeConnect appliances on that path are Boost-capable and Boost-enabled. A branch with Boost talking to a data center without it gets no WAN optimization on that flow—just standard SD-WAN path selection and QoS. This is intrinsic to how the technology works, as you will see in the next section: optimization is a conversation between two cooperating appliances, and a conversation needs two participants.

Figure 6.1: EdgeConnect with and without the Boost license — a side-by-side comparison showing the same appliance running “SD-WAN only” (routing, QoS, FEC/POC) on the left, and “SD-WAN + Boost” (adding TCP proxy, Network Memory cache, compression) on the right, with the Boost license key as the toggle between them.

graph TD
    Key["Boost License Key (toggle)"]

    subgraph Without["SD-WAN Only (no Boost)"]
        W1["Routing and forwarding"]
        W2["Quality of Service (QoS)"]
        W3["Path conditioning (FEC / POC)"]
    end

    subgraph With["SD-WAN Plus Boost"]
        B1["Routing, QoS, path conditioning"]
        B2["TCP proxy (split-TCP acceleration)"]
        B3["Network Memory dedup cache"]
        B4["LZ-style compression"]
    end

    Key -->|License absent| Without
    Key -->|License applied| With

Allocating Boost Bandwidth Across the Fabric

Boost is not licensed per appliance as an on/off switch. It is licensed as a pool of WAN optimization throughput, measured in Mbps or Gbps, that you draw from and allocate across your fabric using Aruba Orchestrator [Source: Aruba Orchestrator administration and licensing guide, https://www.arubanetworks.com/]. You buy, say, a 300 Mbps Boost pool, then assign slices of that pool to individual appliances based on how much optimized traffic each site needs.

Consider a worked example. Suppose a data center has a 1 Gbps WAN connection, but only about 300 Mbps of that is replication and backup traffic you want optimized. A second data center handles 500 Mbps. You would license a Boost pool sized to your intended optimized bandwidth—roughly 300 Mbps—and allocate 300 Mbps to each data center. Branch offices that do occasional file transfers might each get 10 to 20 Mbps.

Two allocation rules are critical and routinely trip up new administrators:

1. The optimized rate between two sites is limited by the smaller of the two allocations. If Data Center 1 has 300 Mbps allocated and Branch A has only 20 Mbps, the optimized session between them can only run WAN optimization up to 20 Mbps—the branch is the bottleneck. Boost capacity behaves like the narrowest pipe in a series.
2. Allocation is dynamic and software-defined. Because Boost is a license pool managed in Orchestrator, you can reallocate capacity between sites without touching any hardware. If a seasonal project shifts heavy replication to a different region, you move the Mbps where they are needed.

Within a single appliance, the allocated Boost capacity is shared by all flows matching Boost-enabled policies. If Data Center 1 has 300 Mbps of Boost but 400 Mbps of replication traffic eligible for optimization, Boost optimizes up to 300 Mbps and the remainder passes through unoptimized (still routed and protected by SD-WAN, just without the WAN-op engine).

Figure 6.2: Boost pool allocation across a fabric — a central Orchestrator “pool” of 300 Mbps with arrows distributing slices to two data centers and several branches, annotated with the “limited by the smaller end” rule on a DC-to-branch path.

graph TD
    Pool["Orchestrator Boost Pool (300 Mbps)"]
    DC1["Data Center 1 (300 Mbps allocated)"]
    DC2["Data Center 2 (300 Mbps allocated)"]
    BrA["Branch A (20 Mbps allocated)"]
    BrB["Branch B (10 Mbps allocated)"]

    Pool -->|allocate slice| DC1
    Pool -->|allocate slice| DC2
    Pool -->|allocate slice| BrA
    Pool -->|allocate slice| BrB

    DC1 -.->|"optimized rate capped at smaller end = 20 Mbps"| BrA

Use Cases for Long-Haul and High-Latency Links

Where does this performance tier earn its keep? The short answer: on TCP traffic that is limited by latency or protocol inefficiency rather than by raw bandwidth or loss. Standard SD-WAN with tunnel bonding already aggregates circuits and protects against loss and jitter. What it cannot do is change how TCP behaves over distance.

The physics matter here. A single TCP stream’s maximum throughput is roughly its window size divided by the round-trip time. On a “long fat” link—high bandwidth, high latency, such as an intercontinental circuit at 120 ms RTT—a default TCP stack simply cannot grow its window fast enough to fill the pipe. You can have a 200 Mbps link with 1% loss and still see a single backup stream plateau at a few megabits per second. Adding more bandwidth does nothing; the limiter is RTT and TCP’s conservative window growth. This is precisely the regime where Boost transforms throughput.

Prime long-haul and high-latency use cases include:

• Intercontinental and satellite links where RTT runs 80 to 200+ ms and individual TCP flows chronically underutilize available capacity.
• Backup and disaster-recovery replication (for example NetApp SnapMirror, Dell EMC SRDF, Veeam, or vSphere replication) that runs continuously, carries highly repetitive data, and must meet strict Recovery Point and Recovery Time Objectives (RPO/RTO).
• Bulk data movement—media assets, CAD files, large datasets, initial cloud-seeding migrations—where the transfer time is business-critical.

Key Takeaway: Boost is a licensed software performance tier, not a separate appliance. It is consumed as a throughput pool allocated across the fabric in Orchestrator, requires Boost at both ends of any optimized path (with the optimized rate capped by the smaller allocation), and delivers its greatest value on high-latency, long-haul TCP traffic that bandwidth alone cannot speed up.

Optimization Techniques

Having established what Boost is, we now open the hood. Every Boost technique is, at its core, one of two tricks: send fewer bytes across the WAN, or make the WAN look less lossy and less latent to the applications. The first goal is served by deduplication and compression; the second by TCP and protocol acceleration. EdgeConnect intercepts eligible flows at each end, applies these optimizations, carries the result across a private optimized transport inside the overlay, and reconstructs the original flow on the far side—all transparently to the end hosts.

TCP Acceleration and Protocol Optimization

TCP acceleration is the headline latency-fighting feature. The mechanism is a TCP proxy, sometimes called split-TCP or local termination. Instead of one end-to-end TCP session stretched across the WAN, there are effectively three segments:

1. The client’s TCP session terminates locally on the branch EdgeConnect.
2. A separate, WAN-tuned optimized transport runs between the two EdgeConnects.
3. The server’s TCP session terminates locally on the data-center EdgeConnect.

Crucially, the end hosts never know. Each host believes it has a normal, direct TCP conversation with the remote host. In reality each is talking to a nearby proxy on its local EdgeConnect, and the long-haul middle leg is a high-performance transport tuned for the actual bandwidth and RTT of the link.

Key Term — TCP acceleration: A WAN optimization technique that locally terminates (proxies) TCP at each end and replaces the WAN leg with an optimized transport, using local acknowledgments, aggressive window scaling, and WAN-tuned congestion control to hide round-trip latency from endpoints.

The specific techniques the TCP proxy uses include:

• Local acknowledgments (ACK spoofing). The local EdgeConnect acknowledges the client’s TCP segments immediately, without waiting for the data to cross the WAN and be acknowledged by the far end. The client, seeing fast ACKs, grows its congestion window quickly and keeps sending. This is the single most powerful trick for hiding RTT.
• Aggressive window scaling. On the optimized middle leg, EdgeConnect uses large TCP windows appropriate to the link’s true bandwidth-delay product—far more aggressive than a default endpoint stack would dare.
• WAN-tuned congestion control and loss recovery. Retransmissions are handled locally between the two EdgeConnects, so endpoints rarely see drops or retransmission timeouts. Combined with the path-conditioning features below, this keeps the pipe full.

An analogy: imagine mailing a series of letters to a colleague overseas where each letter asks “received the last one?” before you send the next. The conversation takes weeks because every exchange waits for an ocean crossing. The TCP proxy is like hiring a local assistant who confirms receipt for you the moment you hand over a letter, batches everything for the overseas trip, and has a counterpart assistant who does the same on the far side. You keep working at local speed while the slow leg is managed behind the scenes.

On top of TCP, Boost adds protocol acceleration for chatty application protocols whose real problem is the number of round-trips, not the volume of data:

• CIFS/SMB (Windows file sharing): read-ahead (prefetching the data a client is likely to request next), write-behind (acknowledging writes locally then efficiently pushing them across the WAN), and metadata optimization to reduce the chattiness of file opens, directory listings, and permission checks.
• MAPI/Exchange, NFS, and HTTP: bundling and pipelining requests to collapse many serial round-trips into fewer exchanges.

The payoff is dramatic for operations whose total time is “N round-trips × RTT.” Removing even a few round-trips per file open over a 100 ms link can turn a multi-second wait into a near-instant one.

Figure 6.3: Split-TCP proxy across the WAN — a sequence diagram showing the client, branch EdgeConnect, data-center EdgeConnect, and server; local ACKs returning instantly to the client and server while a single optimized transport carries data across the high-latency middle leg.

sequenceDiagram
    participant C as Client
    participant BE as Branch EdgeConnect
    participant DE as Data-Center EdgeConnect
    participant S as Server

    C->>BE: TCP data segment
    BE-->>C: Local ACK (instant, ACK spoofing)
    BE->>DE: Optimized WAN transport (large windows, high-latency leg)
    DE->>S: TCP data segment
    S-->>DE: Local ACK (instant)
    Note over BE,DE: Retransmissions handled locally on the middle leg

This middle leg also benefits from EdgeConnect’s path-conditioning features (introduced in earlier chapters), which complement Boost:

• Forward Error Correction (FEC): EdgeConnect sends redundant parity packets (for example, one parity packet per N data packets). If a packet is lost within that group, the receiver reconstructs it from parity—no retransmission needed. On lossy links, this prevents TCP from misreading loss as congestion and collapsing its throughput. The cost is some extra bandwidth for parity, so FEC is tuned per path.
• Packet-order correction (POC): On multi-path internet routes, packets often arrive out of order, which TCP mistakes for loss and reacts to with duplicate ACKs and unnecessary retransmits. EdgeConnect re-sequences packets in a small jitter buffer before delivering them in order to the endpoint, keeping TCP calm and throughput high.

Key Term — latency mitigation: The combined effect of hiding or reducing the impact of round-trip time—via local acknowledgments, fewer round-trips per operation, fewer bytes on the high-latency path, and loss masking (FEC/POC)—so that distant resources feel local to users.

Network Memory Deduplication

The most distinctive Boost capability is Network Memory, Silver Peak’s byte-level deduplication technology and the direct descendant of the dedup engine in the legacy NX and VX appliances [Source: Silver Peak Network Memory datasheet, https://www.arubanetworks.com/].

Key Term — Network Memory: Silver Peak’s WAN deduplication technology. Each EdgeConnect maintains a large disk- and memory-based dictionary of previously seen byte patterns; when data recurs, the appliance sends a small reference token instead of the raw bytes, and the far-end appliance reconstructs the data from its own copy of the dictionary.

Key Term — deduplication: Detecting data that has already crossed the WAN and replacing the repeated bytes with small references, so identical content is transmitted in full only once.

The mechanism works like this. As traffic flows through, EdgeConnect breaks it into small chunks and computes a fingerprint (hash) of each chunk. Both the branch and data-center appliances maintain a synchronized dictionary of these fingerprinted chunks. When a chunk’s fingerprint matches one already in the dictionary, EdgeConnect transmits a tiny reference token instead of the full chunk. The receiving appliance looks up the token in its own dictionary and reconstructs the original data locally. The endpoints receive the complete, byte-identical content—they have no idea that most of it never actually crossed the WAN.

Three properties make Network Memory powerful:

1. It is byte-level, not file-level or block-level. This matters more than it sounds. File-level dedup fails the moment a single byte changes; block-level dedup fails if content shifts position. Byte-level dedup still finds the repeated patterns even when content is shifted, repackaged, or embedded across different file types—the same company logo inside a PDF, a PowerPoint, and an email is recognized as the same bytes each time.
2. It is cross-flow and cross-application. The dictionary is shared across all connections and protocols. If ten branch users open the same 50 MB presentation from a central file server, the first open transfers roughly 50 MB across the WAN; subsequent opens may send only a few hundred kilobytes of differences, feeling like local-disk speed. The same effect applies across SMB, NFS, HTTP, email, software updates, and repetitive database traffic.
3. It is bidirectional and symmetric. Because both ends keep caches, dedup works branch-to-data-center, data-center-to-branch, and even branch-to-branch—wherever Boost is enabled at each end.

On repetitive workloads, Network Memory commonly yields 5× to 20× effective (logical) throughput without any change to the physical link—the WAN carries a fraction of the bytes the application thinks it sent.

Figure 6.4: Network Memory deduplication — a diagram showing a first transfer populating identical dictionaries on both EdgeConnect appliances, then a second transfer of the same content crossing the WAN as small reference tokens and being reconstructed from the local dictionary at the far end.

sequenceDiagram
    participant SE as Sending EdgeConnect
    participant RE as Receiving EdgeConnect

    Note over SE,RE: First transfer of the content
    SE->>RE: Full byte chunks (data not seen before)
    Note over SE,RE: Both dictionaries now hold identical fingerprinted chunks

    Note over SE,RE: Second transfer of the same content
    SE->>RE: Small reference tokens instead of repeated bytes
    Note over RE: Reconstructs original data from local dictionary

Compression and Payload Reduction

After deduplication has removed repeated content, the remaining unique data is compressed using an LZ-style algorithm before it crosses the WAN.

Key Term — compression: Encoding data more compactly (typically with an LZ-style algorithm) to reduce the number of bytes transmitted. In Boost it is applied after deduplication, shrinking the unique data that dedup could not eliminate.

The ordering is deliberate and worth memorizing: deduplicate first, then compress. Deduplication eliminates content that has been seen before; compression then squeezes whatever genuinely new bytes remain. Compression is highly effective on text-heavy and structured data—source code, logs, XML, JSON, uncompressed documents, and database traffic—where redundancy within the data itself is high. It offers little benefit on data that is already compressed, such as JPEG images, MP4 video, or ZIP archives, because that data has already had its redundancy squeezed out at the source.

The combined effect of dedup-then-compress is that even traffic that is “all new” to the dictionary still typically crosses the WAN smaller than its original size, lowering utilization on bandwidth-constrained or expensive links (MPLS, satellite, international circuits) and letting them serve more users without an upgrade.

One caveat threads through all of these techniques: encryption. Deduplication, compression, and protocol acceleration all need to see the payload. Traffic that is encrypted end to end—HTTPS to a SaaS provider, SMB3 with encryption enabled—is opaque to EdgeConnect, so dedup and compression gains largely disappear. TCP acceleration, FEC, and packet-order correction can still help because they operate on the transport and packet level, not the payload. This caveat becomes central to the next section’s “when not to use Boost” discussion.

Key Takeaway: Boost’s techniques fall into two camps—send fewer bytes (byte-level Network Memory deduplication, then LZ-style compression) and hide loss and latency (split-TCP acceleration with local ACKs and large windows, protocol acceleration for chatty apps, plus FEC and packet-order correction). The processing order is dedup, then compress; and all payload-based techniques require unencrypted, inspectable traffic.

Measuring the Benefit

Optimization features are only worth their license cost and CPU/disk overhead if they move the needle on the metrics your business cares about. This section explains how to quantify the benefit, gives concrete acceleration examples, and—critically—identifies the situations where Boost adds nothing and standard SD-WAN is the better answer.

Reduction in Bandwidth and Latency

There are two distinct benefits to measure, and they come from different techniques.

Bandwidth reduction comes from deduplication and compression. The headline metric is the deduplication hit ratio or the ratio of pre-optimization bytes to post-optimization bytes sent on the wire. EdgeConnect’s visibility tools in Orchestrator report pre- and post-optimization throughput, dedup ratios, FEC statistics, and packet-order-correction counters [Source: Aruba Orchestrator administration guide, https://www.arubanetworks.com/]. A high dedup ratio (say, 5:1 or better) means the WAN is carrying one-fifth the bytes the applications generated—your effective capacity has multiplied. A low dedup ratio is itself a diagnostic: it usually means the traffic is encrypted or genuinely unique, and Boost’s data-reduction benefit on that flow is limited.

Latency reduction comes from TCP and protocol acceleration. Here the right metric is not bytes but time: file-open time, transaction completion time, or backup-job duration. Because chatty protocols spend their time in round-trips, the meaningful comparison is “seconds to complete this operation, before and after.” A useful diagnostic baseline: if a long-lived TCP flow consistently uses below roughly 30–40% of available bandwidth at an RTT above 50–70 ms despite tunnel bonding and low loss, the bottleneck is latency/protocol inefficiency and Boost is likely to help substantially.

Application Acceleration Examples

Concrete before-and-after scenarios make the value tangible.

• Branch SMB/CIFS file shares to a central data center. Before Boost, over an 80 ms RTT link, opening a large file takes 10–20 seconds because the SMB protocol makes many serial round-trips. After enabling Network Memory plus TCP and protocol acceleration: the first open is faster (protocol round-trips collapsed), and subsequent opens of the same or similar content are near-instant because Network Memory serves most of the bytes from the local dictionary. Effective throughput for file traffic rises 5–10×, and WAN utilization flattens.

• Database replication over an internet VPN. Before Boost, with 2–3% loss and 120 ms RTT, native TCP backs off on every loss event and stalls at a few Mbps on a 100 Mbps link. After enabling FEC, TCP acceleration, and packet-order correction: FEC masks the loss so TCP stops backing off, ordered delivery eliminates spurious retransmits, and effective throughput climbs to roughly 40–60 Mbps—dramatically shortening the replication window and protecting RPO/RTO.

• Cloud-hosted private applications accessed by branches. With an EdgeConnect in the branch and another in the cloud VPC, deduplication and protocol acceleration speed repetitive access while FEC and packet-order correction stabilize variable internet routes. The cloud-hosted app feels on-premises.

When Optimization Is Unnecessary

This is the most important practical lesson in the chapter: Boost is not always the answer, and turning it on indiscriminately wastes license capacity and appliance resources. Standard EdgeConnect SD-WAN—business-intent path control, tunnel bonding, QoS, and path conditioning—is sufficient or even preferable in several common cases.

Boost adds little or no value when:

• Traffic is real-time voice and video. VoIP, WebRTC, Zoom/Teams, softphones, and most VDI are UDP-based or already optimized, and they tolerate latency by design. They benefit from dynamic path conditioning, SLA-based steering, and QoS—not from TCP proxying or dedup. (Indeed, Boost is primarily a TCP technology.)
• Traffic is modern web/SaaS over HTTPS. Microsoft 365, Salesforce, and similar services are end-to-end encrypted (so dedup and compression cannot see the payload) and are engineered to tolerate global latency. For these, direct internet breakout, local DNS, and QoS deliver far more value than WAN optimization. Where the endpoints talk directly to the cloud, there is no second EdgeConnect to optimize against anyway.
• The link is low-latency and already near line rate. When RTT is under about 40–50 ms and large transfers already approach the available throughput, there is little latency to hide and little to gain.
• The data is already compressed or CDN-cached. Already-compressed media (JPEG, MP4, ZIP) and content served from a CDN edge offer minimal dedup or compression headroom.
• Bandwidth is cheap and plentiful. Sometimes adding capacity and relying on tunnel bonding is simpler and more cost-effective than buying and tuning Boost.

A second caution applies to organizations migrating from legacy hardware: do not double-optimize. Running Boost and a legacy NX or VX appliance in series on the same flows adds overhead and can break protocol semantics. As you activate Boost, phase out the standalone WAN-op appliances on those paths.

The practical decision framework, then, runs roughly as follows: classify applications by behavior (real-time and SaaS → usually no Boost; replication, file shares, and legacy client-server → prime Boost candidates), check link characteristics (high RTT with underutilized bandwidth → strong case), measure the user experience or job completion times, evaluate whether encryption will neutralize the data-reduction benefit, pilot Boost on one or two key overlays, and then size and license the pool from the measured gains.

Figure 6.5: Decision flow for using Boost versus standard SD-WAN — a flowchart that classifies a flow by traffic type, encryption, and link characteristics to decide whether to enable Boost or rely on standard SD-WAN path control and QoS.

flowchart TD
    Start["Classify the application flow"] --> RT{"Real-time voice/video or UDP?"}
    RT -->|Yes| StdWAN["Use standard SD-WAN (path conditioning, QoS)"]
    RT -->|No| Enc{"End-to-end encrypted (HTTPS / SaaS)?"}
    Enc -->|Yes| StdWAN
    Enc -->|No| Link{"High RTT with underutilized bandwidth?"}
    Link -->|No| StdWAN
    Link -->|Yes| Both{"Boost enabled at both ends?"}
    Both -->|No| StdWAN
    Both -->|Yes| Boost["Enable Boost (TCP accel, dedup, compression)"]

Key Takeaway: Measure bandwidth benefit via dedup ratio and effective throughput, and measure latency benefit via operation/job completion time. Boost shines on high-latency, repetitive, chatty, or bulk TCP workloads—but for real-time media, encrypted SaaS over direct breakout, low-latency links, and already-compressed data, standard SD-WAN path control and QoS are the right tools. Pilot, measure, then license to fit.

Chapter Summary

This chapter examined EdgeConnect’s WAN optimization and performance layer, delivered through the Boost add-on.

• Boost is a licensed software performance tier, not a separate appliance. It unlocks WAN optimization—TCP acceleration, Network Memory deduplication, and compression—on an EdgeConnect that is already performing SD-WAN. Without it, EdgeConnect does routing, QoS, and path conditioning, but no TCP proxying or dedup cache.
• Boost is the direct successor to the legacy Silver Peak NX (hardware) and VX (virtual) WAN-optimization appliances. Their core functions—Network Memory dedup, TCP acceleration, latency mitigation, and compression—were ported into EdgeConnect, eliminating the need for standalone WAN-op boxes. Avoid double-optimizing by running Boost and NX/VX in series.
• Boost requires both ends and is allocated as a throughput pool. Optimization between two sites occurs only when both appliances are Boost-enabled, and the optimized rate is capped by the smaller of the two allocations. Capacity is a Mbps/Gbps pool assigned per appliance in Orchestrator and reallocated dynamically without hardware changes.
• The techniques split into two goals. Fewer bytes: byte-level Network Memory deduplication (5–20× effective throughput on repetitive data) followed by LZ-style compression. Hide loss and latency: split-TCP acceleration (local ACKs, large windows, WAN-tuned congestion control), protocol acceleration for chatty apps (SMB/CIFS, MAPI, NFS), plus FEC and packet-order correction.
• Encryption is the key limiter. Payload-based techniques (dedup, compression, protocol acceleration) need inspectable traffic; TCP acceleration, FEC, and packet-order correction can still help on encrypted flows.
• Value is measured, not assumed. Use dedup ratio and effective throughput for bandwidth benefit, and operation/job times for latency benefit. Boost is prime for high-latency long-haul links, backup/DR replication, chatty file and email apps, and bulk transfers—and largely unnecessary for real-time media, encrypted SaaS over direct breakout, low-latency links, and already-compressed data.

With path control, segmentation, and now performance optimization covered, the remaining chapters turn to how all of this is operated, monitored, and licensed at scale.

Key Terms

Chapter 7: Licensing Models and Subscription Tiers

Up to this point you have studied how Silver Peak EdgeConnect (now sold as Aruba EdgeConnect under HPE) moves traffic across the WAN — the overlays, the dynamic path control, the segmentation, and the Orchestrator that ties it all together. This chapter answers a different but equally important question: what do you actually buy, and how do you keep it compliant?

Licensing is where networking meets procurement. A design that is technically perfect but licensed incorrectly will either cost too much, throttle production traffic, or fall out of compliance at renewal time. By the end of this chapter you will be able to read an EdgeConnect proposal, understand which feature tier a site needs, size its bandwidth correctly, and explain how the pooled FlexLicense model lets you move capacity around as your network changes.

A note on sources and numbers. The structure of EdgeConnect licensing — the Base/Advanced tiers, the optional Boost add-on, term subscriptions, and the FlexLicense bandwidth pool — is well established and described consistently across Aruba’s documentation. However, specific numeric bandwidth tiers and exact SKU names change between hardware generations and software releases. Where this chapter lists bandwidth tiers such as 50M, 200M, 500M, 1G, 2G, or Unlimited, treat them as commonly-cited representative tiers and confirm the exact values, ceilings, and SKUs against the current official Aruba EdgeConnect SD-WAN data sheet and ordering guide before quoting them to a customer [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect/] [Source: https://www.hpe.com/us/en/aruba-edgeconnect-sd-wan.html]. This chapter does not invent prices or part numbers.

Learning Objectives

After completing this chapter, you will be able to:

• Describe the EdgeConnect licensing tiers — EdgeConnect Base, EdgeConnect Advanced, and add-ons such as the Boost WAN-optimization license.
• Explain the bandwidth-based, term subscription, and pooled (FlexLicense) licensing models and how they differ.
• Map feature entitlements to the appropriate license tier for a given deployment, and size bandwidth and Boost licenses to real-world usage.

Section 1 — License Tiers

EdgeConnect software is licensed along two largely independent axes. The first axis is the feature tier, which determines what the software can do: this is where EdgeConnect Base and EdgeConnect Advanced live. The second axis is bandwidth, which determines how much WAN throughput the appliance is allowed to process (covered in Section 2). On top of both sits the optional Boost license, which unlocks classic WAN optimization. Keeping these axes separate in your mind is the single most useful habit when reasoning about EdgeConnect licensing.

Figure 7.0: EdgeConnect licensing structure — feature tier, bandwidth axis, and optional add-on.

graph TD
    L["EdgeConnect license"] --> FA["Feature tier axis<br/>(what it can do)"]
    L --> BA["Bandwidth axis<br/>(how much throughput)"]
    L --> AO["Optional add-on"]

    FA --> Base["EdgeConnect Base<br/>(complete SD-WAN feature set)"]
    Base --> Adv["EdgeConnect Advanced<br/>(superset: automated security<br/>chaining, larger segmentation,<br/>SaaS/cloud, deep analytics)"]

    BA --> BW["Bandwidth tier<br/>(Mini ... 50M ... Unlimited)"]

    AO --> Boost["Boost<br/>(WAN optimization,<br/>sized in Mbps optimized)"]
    Boost -.attaches to.-> Base
    Boost -.attaches to.-> Adv

Analogy. Think of a streaming service. The plan tier (Standard vs. Premium) decides which features you get — 4K, multiple simultaneous screens, downloads. That is Base vs. Advanced. Separately, your internet speed decides how smoothly any of it actually plays. That is the bandwidth license. And an optional sports add-on you can bolt onto either plan is Boost. You choose each one independently.

EdgeConnect Base entitlements

EdgeConnect Base is the entry feature tier and the foundation of every deployment. It is a complete, production-grade SD-WAN feature set — “Base” does not mean “crippled.” A site licensed with Base can run a fully meshed, secure, application-aware WAN.

Base typically includes:

• Full SD-WAN fabric and overlays — IPsec-encrypted tunnels between EdgeConnect appliances and to hubs and data centers, forming the secure overlay network.
• Dynamic path control across multiple underlays (MPLS, broadband internet, LTE/5G), with per-application steering based on SLA metrics such as latency, loss, jitter, and MOS.
• Application-aware routing — deep-packet-inspection-based application identification, including awareness of common SaaS and IaaS destinations.
• Standard routing protocols — BGP, OSPF, and static routing, plus VRRP and high-availability designs for branch resilience.
• Segmentation — zone- and segment-based policies that provide VRF-like isolation between, for example, guest, corporate, and point-of-sale traffic.
• Integrated stateful firewall — basic Layer 3/Layer 4 policy enforcement at the WAN edge, controlling traffic between segments and the WAN.
• Basic internet breakout — policy-based local egress to the internet, or backhaul to a central site, as the policy dictates.
• Baseline service chaining — the ability to steer traffic into an external security stack (an on-premises next-generation firewall, or a cloud security gateway) using manually configured IPsec or GRE tunnels and policy-based routing.
• Zero-touch provisioning (ZTP) and centralized management through Aruba Orchestrator (historically Unity Orchestrator), including monitoring, alarms, and basic historical reporting.

The one thing Base does not include is WAN optimization. There is no TCP acceleration or data deduplication in Base; performance gains come purely from SD-WAN techniques such as path conditioning and, where the platform supports it, Forward Error Correction (FEC). To get classic WAN optimization you must add Boost (below) [Source: https://www.arubanetworks.com/techdocs/sdwan/].

EdgeConnect Advanced (advanced routing, segmentation, security)

EdgeConnect Advanced is a superset of Base: everything in Base, plus a richer set of security, cloud, and analytics capabilities aimed at larger and more complex deployments. Aruba positions Advanced as the full-featured tier where SD-WAN and security integration meet.

Relative to Base, Advanced typically adds:

• Advanced security service chaining — deeper, more granular, and largely automated policy-based steering to cloud security services, with pre-built integrations and templates for major SASE/SECaaS partners such as Zscaler, Netskope, Palo Alto Prisma, and Check Point. This is the headline feature that distinguishes Advanced from Base.
• Larger-scale and more granular segmentation — more segments, richer per-segment policy, and enhanced role-based segmentation suited to large enterprises and multi-tenant environments.
• Advanced SaaS and multi-cloud steering — automated routing to the nearest SaaS entry point (for example, Microsoft 365 or Salesforce) and automation wizards/templates for building hubs in AWS, Azure, and GCP.
• Richer analytics and automation — longer data retention, more KPIs, role-based dashboards, and expanded REST API/telemetry capabilities, typically realized in combination with a higher-tier Orchestrator entitlement.

A subtle but important point: like Base, Advanced still does not automatically include WAN optimization. Boost remains a separate add-on regardless of tier. Advanced is, however, often the tier chosen for hub and data-center roles precisely because those sites tend to need heavy security chaining and Boost.

Worked example — choosing a tier. A 40-site retail chain runs point-of-sale, store Wi-Fi, and back-office traffic, and sends all internet traffic to a single cloud security provider using a couple of standing tunnels. Core SD-WAN, segmentation, and a basic firewall cover the requirement, and the security integration is simple. EdgeConnect Base fits the stores. The regional data center, however, must steer per-application traffic across three different cloud security services by region and run large-scale segmentation for partner networks — that is a clear case for EdgeConnect Advanced.

Add-ons: Boost and security service chaining

The Boost license is Silver Peak’s classic WAN optimization, delivered as a separate add-on that can be applied to either a Base- or Advanced-licensed appliance. When Boost is licensed and enabled (and the hardware has the capacity), it adds:

• TCP acceleration — window scaling, congestion-control optimization, local ACKs, and loss recovery to blunt the impact of WAN latency and packet loss.
• Data reduction — deduplication (byte caching) and compression of repetitive data crossing the WAN.
• Application/protocol acceleration — optimizations for chatty protocols such as SMB/CIFS file shares and certain legacy client/server applications.

Boost has two characteristics worth memorizing. First, it is licensed in Mbps of optimized traffic per appliance, not as a simple on/off switch, and it is never bundled with Base or Advanced by default. Second, it degrades gracefully: when offered traffic exceeds the licensed Boost capacity, the excess flows are still forwarded with full SD-WAN treatment (path selection, encryption, QoS) — they simply do not receive optimization. Nothing is dropped [Source: https://www.arubanetworks.com/techdocs/sdwan/].

On security service chaining, recall the distinction from the tier discussion: Base supports manual chaining (build a tunnel, write a policy), while Advanced supports integrated, automated, multi-provider chaining with vendor templates. Both can technically service-chain; Advanced makes it scalable and operationally simple.

The table below summarizes the tiers and add-ons.

Figure 7.1: EdgeConnect feature-tier comparison. (Verify exact entitlements against the current Aruba EdgeConnect data sheet, as packaging changes between releases.)

Key Takeaway: EdgeConnect Base is a complete SD-WAN feature set; Advanced is a superset that adds automated, multi-provider security chaining, larger-scale segmentation, richer SaaS/cloud steering, and deeper analytics. Neither tier includes WAN optimization — that always comes from the separately licensed Boost add-on, which can be attached to either tier and degrades gracefully when its capacity is exceeded.

Section 2 — Subscription and Consumption Models

Knowing which features a site needs is only half the licensing picture. You also have to decide how you consume those entitlements — for how long, at what bandwidth, and whether capacity is tied to individual appliances or shared across the estate. EdgeConnect uses a subscription model, sizes capacity by bandwidth tier, and offers the pooled FlexLicense option for portability.

Term-based subscription licensing

A subscription in EdgeConnect is the right to run the software at a specified feature tier and bandwidth for a fixed term — commonly 1, 3, or 5 years. The subscription bundles four things together:

1. Time period — every license has an expiry date.
2. Feature tier — Base or Advanced, plus any Boost add-on.
3. Bandwidth entitlement — the licensed WAN throughput for the appliance (or, with FlexLicense, the pool).
4. Software and support — the right to run the software, access to software updates, and Aruba TAC support for the duration of the term.

This is a deliberate shift from perpetual, buy-it-once licensing toward an OPEX model: you pay per period for bandwidth plus features rather than owning a box “forever.” Three practical consequences follow.

• Expiry behavior. When a term ends without renewal, the appliance does not necessarily fail instantly. Depending on the software version and policy, it may downgrade, enter a grace period, or be flagged non-compliant. You should never plan to rely on grace behavior — treat the expiry date as a hard deadline.
• Co-terming. Organizations usually align all license end-dates so renewals happen in one event. When you add capacity mid-cycle, that add-on is often sold on a shorter term so it expires with everything else.
• Renewal risk. Large deployments — especially big FlexLicense pools — should begin the renewal conversation months early, because letting a pool lapse can put many appliances out of compliance at once.

Analogy. A term subscription is like leasing the WAN rather than buying it. You get the use of it, the maintenance (updates), and roadside assistance (TAC) for the lease period — but you must renew before the lease ends or hand the keys back.

Bandwidth tiers per appliance

The bandwidth tier controls the maximum WAN-side throughput an appliance is licensed to process under SD-WAN — encrypted overlays, tunnel encapsulation, and QoS all count against this limit. Three rules govern bandwidth licensing:

1. It measures aggregate WAN throughput — the sum of traffic across all WAN interfaces — not a per-link or per-port entitlement. An appliance with a 100 Mbps MPLS link and a 200 Mbps internet link is sized for roughly 300 Mbps of aggregate WAN capacity, independent of how many links there are or the up/down split.
2. It is enforced in software regardless of hardware. A licensed limit caps throughput even if the physical box could do more; traffic above the licensed rate is shaped/throttled, not granted for free.
3. You cannot license above the hardware’s capability. Assigning an “Unlimited” tier to a small branch box does not magically yield multi-gigabit performance — the appliance model’s processing limit still applies, especially with strong encryption and many tunnels.

The commonly-cited per-appliance tiers are shown below. Treat the names and ceilings as representative, and confirm them against the current data sheet [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect/].

Figure 7.2: Commonly-cited EdgeConnect bandwidth tiers (representative — verify against the official Aruba data sheet).

Pooled / FlexLicense and portability across appliances

In traditional (non-Flex) licensing, each appliance is bought with a fixed bandwidth tier — “this branch is a 200M, that data center is a 2G.” To upgrade a branch you buy an upgrade license for that specific appliance. This is simple and turnkey for small, stable networks, but rigid: you cannot easily rebalance capacity, and a closed site’s license is stranded.

FlexLicense replaces per-appliance tiers with a pooled bandwidth model. Instead of buying “Appliance X = 200 Mbps, Appliance Y = 1 Gbps,” you buy a single aggregate pool — say, 5 Gbps of WAN bandwidth, Advanced features, 3-year term — for the entire estate. Orchestrator then allocates slices of that pool to individual appliances. This is license pooling, and it is the operational heart of modern EdgeConnect licensing.

Figure 7.4: FlexLicense pooling — Orchestrator draws per-appliance allocations from one shared bandwidth pool.

graph TD
    Pool["Shared bandwidth pool<br/>(e.g. 2 Gbps, Advanced, 3-year term)"]
    Orch["Aruba Orchestrator<br/>(system of record:<br/>allocates and tracks pool)"]
    Pool --> Orch
    Orch -->|"1 Gbps"| HQ["HQ appliance"]
    Orch -->|"500 Mbps"| DC["Data center appliance"]
    Orch -->|"200 Mbps"| BrA["Branch A appliance"]
    Orch -->|"100 Mbps"| BrB["Branch B appliance"]
    Rule["Rule: sum of allocations<br/>must not exceed pool<br/>(here 1800 of 2000 Mbps used)"]
    Orch -.enforces.-> Rule

How the pool works in practice:

• Creation. A purchase produces a license entitlement in Aruba’s licensing backend. You import/sync it into Orchestrator, which then displays the total pool (e.g., 5,000 Mbps), the amount allocated (the sum of per-appliance assignments), and the remaining unused capacity.
• Allocation. Each appliance is assigned a licensed bandwidth value (50, 100, 200, 500 Mbps, 1 Gbps, etc.). Assigning capacity decrements the pool; you can raise or lower an appliance’s value later and the pool adjusts accordingly.
• The core rule. The sum of all per-appliance assigned bandwidths must be less than or equal to the total pool. Orchestrator blocks or flags over-allocation until you add pool capacity.

Worked example — pool arithmetic. You buy a 3-year, 2 Gbps FlexLicense pool and deploy: HQ 1 Gbps + DC 500 Mbps + Branch A 200 Mbps + Branch B 100 Mbps = 1,800 Mbps allocated, 200 Mbps remaining. Business grows, so you bump Branch A from 200 to 300 Mbps → 1,900 Mbps allocated, 100 Mbps remaining. Now you try to raise Branch B from 100 to 300 Mbps (+200 Mbps). That would total 2,100 Mbps — over the 2,000 Mbps pool — so Orchestrator refuses or flags it until you buy more pool capacity.

The decisive advantage of pooling is portability: the license is tied to the estate, not to a serial number. Four common lifecycle scenarios show why this matters:

1. Adding a branch — deploy the new appliance, onboard it, assign (say) 50 Mbps from the pool. Allowed as long as ≥50 Mbps is free.
2. Upgrading a branch — a 50M branch is now sustaining 80–90 Mbps; raise its allocation to 100 Mbps in Orchestrator. No new SKU, just reallocation.
3. Decommissioning a site — zero out that appliance’s allocation; the bandwidth returns to the pool for reuse elsewhere.
4. Replacing hardware (RMA or platform change) — free the old appliance’s allocation, onboard the replacement, and assign it the same bandwidth from the pool. Because the entitlement is not bound to the old serial number, replacement is a reallocation rather than a purchase.

Throughout all of this, Orchestrator is the system of record — it tracks pool size and term, per-appliance allocation, and compliance (allocated vs. pool), and it handles activation and periodic validation with Aruba’s licensing backend. If Orchestrator temporarily loses connectivity to the licensing server, there is usually grace behavior, but connectivity should be restored promptly [Source: https://www.arubanetworks.com/techdocs/sdwan/].

The table below contrasts the two consumption models.

Figure 7.3: FlexLicense (pooled) vs. fixed per-appliance subscriptions.

Key Takeaway: EdgeConnect is sold as a fixed-term subscription (commonly 1/3/5 years) bundling feature tier, bandwidth, updates, and TAC support. Bandwidth is licensed as aggregate WAN throughput per appliance and is enforced in software up to the hardware limit. FlexLicense turns those per-appliance tiers into a shared pool managed by Orchestrator, so capacity becomes portable: the unbreakable rule is that total allocated bandwidth must never exceed the pool.

Section 3 — Planning and Compliance

The final step is operational: sizing licenses to real demand, preserving entitlements through hardware changes, and understanding what support and software rights your subscription buys.

Right-sizing licenses to bandwidth

Oversizing wastes money; undersizing throttles production traffic. The goal is to license to real, measured demand plus sensible headroom. A repeatable method:

1. Measure first. Collect at least a week — ideally 30 days — of WAN throughput per circuit, capturing both peak and 95th-percentile values and the up/down split. Sources include SNMP, NetFlow/IPFIX, interface counters, or stats from an existing SD-WAN device.
2. Compute peak aggregate. For active/active links, sum the peak simultaneously used bandwidth across links; for active/standby, use the peak on the active link.
3. Add headroom. Apply roughly 30–50% on top for growth (1–3 years), plus encryption/encapsulation overhead and bursty traffic.
4. Map to the nearest tier that covers (peak × headroom), then validate against the appliance model’s performance limit — never license above what the hardware can deliver under encryption and tunnel load.

Worked example — sizing a branch. A small branch has two 25 Mbps links in active/active, peaking around 30 Mbps aggregate. Apply 50% headroom: 30 × 1.5 = 45 Mbps. The smallest tier that covers 45 Mbps is 50M. A regional data center with multiple 1 Gbps links peaking at 1.2–1.5 Gbps and growing toward 2–2.5 Gbps maps to 2G or Unlimited.

Boost is sized differently from bandwidth. You size Boost only for the traffic you actually intend to optimize — file shares, backup/replication, chatty latency-sensitive apps — not for total site bandwidth. Estimate the maximum simultaneous optimized traffic, add ~20–30% overhead, and choose the nearest Boost tier. Both ends of an optimized path must have Boost licensed and enabled (for example, both the branch and the data center). Mild undersizing of Boost is acceptable because overruns degrade gracefully — excess flows simply forgo optimization rather than failing. Boost adds limited value on pure internet/SaaS traffic (especially encrypted web) and on very high-bandwidth, low-latency links; it pays off on high-latency, constrained links such as MPLS, long-haul, and satellite [Source: https://www.arubanetworks.com/techdocs/sdwan/].

A common, sensible strategy under FlexLicense is to start conservative and upgrade later: deploy branches at a modest tier (e.g., 50M), monitor with Orchestrator’s historical graphs, and reallocate pool capacity upward only when usage consistently approaches the cap.

License portability when replacing hardware

Hardware changes are inevitable: an appliance fails and is RMA’d, or a growing site moves to a larger model. This is where FlexLicense’s decoupling of license from serial number pays its biggest operational dividend.

With fixed per-appliance licensing, the entitlement is associated with a specific device, so replacement can require re-licensing the new unit — friction at exactly the wrong moment. With FlexLicense, the steps are simply: remove (zero) the failed appliance’s allocation so its bandwidth returns to the pool, onboard the replacement into Orchestrator, and assign it the same bandwidth from the pool. No new bandwidth SKU is consumed, because the pool total is unchanged — you have merely moved an allocation from one box to another. The same mechanism makes platform upgrades and site relocations routine reallocations rather than purchasing events.

Worked example — RMA under FlexLicense. A 200M branch appliance fails on a Friday. In Orchestrator you remove its allocation; the 200 Mbps drops back into the pool. The replacement arrives, is onboarded via ZTP, and you assign it 200 Mbps from the pool. Total pool consumption is identical to before the failure, and no procurement ticket was needed.

Support and software entitlement (TAC, updates)

The subscription is not only a right to run the software — it is also your entitlement to support and software maintenance for the term. Concretely, an active subscription typically grants:

• Aruba TAC support for the licensed appliances and features during the subscription term.
• Software updates and upgrades — access to new releases, fixes, and security patches for the entitled feature tier.
• The legal right to operate the software at the licensed feature tier and bandwidth.

The compliance implication is direct: support and update rights are tied to the term. When a subscription lapses, you lose not just feature/bandwidth entitlement but also the right to open TAC cases and download updates. This is a major reason to manage renewals proactively and to co-term licenses so the whole estate stays supported together. For the authoritative statement of what a given subscription includes — covered features, support response targets, and update rights — consult the current Aruba EdgeConnect data sheet, the Aruba Orchestrator administration guide, and the HPE/Aruba ordering and support documentation, since these terms evolve by release and offering [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect/] [Source: https://www.arubanetworks.com/techdocs/sdwan/] [Source: https://www.hpe.com/us/en/aruba-edgeconnect-sd-wan.html].

Key Takeaway: Right-size by measuring real WAN usage, adding 30–50% headroom, and mapping to the nearest tier within hardware limits — sizing Boost separately and only for optimize-worthy traffic. FlexLicense makes hardware replacement a pool reallocation rather than a purchase, and the subscription term is what keeps TAC support and software updates flowing, so renewals must be managed before they lapse.

Chapter Summary

EdgeConnect licensing is best understood as two independent axes plus an add-on. The feature axis offers EdgeConnect Base — a complete SD-WAN feature set with overlays, dynamic path control, application-aware routing, standard routing protocols, segmentation, a basic firewall, internet breakout, ZTP, and central management — and EdgeConnect Advanced, a superset that adds automated multi-provider security service chaining, larger-scale segmentation, advanced SaaS/multi-cloud steering, and deeper analytics. Neither tier includes WAN optimization; that comes only from the separately licensed Boost add-on, which is sized in Mbps of optimized traffic and degrades gracefully when exceeded.

The consumption side uses fixed-term subscriptions (commonly 1/3/5 years) that bundle feature tier, bandwidth, software updates, and TAC support. Bandwidth is licensed as aggregate WAN throughput per appliance — measured across all WAN links, enforced in software, and never permitted to exceed the hardware’s capability. The commonly-cited tiers (Mini, 50M, 200M, 500M, 1G, 2G, Unlimited) should always be verified against the current Aruba data sheet. FlexLicense converts per-appliance tiers into a shared bandwidth pool managed by Orchestrator, governed by one rule: total allocated bandwidth must never exceed the pool. Pooling makes licenses portable — adding, upgrading, decommissioning, and replacing appliances become reallocations rather than purchases.

On planning and compliance, right-size by measuring 1–30 days of peak/95th-percentile usage, adding 30–50% headroom, and mapping to the nearest tier within model limits; size Boost separately for only the traffic worth optimizing, licensed at both ends. FlexLicense turns hardware RMA into a simple pool reallocation, and the subscription term is what keeps support and updates active — making proactive, co-termed renewals an operational necessity rather than an afterthought.

Key Terms

Chapter 8: Orchestrator and Centralized Management

In the earlier chapters you learned what the EdgeConnect appliance is and how its overlays, paths, and optimization features behave at a single site. This chapter answers a different question: how do you manage hundreds of those appliances without logging into each one? The answer is Orchestrator — the centralized management plane that turns a fleet of EdgeConnect devices into a coherent, policy-driven SD-WAN fabric. By the end of this chapter you will be able to navigate Orchestrator’s core functions, deploy new sites with zero on-site expertise, and read the dashboards that tell you whether your network is healthy.

Learning Objectives

By the end of this chapter, you will be able to:

• Navigate the core functions of Orchestrator for configuration, monitoring, and reporting.
• Explain zero-touch provisioning (ZTP) and template/preconfig-based deployment end to end.
• Use Orchestrator dashboards and reports to monitor fabric health and application performance.

8.1 Orchestrator Overview

Orchestrator (originally branded Unity Orchestrator, now Aruba Orchestrator under HPE/Aruba) is the centralized management and orchestration plane for EdgeConnect SD-WAN appliances. It provides policy-driven configuration, device grouping, real-time monitoring, alarms, and granular access control from a single console [Source: https://www.arubanetworks.com/products/sd-wan/orchestrator/].

The defining principle is the single pane of glass. Administrators work almost entirely inside Orchestrator; the appliances themselves are normally not configured directly except for the most basic bootstrap settings (an initial IP address, for example). Each EdgeConnect appliance establishes a secure, out-of-band control connection to Orchestrator — typically over HTTPS/TLS — and through that channel Orchestrator stores and manages three categories of information: configuration objects (WAN labels, overlays, QoS and routing policies, templates), live appliance state (tunnels, interfaces, routes, flows, performance statistics), and events, alarms, and historical statistics [Source: https://www.arubanetworks.com/techdocs/sdwan-Orch/].

The payoff is policy-based intent instead of per-box command-line work. Rather than typing routing and QoS commands into 200 routers, you express an intent once — “all voice traffic should use the best-quality path” — and Orchestrator computes and pushes the device-specific configuration everywhere. Changes are validated through consistency checks before they reach the appliances, and rollouts can target one device, a group, or an entire tenant.

Analogy: Think of Orchestrator as the conductor of an orchestra. The musicians (EdgeConnect appliances) each play their own instrument, but they don’t decide independently when to come in or how loud to play. The conductor reads from one score (the policy), cues each section, and keeps the whole performance in sync. Configuring each appliance by hand would be like asking every musician to improvise and hoping they stay in tune.

Deployment Options: On-Prem, Cloud, and SaaS

Orchestrator can be deployed in three broad ways, and the choice affects who owns the infrastructure and how it scales:

In all models the management plane is logically the same product; the difference is who operates the server. The SaaS model is closely tied to the Global Cloud Portal, which (as you will see in Section 8.2) is also the rendezvous point for zero-touch provisioning.

Figure 8.1: Orchestrator deployment models — on-prem virtual appliance, customer-hosted cloud VM, and vendor-hosted SaaS — each managing the same EdgeConnect fleet over HTTPS/TLS.

flowchart LR
    subgraph Models["Orchestrator Deployment Models"]
        OnPrem["On-Premises Virtual Appliance<br/>(ESXi / KVM / Hyper-V)"]
        CloudVM["Customer-Hosted Cloud VM<br/>(AWS / Azure)"]
        SaaS["Vendor-Hosted SaaS<br/>(Global Cloud Portal)"]
    end

    subgraph Fleet["Same EdgeConnect Fleet"]
        EC1["EdgeConnect<br/>Branch A"]
        EC2["EdgeConnect<br/>Branch B"]
        EC3["EdgeConnect<br/>Data Center"]
    end

    OnPrem -- "HTTPS / TLS" --> Fleet
    CloudVM -- "HTTPS / TLS" --> Fleet
    SaaS -- "HTTPS / TLS" --> Fleet

Role-Based Access Control and Multi-Tenancy

Real networks are run by teams, not individuals, so Orchestrator supports RBAC (role-based access control) to govern who can see and change what.

Authentication can be handled by local users defined in Orchestrator, or delegated to external systems via RADIUS or TACACS+ for centralized AAA; many deployments also integrate SAML/SSO depending on version and licensing. A role controls two independent things: which functions a user may perform (full administration, configuration only, monitoring only, read-only) and which objects they may touch (all appliances, or only a subset scoped by group, region, or tenant).

Common role archetypes include:

• Super Admin — full access to Orchestrator, every appliance, all templates, and (in MSP mode) tenant definitions.
• Network Engineer / Designer — creates and edits overlays, templates, and groups, and pushes configuration, usually scoped to one tenant or region.
• NOC Operator — monitors dashboards, acknowledges and clears alarms, and runs reports, but cannot change configuration.
• Read-Only / Auditor — visibility only, for compliance or oversight.

Multi-tenancy (often called MSP mode) extends RBAC into full logical isolation. A global administrator creates tenants — for example Customer-ACME or Business-Unit-EMEA — assigns appliances to each, and allocates per-tenant templates and resources. Each tenant then sees only its own appliances, groups, overlays, reports, and alarms; configurations, logs, and statistics are logically separated. This is what lets a managed service provider run dozens of customers from one Orchestrator while guaranteeing that Customer A never sees Customer B’s data.

Example: A regional MSP onboards a new client, Northwind Retail. The global admin creates a tenant, assigns Northwind’s future appliance serial numbers to it, applies a retail-store template, and creates two scoped operator accounts for Northwind’s internal IT. Northwind’s staff log in and see only their 40 stores — never the MSP’s other 1,500 managed sites.

Key Takeaway: Orchestrator is the single pane of glass for the EdgeConnect fabric: appliances connect to it over secure TLS, administrators express policy centrally, and RBAC plus optional multi-tenancy control exactly who can configure or view each slice of the network.

Configuration Templates and Apply Groups

Orchestrator scales configuration through a hierarchical model combined with grouping. Every appliance’s running configuration — its effective configuration — is the sum of three layers:

1. Global objects shared across the fabric: application definitions, Business Intent Overlays (BIOs), QoS and optimization policies, underlay/path definitions, and default routing or security policy.
2. Group-level configuration shared by a collection of similar appliances: interface and VLAN definitions, routing protocol defaults (OSPF/BGP), WAN labels and tunnel settings, and system parameters such as DNS, NTP, SNMP, and logging.
3. Appliance-specific overrides layered on top: local IP addressing, site-specific static routes, unique identities or keys, and per-site bandwidth caps.

Effective configuration = Global + Group + Appliance override, validated on each device before it takes effect.

Groups (called Appliance Groups in the UI) are logical containers for appliances that should share a baseline — grouped by site type, region, connectivity type, or tenant. Names like Branch-Small, Branch-Large, DataCenter, or EMEA-MPLS are typical.

The apply groups operation is how staged changes reach devices. When you edit a group-level setting — say, you raise the DSCP marking for the Voice overlay or change a WAN bandwidth — that change lives only in Orchestrator until you explicitly apply it. Applying the group recomputes each member’s effective configuration and pushes it out. Three behaviors make this safe at scale:

• Inheritance with override — group settings become the default for all members, but any existing per-appliance override is preserved unless you deliberately reset it.
• Staged review — many teams edit the group, review the diff or compliance report, and click Apply only during a maintenance window.
• Selective apply — you can apply to a subset (a few pilot branches) before rolling out to the whole group.

Templates are reusable configuration blocks — interface/VLAN structure, routing neighbors and timers, WAN circuit definitions, firewall rules — that can be attached to groups or appliances. The best practice is to maintain a small number of strong templates (one per site type), use them for 90–95% of every device’s configuration, and reserve per-appliance overrides for the genuinely unique values like a branch’s local subnet.

Figure 8.2: Configuration inheritance — global objects flow into appliance groups, group settings flow into individual appliances, and per-device overrides sit on top, producing the effective configuration validated on each box.

graph TD
    Global["Global Objects<br/>(Overlays, QoS, Apps, Routing Defaults)"]
    GroupA["Appliance Group: Branch-Small<br/>(Interfaces, VLANs, WAN Labels, NTP/DNS)"]
    GroupB["Appliance Group: DataCenter<br/>(Interfaces, VLANs, WAN Labels, NTP/DNS)"]
    Override1["Appliance Override<br/>(Local IP, Static Routes, Bandwidth Cap)"]
    Override2["Appliance Override<br/>(Local IP, Static Routes, Bandwidth Cap)"]
    Effective["Effective Configuration<br/>(Validated on Each Appliance)"]

    Global --> GroupA
    Global --> GroupB
    GroupA --> Override1
    GroupB --> Override2
    Override1 --> Effective
    Override2 --> Effective

Example: To raise the direct-internet-access circuit on every small branch from 20 Mbps to 50 Mbps, an engineer edits the Branch-Small group’s WAN interface and sets bandwidth to 50 Mbps. Orchestrator lists the 30 appliances that will be affected. The engineer clicks Apply but selects only three pilot sites, watches their path utilization and tunnel metrics for a day, then applies to the remaining 27 — all without touching a single appliance directly.

Key Takeaway: Configuration is layered (global, group, appliance) and rolled out through apply-groups; templates standardize the bulk of the configuration so that adding a site means assigning a template and a few site-specific variables, not hand-building a router.

8.2 Provisioning Workflows

Centralized configuration solves the ongoing management problem. Zero-touch provisioning (ZTP) solves the initial deployment problem: how to bring a brand-new appliance online at a remote site where nobody on the ground knows anything about SD-WAN.

Zero-Touch Provisioning End to End

The goal of ZTP is that a factory-default EdgeConnect appliance can be shipped to a branch, plugged in by non-technical staff, and automatically come up fully configured — no CLI, no local GUI, no expert truck-roll. This works through a rendezvous between three actors: the appliance, the Global Cloud Portal, and your Orchestrator [Source: https://www.arubanetworks.com/techdocs/sdwan-Orch/].

The Global Cloud Portal is the cloud service that maintains your customer account and entitlements, tracks appliance inventory (serial numbers, models, licenses), tracks your registered Orchestrator instances, and acts as the phone-home rendezvous point. Conceptually, its job during ZTP is to answer one question: “This serial number belongs to which customer, which Orchestrator should it talk to, and does it have an initial config?”

The end-to-end flow proceeds in five stages:

The result is an appliance in production within minutes, configured entirely from policy that lived in Orchestrator before the box ever shipped.

Figure 8.3: ZTP rendezvous sequence — appliance boots and gets DHCP/DNS, phones home to the Global Cloud Portal, is redirected to the correct Orchestrator, then receives its full template-based configuration.

sequenceDiagram
    participant Appliance as EdgeConnect Appliance
    participant DHCP as DHCP / DNS
    participant Portal as Global Cloud Portal
    participant Orch as Orchestrator

    Appliance->>DHCP: Power on (factory default), request IP
    DHCP-->>Appliance: Assign IP, gateway, DNS
    Appliance->>Portal: Phone home over outbound HTTPS (built-in certificate)
    Portal->>Portal: Match serial number to customer account
    Portal-->>Appliance: Return Orchestrator address and preconfig
    Appliance->>Appliance: Apply preconfig locally
    Appliance->>Orch: Connect and identify (serial / certificate)
    Orch-->>Appliance: Push template / deployment profile (interfaces, routing, BIOs, QoS)
    Note over Appliance,Orch: Appliance joins the SD-WAN fabric in production

Analogy: ZTP is like a new employee’s badge activating itself on the first day. The badge (appliance) is shipped blank. When it’s first swiped (powered on), it contacts HR’s central directory (Cloud Portal), which recognizes the employee ID, looks up which office and department they belong to (the Orchestrator and template), and provisions their building access, email, and software automatically — no IT technician walks them through setup desk by desk.

A short list of prerequisites prevents most ZTP failures: the appliance needs internet reachability with working DNS and outbound HTTPS allowed through any firewall or proxy; the Orchestrator must be correctly registered in the portal; certificate names must match; and clocks must be roughly correct, because a large time skew breaks TLS certificate validation.

Preconfiguration Files and YAML

A preconfiguration (or preconfig) file is a minimal, device-specific configuration “stub” delivered during ZTP. Its purpose is to give the appliance just enough site-specific identity to come up in the right place and reach Orchestrator, before the full template is applied. Preconfigs are commonly authored in a structured format — historically XML/JSON fragments, and increasingly YAML, which is human-readable and easy to template and diff in version control.

Typical preconfig contents include:

• Identity — hostname, site name/ID, and location metadata (city, country, region).
• Network basics — management IP/subnet and gateway (if not pure DHCP), DNS servers, domain search list, NTP servers, and time zone.
• Interface roles — which ports are LAN vs WAN, VLAN tagging and addressing, and WAN-link labels (Internet, MPLS, LTE).
• Bootstrap — the Orchestrator FQDN/IP and any bootstrap token, where not handled solely by the portal.

A minimal preconfig might look like this in YAML form:

hostname: BR-NYC-01
site:
  name: New York Branch 01
  region: AMER
management:
  ip: 10.10.1.2/24
  gateway: 10.10.1.1
  dns: [10.10.0.53, 10.10.0.54]
  ntp: [time.example.com]
interfaces:
  wan0: { role: wan, label: INTERNET, dhcp: true }
  wan1: { role: wan, label: MPLS, ip: 172.16.5.2/30 }
  lan0: { role: lan, vlan: 20, ip: 10.10.20.1/24 }
orchestrator:
  fqdn: orch.example.com

Note what is absent: there are no overlay policies, QoS classes, or routing intent here. Those come from the template. The preconfig carries only the values that genuinely differ from one site to the next.

Preconfigs are generated three common ways: from a golden reference appliance whose variable fields (IPs, names) are marked as parameters and exported; from a template wizard that asks for a site type and variables and emits one file per appliance; or from a bulk CSV/spreadsheet listing branch names, IPs, and WAN details, from which Orchestrator mass-generates one preconfig per device. Each preconfig is uploaded to the Cloud Portal and associated with a specific appliance serial or deployment profile so it is delivered during phone-home.

Bulk Deployment and Staging

ZTP shines when you deploy many sites at once. Consider a 50-branch rollout:

1. Design templates in Orchestrator — for example one Branch_Template with two WAN interfaces (INTERNET and MPLS), two LAN VLANs (Users and Voice), OSPF, and BIO policies steering SaaS, Voice, and bulk traffic. Parameterize the LAN subnets and WAN bandwidths so each site fills in its own values.
2. Generate preconfigs in bulk — one per branch, from a spreadsheet of site names, hostnames, management IPs, and WAN circuit details.
3. Set up the Cloud Portal — confirm Orchestrator is registered, claim all 50 serial numbers, upload and associate each preconfig, and attach the Branch_Template deployment profile.
4. On site — local staff rack the appliances, connect LAN and WAN circuits, and power on. DHCP supplies the initial address and DNS.
5. ZTP runs — each appliance phones home, is redirected to Orchestrator, applies its preconfig, and receives the template plus site parameters automatically.

Two staging strategies handle sites that cannot reach the cloud immediately. USB/console pre-staging loads a full configuration onto the appliance in the lab before shipping, so it arrives ready to run with no phone-home. A hybrid approach stages core configuration (system, WAN, overlay) in the lab and leaves branch-specific parameters as Orchestrator variables to be filled in later. Both are common where a site has no initial internet, where outbound traffic is heavily restricted, or where compliance rules limit cloud reachability. For automation at scale, Orchestrator also exposes REST APIs so onboarding, bulk configuration, and reporting can be driven from IPAM/CMDB systems or CI/CD pipelines — the “network as code” pattern.

Example: A common ZTP misfire: an appliance is claimed under the wrong customer account, or the Orchestrator’s certificate FQDN doesn’t match its registration. The box boots, gets DHCP, phones home — and then either fails to find an Orchestrator or is sent to the wrong one. The fix is in the portal (correct the claim and registration), not on the appliance, which is exactly the point of zero-touch.

Key Takeaway: ZTP separates what is unique per site (a small preconfig of identity and IPs) from what is common (templates and overlays in Orchestrator), letting non-technical staff bring up dozens of sites by simply plugging them in, while staging and APIs cover offline and automated scenarios.

8.3 Monitoring, Reporting, and Visibility

Once the fabric is deployed, Orchestrator becomes the central telemetry and analytics hub. It collects state and statistics from every appliance and presents them through dashboards, topology views, alarms, and historical reports — giving operations teams end-to-end visibility without logging into individual boxes.

Health Dashboards and Alarms

The top-level view is a fabric health dashboard: an at-a-glance summary of appliance status, tunnel health, link state, CPU and memory, and policy/SLA compliance. A topology view renders the logical SD-WAN overlay as a map of sites, hubs, and data centers with color-coded health indicators per tunnel and per SLA, so a degraded or down path is visible instantly. From any element you can drill down into a single appliance to see live interface counters, CPU/memory, tunnel status, flow lists, and per-application breakdowns.

Alarms are how Orchestrator surfaces problems proactively. It aggregates and manages alarms from all appliances, organized roughly into four families:

A central alarm dashboard lets operators view active and cleared alarms, filter by site, severity, or type, and acknowledge or clear them with notes. Critically, alarms and events can be forwarded to email, to a network management system via SNMP traps, and to syslog/SIEM platforms — so SD-WAN events flow into the same operations tooling and ticketing systems used for the rest of the environment.

Figure 8.4: Orchestrator fabric health dashboard — color-coded topology map, an alarm summary panel by severity, and per-site drill-down into tunnel and resource metrics.

Application and Flow Visibility

Because EdgeConnect is application-aware, Orchestrator can break traffic down by application rather than just by interface. Application visibility dashboards show per-application traffic volume, bandwidth, session counts, and QoS class across the whole fabric, along with views of top applications, top talkers, and traffic distribution by app, site, user, or WAN link. Alongside the volume data, application performance indicators — latency, loss, and jitter along the chosen path — help an operator distinguish a network problem from an application problem.

Example: A help-desk ticket says “the ERP system is slow at the Dallas branch.” In Orchestrator the operator opens Dallas, sees that the ERP application’s path has 4% loss and elevated jitter on the MPLS underlay while the internet underlay is clean, and confirms the overlay failed traffic over correctly. The data points to a carrier issue on the MPLS circuit — not the ERP servers — so the ticket is routed to the WAN provider with evidence attached.

Boost and Bandwidth Utilization Reports

Bandwidth and circuit utilization reports show Tx/Rx rates, volume transferred, and peak/average utilization per site, per appliance, per WAN link, and per tunnel, over selectable time windows (hour, day, week, month). Views of the top sites, tunnels, or interfaces by throughput make congestion and oversubscription easy to spot, and every chart supports drill-down from the global fabric view to an individual link.

For sites that license Boost (the WAN optimization capability covered earlier in the book), Orchestrator provides dedicated visibility into its benefit: where Boost is enabled, optimized versus unoptimized bytes, compression and deduplication ratios, and per-application and per-site savings in bandwidth and round-trip time. Session-level views confirm that the intended applications (file transfers, CIFS, HTTP/S) are actually being optimized. This is what lets a team quantify the return on a Boost license rather than taking the savings on faith.

Finally, all of this is available as historical reporting. Time-series graphs for tunnel performance, application usage, and link utilization support capacity planning (“which branches will outgrow their circuits next quarter?”) and before/after comparisons (“how much did enabling Boost reduce WAN volume?”). Reports can be scheduled or run on demand and exported (PDF/CSV) for SLA reporting to management. In the cloud-hosted model, the Cloud Portal aggregates these reports across multiple tenants or organizations — the view an MSP needs to report uptime and usage to many customers at once [Source: https://www.arubanetworks.com/products/sd-wan/orchestrator/].

Figure 8.5: Boost optimization report — a stacked time-series of optimized versus unoptimized bytes with the resulting compression/dedup ratio and bandwidth saved per application.

Key Takeaway: Orchestrator turns raw appliance telemetry into actionable visibility — health dashboards and alarms for proactive operations, application and flow views to isolate problems, and bandwidth and Boost reports (live and historical) for troubleshooting, capacity planning, and SLA reporting.

Chapter Summary

Orchestrator is the centralized management plane that makes a fleet of EdgeConnect appliances behave as one coherent SD-WAN fabric. Appliances connect to it over a secure out-of-band TLS channel, and administrators work almost entirely within its single pane of glass, expressing policy-based intent rather than configuring boxes one CLI command at a time. Orchestrator can be deployed on-premises, in a customer-hosted cloud, or as a vendor-managed SaaS, and it controls access through RBAC — roles scoped by both function and object — with an optional multi-tenant (MSP) mode that fully isolates each tenant’s appliances, configuration, and data.

Configuration follows a layered model — global objects, group settings, and per-appliance overrides combine into each device’s effective configuration — and changes are rolled out through the apply-groups operation, with staged and selective rollout to protect production. Templates standardize the bulk of every site’s configuration so that deployment becomes a matter of assigning a template and a handful of variables.

That deployment is automated by zero-touch provisioning: a factory-default appliance boots, phones home to the Global Cloud Portal, is redirected to the correct Orchestrator, applies a minimal preconfiguration file of site-specific identity and addressing (often authored in YAML), and then receives its full template-based configuration — all with no on-site expertise. Bulk rollouts, USB/console pre-staging, hybrid staging, and REST-API automation cover the remaining scenarios.

Finally, Orchestrator is the visibility hub. Health dashboards and a color-coded topology view surface fabric status; alarms for availability, performance/SLA, system health, and configuration issues drive proactive operations and forward to email, SNMP, and SIEM; application and flow visibility isolates problems by app rather than by interface; and bandwidth and Boost reports — live and historical — support troubleshooting, capacity planning, and SLA reporting, aggregated across tenants in the cloud-hosted model.

Key Terms

Chapter 9: Security, Segmentation, and SASE Integration

Up to this point, we have treated Silver Peak / Aruba EdgeConnect primarily as a networking platform — a fabric that steers application traffic intelligently across MPLS, broadband, and LTE underlays. But a WAN edge that can reach the internet directly from every branch is also a WAN edge that must secure that internet edge. Backhauling every packet to a central firewall used to be the easy answer; in a cloud-first world, it is the slow and expensive one. This chapter examines how EdgeConnect bakes security and isolation directly into the fabric, how it hands deep inspection off to cloud security services, and how the whole arrangement adds up to a Secure Access Service Edge (SASE) architecture.

Learning Objectives

By the end of this chapter, you should be able to:

• Describe EdgeConnect’s built-in stateful firewall, segmentation model, and zone-based security policies.
• Explain service chaining to cloud security services and the unified SASE story.
• Outline integration with Aruba SSE and third-party cloud security providers (Zscaler, Netskope, Check Point).

Built-in Security

A defining feature of EdgeConnect (formerly Silver Peak Unity EdgeConnect) is that security is not a separate appliance bolted onto the WAN edge — it ships inside every appliance. Each EdgeConnect device includes an integrated stateful, zone-based firewall and a segment-based fabric that together provide both macro-segmentation (VRF-like isolation across the WAN) and micro-segmentation (fine-grained zone-to-zone policy) [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect-enterprise/].

Zone-based stateful firewall

A stateful firewall is one that tracks the state of each network session rather than inspecting packets in isolation. Where an old-fashioned stateless access control list (ACL) evaluates every packet against a static rule, a stateful firewall remembers that a connection was opened — it follows the TCP handshake (SYN, SYN-ACK, ACK), watches TCP flags, and maintains “pseudo-sessions” for connectionless UDP flows. The practical payoff is large: because the firewall knows a session is already established, return traffic is permitted automatically. You generally write policy only in the initiating direction, and the matching reply path opens itself [Source: https://www.arubanetworks.com/techdocs/sdwan/docs/EC_Orchestrator/].

Analogy: A stateless ACL is like a bouncer who checks an ID against the guest list every single time someone walks through the door, including people leaving and coming right back. A stateful firewall is a bouncer who stamps your hand on the way in — once you are a known guest, your trips in and out are remembered, and only new arrivals get re-checked.

EdgeConnect’s firewall is zone-based rather than merely interface-based. A zone-based firewall groups interfaces or VLANs into logical zones that share a common trust level, then writes policy between those zones instead of between physical ports. A zone might be Corp_LAN, Guest, IoT, WAN, DC, or Internet. Every physical interface or VLAN sub-interface is assigned to a zone (its security/policy anchor) and to a segment (its routing context). Rules are then expressed as zone-to-zone statements:

Source: Segment=Corp, Zone=Corp_LAN → Dest: Segment=Corp, Zone=Internet → allow HTTP/HTTPS; deny everything else.

Policy granularity is rich. Rules can match on source/destination IP, subnet, VLAN, port, protocol (Layer 3/4), and recognized applications or application groups (Layer 7, via EdgeConnect’s application-identification engine). Available actions are allow, deny, or send to service — the last of which redirects matching traffic to an external next-generation firewall (NGFW) or cloud secure web gateway, the service-chaining behavior we explore in the next section. Permit and deny decisions can be logged and viewed centrally in Orchestrator, filtered by application, segment, zone, or site [Source: https://www.arubanetworks.com/techdocs/sdwan/docs/EC_Orchestrator/].

The usual default posture is deny by default, allow by exception between zones, with intra-zone traffic typically more permissive (and configurable). The biggest operational benefit of the zone model is that policies become topology-independent — written in terms of zones and segments rather than specific interfaces or IP ranges. A single Guest-to-Internet rule can apply identically across hundreds of branches, no matter how each site’s IP addressing happens to be laid out.

Figure 9.1: Stateful zone-to-zone firewall — interfaces/VLANs at a branch mapped into trust zones (Corp_LAN, Guest, IoT, Internet), with arrows showing an allowed Corp_LAN → Internet session and the auto-permitted return path, alongside a denied Guest → Corp_LAN attempt.

graph TD
    subgraph Branch["Branch Interfaces / VLANs"]
        V10["VLAN 10 Corp Users"]
        V20["VLAN 20 Guest Wi-Fi"]
        V30["VLAN 30 IoT Devices"]
    end

    V10 --> ZCorp["Zone: Corp_LAN"]
    V20 --> ZGuest["Zone: Guest"]
    V30 --> ZIoT["Zone: IoT"]

    FW{{"Stateful Zone-Based Firewall"}}

    ZCorp --> FW
    ZGuest --> FW
    ZIoT --> FW

    FW -- "Allow HTTP/HTTPS (new session)" --> ZInet["Zone: Internet"]
    ZInet -. "Return traffic auto-permitted" .-> ZCorp
    FW -- "DENY Guest to Corp_LAN" --> Drop["X Dropped"]

Routing segmentation as micro-segmentation

EdgeConnect layers two kinds of isolation. The coarse layer is the segment, which behaves like a Virtual Routing and Forwarding (VRF) instance for the SD-WAN fabric. Each segment owns its own routing table, its own set of overlays (the tunnels built between sites), and its own policy context — its own firewall rules, business-intent overlays, and service-insertion settings. Typical segments are Corp, Guest, IoT, PCI, OT (industrial control / SCADA), and Voice. Critically, traffic in one segment does not reach another by default; there is no inter-segment routing unless you explicitly build an inter-segment gateway or configure route leaking plus policy. This is the macro security boundary — the guarantee that “Guest can never reach Corp or PCI across the WAN” [Source: https://www.arubanetworks.com/techdocs/sdwan/docs/EC_Orchestrator/].

The fine layer is the zone, which lives inside exactly one segment. Micro-segmentation — the practice of dividing a network into small, individually-policed compartments so that a breach in one cannot spread laterally — is implemented through zone-to-zone rules within (and, carefully, across) segments. Consider a Corp segment carved into the zones Corp_User_LAN, Corp_Server, and Corp_Management:

When two segments genuinely need to talk — say, IoT sensors that must report to a Corp application — you keep IoT as its own segment, route the controlled traffic through a gateway at a hub or data center that participates in both segments (or leaks specific prefixes), and write an explicit, narrow rule such as Segment=IoT, Zone=IoT_LAN → Segment=Corp, Zone=Corp_Server allow MQTT/HTTPS to one subnet, deny everything else.

Analogy: Think of a segment as a separate building on a corporate campus — each with its own address book (routing table) and locked perimeter; you cannot wander from the Guest building into the PCI building because there is no connecting corridor. Zones are the locked rooms inside each building. Even an authorized employee in the user room cannot stroll into the server room or the IT management room without a specific key for a specific door.

Figure 9.2: Segments vs. zones — two stacked VRF “containers” (Corp, Guest) shown as isolated routing planes, each subdivided into trust zones, with a single explicitly-configured inter-segment gateway drawn as the only path between them.

graph TD
    subgraph SegCorp["Segment: Corp (own routing table)"]
        CU["Zone: Corp_User_LAN"]
        CS["Zone: Corp_Server"]
        CM["Zone: Corp_Management"]
        CU -- "Allow app groups" --> CS
        CU -- "Deny all" --> CM
        CS -- "Allow RDP/SSH from jump hosts" --> CM
    end

    subgraph SegGuest["Segment: Guest (own routing table)"]
        GU["Zone: Guest_LAN"]
        GI["Zone: Guest_Internet"]
        GU -- "Allow web only" --> GI
    end

    GW{{"Explicit Inter-Segment Gateway (only path)"}}
    SegCorp -. "No default inter-segment routing" .-x SegGuest
    SegGuest --- GW
    GW --- SegCorp

A typical branch interface map makes the relationship concrete:

Identity and role-based segmentation

Segments and zones isolate traffic by where it connects from, but modern zero-trust design increasingly wants to police by who the user is. EdgeConnect extends its segmentation model with identity by aligning on a shared identity provider (IdP) — Azure AD, Okta, or Aruba ClearPass — so that policy can be written in terms of users and roles rather than IP addresses. A useful pattern is to map Aruba wired/wireless ClearPass roles into EdgeConnect segments and zones: a user authenticated as “Contractor” lands in the Guest segment, while a “Finance” user lands in a PCI-adjacent zone, with the firewall enforcing the resulting trust level automatically [Source: https://www.arubanetworks.com/products/sd-wan/edgeconnect-enterprise/].

This identity awareness is what later allows the SASE layer to make consistent decisions whether a user is on the corporate LAN or working remotely. Device posture signals (from MDM or EDR tooling) can feed the same policy inputs, so an out-of-compliance laptop receives a more restrictive role regardless of where it plugs in.

It is worth being honest about EdgeConnect’s security scope. The built-in firewall is excellent for L3–L7 policy, segmentation, and breakout control, and it can serve as a branch’s primary perimeter firewall for many use cases. For deep threat prevention — full intrusion detection/prevention (IDS/IPS), advanced data loss prevention (DLP), sandboxing — EdgeConnect is designed to hand traffic off to a dedicated NGFW or a cloud security service rather than do it all itself. That hand-off is the subject of the next section.

Key Takeaway: EdgeConnect builds security into every appliance through a stateful, zone-based firewall and a two-tier isolation model — VRF-like segments enforce macro boundaries (Guest can’t reach PCI), while zones enforce micro-segmentation inside a segment, all written as topology-independent, identity-aware, deny-by-default policy pushed centrally from Orchestrator.

Service Chaining and Breakout

The old WAN security model hauled every internet-bound packet from a branch back across the WAN to a data-center firewall stack — a design that adds latency, consumes expensive transport, and bottlenecks at the data center. EdgeConnect breaks that pattern with local internet breakout secured by service chaining: the appliance sends selected traffic directly from the branch over an encrypted tunnel to a cloud security provider’s nearest point of presence (POP), which inspects it and forwards it to the internet [Source: https://www.zscaler.com/partners/aruba].

Cloud security service chaining

Service chaining (sometimes called service insertion) is the practice of steering a flow through one or more security services on its way to its destination. In EdgeConnect terms, instead of User → LAN → EdgeConnect → Internet, the path becomes User → LAN → EdgeConnect → IPsec tunnel → cloud secure web gateway (SWG) → Internet. The cloud service — a Zscaler, Netskope, or Check Point POP — performs the URL filtering, threat inspection, CASB, and DLP that the branch appliance does not, then sends clean traffic on its way.

The decision of which traffic to chain is driven by EdgeConnect’s application intelligence. First-Packet iQ is EdgeConnect’s ability to classify an application on the very first packet of a flow — before the full session has even been established — using the destination IP and port, the domain or TLS SNI, URL category, behavioral heuristics, and a continuously updated application database [Source: https://blogs.arubanetworks.com/solutions/first-packet-iq-and-sd-wan-application-classification/]. Because classification happens immediately, the very first SYN a user sends is enough for the policy engine to pick a path and commit the entire flow to it. There is no “first few packets go the wrong way while we figure it out” problem.

Steering examples that fall out of this:

• General, unknown, or risky web traffic → Zscaler SWG for inspection.
• Social media, webmail, file sharing → Netskope for CASB and DLP control.
• Internal / private applications (internal IP ranges or known FQDNs) → SD-WAN overlay straight to the data center, bypassing the SWG entirely.

Automated tunnels to third-party SSE

The connectivity that makes service chaining possible is a set of automated IPsec tunnels that Aruba Orchestrator builds and maintains to each provider. Rather than hand-configuring VPNs at hundreds of sites, the workflow is centralized [Source: https://www.arubanetworks.com/techdocs/sdwan/docs/EC_Orchestrator/]:

1. Define the cloud security service in Orchestrator — choose the provider (Zscaler ZIA, Netskope, Check Point CloudGuard/Harmony Connect), set region/POP preferences, and configure global IKE/IPsec settings (IKE version, encryption, perfect forward secrecy, timers, redundancy).
2. API-based or template-based automation — for native integrations (Zscaler ZIA, Check Point CloudGuard), Orchestrator calls provider APIs to create VPN endpoints, register each branch’s public/egress IP, and create the matching sites or sub-locations bound to the correct POPs. For Netskope, Orchestrator typically uses predefined per-region tunnel templates.
3. Per-site automatic tunnel instantiation — when a site is associated with a cloud security profile, Orchestrator automatically builds one or two IPsec tunnels per POP (primary plus backup), pushes the IKE/IPsec parameters and peer addresses, and the appliance brings the tunnels up and reports health.
4. Continuous monitoring and failover — Orchestrator tracks per-tunnel SLA (latency, loss, jitter) and, on POP or tunnel failure, fails over to the secondary tunnel/POP and fails back per policy.

The most common operational pitfalls follow directly from this automation. IKE/IPsec proposal mismatches (v1 vs v2, mismatched lifetimes or DPD timers) are the classic cause of a “tunnel DOWN” state. NAT public-IP mismatches trip up sites behind NAT — the external NAT address must match the IP configured in the provider’s portal or IKE authentication fails. And MTU/fragmentation problems appear because IPsec encapsulation shrinks the effective MTU, so MSS clamping or a lowered tunnel MTU is often required, especially on Netskope NewEdge paths.

Figure 9.3: Automated dual-tunnel service chaining — a branch EdgeConnect with redundant primary/secondary IPsec tunnels rising to two provider POPs, Orchestrator shown overhead pushing tunnel config via provider API, and SLA probes on each tunnel.

flowchart LR
    User["Branch User / LAN"] --> EC["EdgeConnect (First-Packet iQ)"]
    Orch["Aruba Orchestrator"] -. "Pushes tunnel config via provider API" .-> EC

    EC == "Primary IPsec tunnel (SLA probed)" ==> POP1["Cloud Security POP 1"]
    EC -. "Secondary IPsec tunnel (failover)" .-> POP2["Cloud Security POP 2"]

    POP1 --> Inspect["SWG / CASB / DLP inspection"]
    POP2 --> Inspect
    Inspect --> Internet["Internet"]

Local breakout with security enforcement

Putting it together, the recommended breakout design layers three kinds of rule, ordered most-specific first:

Business Intent Overlays (BIOs) tie this together by deciding where and how traffic flows — the path selection, SLA targets, and whether to service-insert — while the firewall decides whether the traffic is allowed and between which zones. For example, a BIO might declare “Microsoft 365 from Corp_User_LAN prefers direct internet breakout, minimum 10 Mbps, under 100 ms latency, falling back to the SWG tunnel if the local circuit degrades,” while a firewall rule simply allows Corp_User_LAN → Corp_Internet for the O365 app group and sends everything else to the SWG [Source: https://www.arubanetworks.com/techdocs/sdwan/docs/EC_Orchestrator/].

A frequent troubleshooting trap deserves a callout: a niche or brand-new application that First-Packet iQ classifies as “unknown” must still have somewhere to go. The fix is a fallback rule that sends all unknown internet traffic to the SWG, so nothing escapes inspection by accident. Equally, in multi-provider environments (Zscaler for general web, Netskope for CASB) every app category needs a single, non-overlapping steering decision to avoid asymmetric routing from competing default routes.

Key Takeaway: EdgeConnect replaces data-center hairpinning with secure local breakout — Orchestrator auto-builds redundant IPsec tunnels to cloud security POPs, First-Packet iQ classifies each flow on its first packet, and a layered policy (default-to-SWG, direct-breakout for trusted SaaS, backhaul for internal apps) decides the path while watching for the usual gotchas: IKE mismatches, NAT IP mismatches, and MTU fragmentation.

The SASE Picture

Everything in this chapter — segmentation, the integrated firewall, application-aware steering, and automated tunnels to cloud security — is, in effect, half of a larger architecture the industry calls SASE. Understanding how EdgeConnect fits requires first untangling two acronyms that are often confused.

Converging SD-WAN with SSE

SSE (Security Service Edge) is the security portion of the model, delivered from the cloud. It bundles, at minimum [Source: https://www.gartner.com/en/information-technology/glossary/secure-access-service-edge-sase]:

• SWG (Secure Web Gateway) — URL filtering and web threat protection.
• CASB (Cloud Access Security Broker) — SaaS visibility, control, and DLP.
• ZTNA (Zero Trust Network Access) — application-level secure access that replaces broad VPN tunnels.
• FWaaS (Firewall as a Service) — L3–L7 firewall policy in the cloud.
• Frequently also DLP, remote browser isolation, and user-behavior analytics.

Crucially, SSE does not include SD-WAN or any WAN-edge connectivity. It assumes traffic somehow arrives at its POPs — via an endpoint agent, a VPN, or an SD-WAN tunnel.

SASE (Secure Access Service Edge) is the convergence of WAN networking and cloud security into a single, identity-driven, centrally managed, globally distributed service. The relationship is cleanest as a formula:

SASE = SD-WAN (WAN edge) + SSE (cloud security) + unified, cloud-delivered control.

In other words, SSE is one ingredient; SASE is the finished dish. EdgeConnect is the networking half of SASE — the WAN edge that performs local breakout, builds the IPsec/GRE tunnels to security POPs, applies application-aware steering (internal apps over private overlays, internet/SaaS/unknown traffic to SSE for inspection), and monitors path health across regions and providers. EdgeConnect decides what goes where and how; the SSE platform enforces what is allowed and inspects for threats [Source: https://www.arubanetworks.com/solutions/sase/].

Figure 9.4: The SASE equation — left block “SD-WAN / WAN edge (EdgeConnect)” plus right block “SSE (SWG + CASB + ZTNA + FWaaS + DLP)” combining under a “unified cloud-delivered control” banner to form SASE, with a remote user and a branch both feeding into the SSE cloud.

graph TD
    Branch["Branch Site"] --> SDWAN["SD-WAN / WAN Edge (EdgeConnect)"]
    Remote["Remote User (SSE Client)"] --> SSE

    SDWAN -- "IPsec/GRE tunnels" --> SSE["SSE: SWG + CASB + ZTNA + FWaaS + DLP"]

    SDWAN --> Control["Unified Cloud-Delivered Control (identity-driven)"]
    SSE --> Control
    Control ==> SASE{{"SASE = SD-WAN + SSE + Unified Control"}}

Aruba EdgeConnect SASE / unified SASE

HPE Aruba assembled the security half organically through acquisition. It bought Axis Security and rebranded and expanded the platform as Aruba SSE (HPE Aruba Networking SSE), delivering ZTNA for granular app-level access to private apps on-prem and in the cloud, SWG/FWaaS for web security and threat prevention, CASB for SaaS control, and cloud-delivered DLP [Source: https://blogs.arubanetworks.com/solutions/hpe-aruba-networking-completes-acquisition-of-axis-security/]. Pairing EdgeConnect (SD-WAN) with Aruba SSE (Axis-based) gives Aruba a single-vendor SASE offering [Source: https://www.arubanetworks.com/products/security/sse/].

The branch flow in a unified Aruba SASE looks like this:

1. A user at the branch connects to the LAN; traffic hits EdgeConnect.
2. EdgeConnect classifies the flow by application (SaaS vs. internal), by user/group (via the shared IdP or ClearPass), by destination, and by risk.
3. EdgeConnect steers: private/enterprise apps go over the secure SD-WAN overlay to the data center or cloud VPC; internet, SaaS, and private apps needing ZTNA go over IPsec/GRE tunnels to Aruba SSE POPs.
4. The Aruba SSE POP terminates the tunnel, applies ZTNA/SWG/CASB/DLP, transparently connects to private apps via a reverse connector, and forwards SaaS/internet traffic out.

Remote users off the network run an Aruba SSE client to the nearest POP and get the same security stack — no backhauling to a branch or data center. The single-vendor appeal is operational: one vendor for SD-WAN and SSE, tighter policy alignment (the segmentation and steering in EdgeConnect line up with the ZTNA/SWG rules in Aruba SSE), fewer consoles, and consistent identity and posture across the two halves. In practice you still run Aruba Orchestrator as the SD-WAN control pane and an Aruba SSE portal for security policy, with API, auto-tunnel, and shared-identity integration deepening as the post-acquisition platforms mature.

Partnerships: Zscaler, Netskope, Check Point, Palo Alto

Single-vendor is not the only path. EdgeConnect’s long-standing strength is its openness, and it supports multi-vendor, best-of-breed SASE by integrating natively with the major SSE providers — valuable for enterprises that already run Zscaler or Netskope and have no wish to rip them out.

• EdgeConnect + Zscaler: In Zscaler ZIA you create IPsec/GRE “locations,” configure authentication, and define web/SaaS policy. In Orchestrator you define Zscaler as a cloud security service, auto-build tunnels to the closest POPs via templates and ZIA APIs, and set SLA health probes. BIOs then steer business-critical SaaS (Microsoft 365, Salesforce) and general internet to Zscaler, while internal apps ride private overlays [Source: https://www.zscaler.com/partners/aruba].
• EdgeConnect + Netskope: In Netskope you configure NewEdge POPs as tunnel endpoints and define CASB/SWG/DLP policy; in Orchestrator you configure Netskope as a cloud security service, build tunnels to the nearest NewEdge POPs, and monitor health. Web and SaaS steer to Netskope for SWG/CASB/DLP; private apps go over a private overlay or Netskope Private Access (its ZTNA) [Source: https://www.netskope.com/partners/aruba].
• Check Point (CloudGuard Connect / Harmony Connect): You create cloud security locations in the Check Point portal (IPsec parameters, POP, gateway IPs, PSKs); Orchestrator installs the IPsec config with a compatible IKE/IPsec profile, sets a default route toward the Check Point cloud, and fails over to secondary POPs. Watch for IKE lifetime/DPD mismatches and asymmetric routing.
• Palo Alto Networks rounds out the set of recognized cloud security partners that branch traffic can be service-chained to, fitting the same IPsec-tunnel-plus-steering model.

The choice between architectures is a genuine trade-off:

The right answer depends on existing investments, how deep the CASB/DLP requirements run, and how much operational capacity the team has. A common migration arc is pragmatic: Phase 1 deploys EdgeConnect for SD-WAN while keeping the existing SSE; Phase 2 moves more traffic to SSE and retires on-prem appliances; Phase 3 optionally consolidates onto Aruba SSE (or fully commits to Zscaler/Netskope) and sunsets legacy VPN and firewalls. Across all of these, aligning EdgeConnect and the SSE layer on the same IdP (Azure AD, Okta) and feeding device posture from MDM/EDR is what lets policy be written about users and roles rather than brittle IP addresses [Source: https://www.arubanetworks.com/solutions/sase/].

Key Takeaway: SASE = SD-WAN + SSE + unified cloud control, and EdgeConnect is the SD-WAN half. Aruba’s acquisition of Axis Security created Aruba SSE for a single-vendor SASE story, while EdgeConnect’s native integrations with Zscaler, Netskope, Check Point, and Palo Alto enable best-of-breed multi-vendor SASE — the choice trading operational simplicity against specialist security depth.

Chapter Summary

EdgeConnect treats security as a property of the fabric rather than a separate box. Every appliance runs a stateful, zone-based firewall that tracks session state (so return traffic auto-permits and policy is written only in the initiating direction) and enforces topology-independent, deny-by-default rules between zones. Isolation comes in two tiers: VRF-like segments create macro boundaries that keep Guest, IoT, PCI, and Corp traffic fully separated across the WAN, while zones inside a segment deliver micro-segmentation through fine-grained zone-to-zone policy. Identity integration via a shared IdP or ClearPass lets these boundaries follow users and roles, not just IP addresses.

For deep inspection that the branch firewall deliberately does not perform, EdgeConnect uses service chaining: Orchestrator auto-builds redundant IPsec tunnels to cloud security POPs, First-Packet iQ classifies each flow on its very first packet, and a layered breakout policy decides whether traffic goes to a cloud SWG, straight out a trusted-SaaS direct path, or back over the overlay to the data center. Business Intent Overlays govern path and SLA; the firewall governs permission. Watch for IKE mismatches, NAT-IP mismatches, MTU fragmentation, and unclassified-traffic fallbacks.

Stepping back, this is the SD-WAN half of SASE — the convergence of WAN edge and cloud-delivered SSE (SWG, CASB, ZTNA, FWaaS, DLP). Aruba’s acquisition of Axis Security produced Aruba SSE, making EdgeConnect + Aruba SSE a single-vendor SASE, while native integrations with Zscaler, Netskope, Check Point, and Palo Alto support best-of-breed multi-vendor designs. The single-vs-multi-vendor decision trades tighter operational alignment against specialist security depth, and a phased migration lets organizations move at their own pace.

Key Terms

Chapter 10: Deployment, Operations, and Best Practices

Learning Objectives

By the end of this chapter, you will be able to:

• Plan a phased Silver Peak SD-WAN deployment from pilot to full rollout.
• Apply day-2 operational best practices for monitoring, upgrades, and troubleshooting.
• Summarize how architecture, models, licensing, and management come together in a real-world enterprise design.

This is the capstone chapter. The previous nine chapters built up the pieces: the EdgeConnect architecture and overlay/underlay model, the appliance family (EC-XS through EC-L), the Boost and security licensing model, and the Orchestrator management plane. Here we assemble those pieces into a working method — how a real organization gets from a slide deck to a production WAN, and how it keeps that WAN healthy afterward.

10.1 Deployment Lifecycle

A Silver Peak (now Aruba) EdgeConnect deployment is not a single cutover event. It is a deployment lifecycle — a structured sequence of phases that moves a network from assessment and design, through a tightly scoped pilot, to a controlled phased migration, and finally to an industrialized full rollout [Source: https://www.pure-ip.com/blog/what-weve-learned-from-100-mpls-to-sd-wan-migrations]. Treating deployment as a lifecycle rather than a flag-day swap is the single biggest predictor of a low-drama project.

Analogy: Think of it like renovating a house you still live in. You do not demolish every wall at once. You plan, you test materials in one room, you keep the kitchen working while you redo the bathroom, and you always know how to put a wall back if something goes wrong.

Design and Pilot Phase

The lifecycle has five recognizable phases. The early phases are about learning and validating; the later phases are about repeating at scale.

The design phase must be driven by requirements, not by technology preference. Before choosing any appliance model, inventory the sites, circuits, applications, and performance and security requirements — latency budgets, loss tolerance, availability targets, and regulatory constraints [Source: https://www.pure-ip.com/blog/what-weve-learned-from-100-mpls-to-sd-wan-migrations]. Classify applications by business criticality and performance sensitivity, because that classification becomes the raw material for your Business Intent Overlays later (Chapter 5). Then decide the underlay strategy: keep MPLS, move to dedicated Internet access (DIA), broadband, and LTE, or run a hybrid.

Critically, you must baseline the current WAN during design. Capture today’s latency, jitter, packet loss, application response times, and trouble-ticket volume [Source: https://www.firewalls.com/blog/sd-wan-migration/]. Without a baseline you cannot prove the project succeeded. “Voice sounds better now” is an opinion; “mean opinion score rose from 3.6 to 4.2 and failover events dropped 80%” is evidence.

Figure 10.1: The five-phase EdgeConnect deployment lifecycle, showing the narrowing-then-widening shape — broad discovery, narrow pilot, then widening rollout waves.

flowchart LR
    P1["Phase 1: Discovery and Design<br/>(inventory sites, baseline WAN)"]
    P2["Phase 2: Lab / PoC<br/>(validate in isolation)"]
    P3["Phase 3: Pilot<br/>(3-10 representative sites)"]
    P4["Phase 4: Phased Rollout<br/>(templates + ZTP in waves)"]
    P5["Phase 5: Optimization<br/>(steady-state tuning)"]

    P1 --> P2 --> P3 --> P4 --> P5
    P4 -. "review metrics, next wave" .-> P4

    subgraph Learning_and_Validating["Learning and Validating"]
        P1
        P2
        P3
    end
    subgraph Repeating_at_Scale["Repeating at Scale"]
        P4
        P5
    end

The pilot phase is where design assumptions meet reality. Choose 3–10 sites that collectively mirror your environment rather than your easiest sites. Good pilot selection criteria include [Source: https://www.pure-ip.com/blog/what-weve-learned-from-100-mpls-to-sd-wan-migrations]:

• Low-to-medium business risk, but enough real usage to generate insight. Do not pilot on your top-revenue store, but do not pilot on an empty closet either.
• Diverse connectivity: for example one site with MPLS plus DIA, one broadband-only site, and one site with LTE backup. This validates your hybrid design and exposes last-mile variability.
• Application-mix coverage: at least one SaaS-heavy site (Microsoft 365, Salesforce) and one with latency-sensitive apps (voice, VDI, EMR, or trading).
• Operational readiness: local “champions” who can validate the user experience, and sites where maintenance windows are manageable.

Pilot objectives should be explicit and measurable, tied directly to the baseline — for example, “improve voice MOS and reduce failover events relative to the current WAN” [Source: https://www.firewalls.com/blog/sd-wan-migration/]. The pilot is also where you refine the artifacts you will mass-produce later: device templates, Business Intent Overlays (BIOs), Zero-Touch Provisioning (ZTP) workflows, and operational runbooks.

Phased Migration from MPLS to Hybrid WAN

The migration from a legacy MPLS network to a hybrid WAN — one that uses MPLS, broadband, and/or LTE simultaneously as underlays — should be treated as coexistence then transition, never an abrupt cutover [Source: https://www.lightyear.ai/resources/mpls-migration-to-sd-wan-guide]. This is the principle of phased migration: legacy and new transports run in parallel while traffic is gradually shifted.

The typical pattern unfolds in four steps:

1. Transport audit & underlay readiness. Validate existing MPLS, DIA, broadband, and LTE circuits, and order new circuits where needed. ISP lead times are often the longest pole in the tent, so build them — and last-mile redundancy — into the schedule early [Source: https://www.firewalls.com/blog/sd-wan-migration/].
2. Overlay standup. Deploy EdgeConnect appliances over the hybrid underlay, often initially in a limited-control mode. Build overlays and BIOs, steering selected low-risk traffic across the SD-WAN while critical traffic stays on MPLS.
3. Parallel run / gradual traffic shift. Move increasingly critical applications from MPLS to SD-WAN paths as performance is validated [Source: https://www.lightyear.ai/resources/mpls-migration-to-sd-wan-guide]. Dynamic path selection, QoS, and Forward Error Correction (FEC) guarantee critical-app performance during the shift. Keep a per-site fall-back plan — such as reverting the default route to MPLS — active throughout this phase.
4. MPLS optimization or decommission. For some sites, retain a reduced MPLS footprint where strict SLAs or regulatory isolation justify it [Source: https://www.portnox.com/blog/network-security/mpls-to-sd-wan-migration-everything-you-need-to-know/]. Elsewhere, once operations are stable and SLAs are validated, remove MPLS, update routing, and renegotiate contracts [Source: https://www.lightyear.ai/resources/mpls-migration-to-sd-wan-guide].

During the parallel-run period, define clear traffic-steering rules so you always know exactly which applications use MPLS versus the Internet, and keep existing security controls in force while you gradually shift enforcement to the new model [Source: https://www.pure-ip.com/blog/what-weve-learned-from-100-mpls-to-sd-wan-migrations].

Cutover and Rollback Planning

Every site wave needs a documented rollback procedure before cutover begins [Source: https://www.pure-ip.com/blog/what-weve-learned-from-100-mpls-to-sd-wan-migrations]. The core of any EdgeConnect rollback is simple to state: know how to return default routing and DNS to the legacy WAN. Because MPLS remains in place during coexistence, rollback usually means re-pointing the default route and any application-specific routes back to the legacy edge router, rather than physically re-cabling anything.

A practical per-wave cutover package contains:

• A design and migration plan, plus a site-specific diagram.
• A test/validation checklist: application reachability tests, hard and soft failover tests, and monitoring checks.
• The rollback steps with a clear “go / no-go” decision point and the named person who owns that decision.

Example: A retail chain cutting over 40 stores in a wave schedules each store for a 30-minute window after closing. The technician powers on the pre-staged EdgeConnect, confirms both underlays come up green in Orchestrator, runs a four-item checklist (point-of-sale app reachable, voice MOS acceptable, SaaS breakout working, MPLS failover tested by disabling the broadband interface), and only then removes the temporary route back to the old router. If any check fails, the documented rollback re-enables the MPLS default route and the store is unaffected at open the next morning.

Key Takeaway: An EdgeConnect deployment is a five-phase lifecycle — discovery/design, lab, pilot, phased rollout, optimization. Baseline the WAN before you start, pilot on 3–10 representative (not easiest) sites, migrate MPLS-to-hybrid as coexistence-then-transition, and never cut over a wave without a documented rollback to legacy routing and DNS.

10.2 Day-2 Operations

Once sites are live, the work shifts from project mode to day-2 operations — the ongoing tasks of monitoring, upgrading, troubleshooting, and capacity-managing a running SD-WAN. The architecture you chose makes this far more centralized than legacy WAN operations: most day-2 work happens in Orchestrator rather than by SSH-ing into individual routers.

A note on sources: the research for upgrade and troubleshooting procedures flagged that some retrieved citations were off-topic and unreliable. The procedures below reflect standard Aruba EdgeConnect / Orchestrator operational practice, but for any production change you should verify exact UI paths and CLI syntax against the official Aruba EdgeConnect and Orchestrator documentation for your specific software version.

Software Upgrade Strategy via Orchestrator

A software upgrade in EdgeConnect follows two firm rules: Orchestrator first, then appliances, and appliances in waves.

Before touching any version, complete the pre-upgrade checklist:

• Check compatibility. Confirm the target Orchestrator version supports your current EdgeConnect OS (ECOS) appliance versions, and read the release notes for schema changes and deprecations (tunnel modes, Boost versions, crypto suites).
• Back up Orchestrator. Export the Orchestrator configuration and database (topology, templates, overlays, appliances) and take a VM snapshot or image backup. Confirm the backup’s integrity before proceeding — this is your rollback path.
• Set a change window. Schedule a maintenance window during which policy changes are frozen and operators expect delayed alarms and telemetry.

The Orchestrator upgrade itself involves obtaining and checksum-verifying the image, applying it (via the built-in upgrade workflow for a virtual Orchestrator, or by restoring a backup onto a new OVA), and monitoring the service restart. Expect UI downtime while the database migration runs. Afterward, validate: confirm the new version in the system info, verify all appliances reconnect, and check that templates, BIOs, route policies, roles, and scheduled jobs are all intact. If anything is severely broken, roll back from the snapshot.

Appliance upgrades are then staged and pushed from Orchestrator:

1. Upload the new ECOS image(s) for each platform you run and verify the version and type.
2. Create upgrade groups by region, role, or business impact.
3. Schedule waves during low-traffic hours, ordered from least to most critical.

The wave ordering matters. Upgrade non-critical sites → smaller branches → central hubs/data centers. For HA (dual-appliance) hubs, upgrade one appliance at a time: fail traffic over, upgrade the first, confirm health, then upgrade its partner. Avoid making configuration changes during an upgrade wave — you want a single variable in flight, not two.

After each appliance wave, verify per-appliance that the device shows Online with the new version, that site-to-site and Internet-breakout tunnels are up, and that there are no new alarms such as “IPSec negotiation failed.” If new tunnel issues appear only after an upgrade, the usual suspects are a new default behavior (a changed cipher suite, path-SLA default, or NAT detection) or a template inconsistency where a WAN-label or overlay change did not reach every site.

Figure 10.2: Orchestrator-driven upgrade flow — image upload, wave grouping, scheduled push to appliances, and per-wave validation gate before the next wave proceeds.

flowchart TD
    Start(["Start upgrade"]) --> Orch["Upgrade Orchestrator first<br/>(backup + snapshot, validate version)"]
    Orch --> Upload["Upload ECOS image per platform<br/>(verify version and type)"]
    Upload --> Group["Create upgrade groups<br/>(by region, role, business impact)"]
    Group --> Wave["Schedule + push next wave<br/>(least-critical first)"]
    Wave --> Validate{"Validation gate:<br/>Online, tunnels up,<br/>no new alarms?"}
    Validate -- "Pass" --> More{"More waves<br/>remaining?"}
    Validate -- "Fail" --> Rollback["Roll back from snapshot /<br/>fix template inconsistency"]
    Rollback --> Wave
    More -- "Yes" --> Wave
    More -- "No" --> Done(["Upgrade complete"])

Troubleshooting Tunnels and Path Issues

Effective troubleshooting in EdgeConnect starts with one decision: is this an overlay problem (tunnel configuration or crypto) or an underlay problem (transport, routing, or path quality)? A fast diagnostic shortcut answers most of it:

• If all tunnels from a site are down → it is an underlay/site problem (the circuit, the WAN interface, or routing to the peer).
• If only some overlays are down → it is an overlay/policy problem (configuration asymmetry or crypto mismatch).

Tunnel-down triage then proceeds layer by layer. First, verify underlay reachability: ping the peer’s WAN IP from each appliance. If ping fails, check the local WAN interface (up/down, error counters), upstream ISP/router connectivity, and routing (show ip route — does a route to the peer WAN IP exist?). If the tunnel crosses a firewall or NAT, confirm IPsec ports UDP 500 and 4500 are open and that NAT rules still translate the EdgeConnect WAN IPs correctly. Fix underlay reachability before touching any tunnel configuration.

If the underlay is reachable but the tunnel is still down, move to overlay and crypto. Compare the overlay configuration on both ends for symmetry: same overlay, same WAN labels and path assignments, matching IPsec settings (suites, PFS). Then inspect IKE/IPsec state:

Figure 10.4: Tunnel-down troubleshooting decision flow — split overlay from underlay, fix underlay reachability first, then walk IKE Phase 1 / Phase 2 state.

flowchart TD
    Start(["Tunnel down"]) --> Scope{"How many<br/>tunnels are down?"}
    Scope -- "All tunnels from site" --> Underlay["Underlay / site problem"]
    Scope -- "Only some overlays" --> Overlay["Overlay / policy problem"]

    Underlay --> Ping{"Ping peer WAN IP<br/>succeeds?"}
    Ping -- "No" --> FixU["Check WAN interface, ISP/route,<br/>NAT and UDP 500/4500"]
    Ping -- "Yes" --> Overlay

    Overlay --> Sym["Compare both ends for symmetry<br/>(overlay, WAN labels, IPsec suites)"]
    Sym --> IKE{"IKE / IPsec<br/>state?"}
    IKE -- "No IKE negotiation" --> Port["Firewall / port issue:<br/>UDP 500 or 4500 blocked"]
    IKE -- "Phase 1 up, Phase 2 down" --> Transform["Transform-set / PFS or<br/>proxy-ID mismatch"]
    IKE -- "Failed after upgrade" --> Cipher["New cipher unsupported by peer;<br/>PSK/cert not on both ends"]

Path issues are a distinct category: the tunnel stays up, but traffic suffers loss, latency, jitter, or flapping on a specific transport. Diagnose these through Orchestrator’s per-WAN-label path performance view, which shows loss, latency, jitter, MOS, and SLA status (OK / Warning / Failed) per direction. Remediation options include biasing the affected overlay toward a healthier transport, enabling FEC or packet duplication for real-time flows on a lossy Internet path (bandwidth permitting), and raising an ISP ticket with the loss graphs as evidence. Watch for overly strict SLA thresholds, which cause constant path flapping on normal Internet links; relaxing the threshold often “fixes” a phantom problem.

Example: A branch’s voice overlay rides both Internet and MPLS. Orchestrator shows the Internet path at 5–10% loss while MPLS sits at 0.1% loss but higher latency. The on-call engineer temporarily biases the voice overlay to prefer MPLS, enables packet duplication for voice on the Internet path, and opens an ISP ticket with the loss graph attached — restoring call quality within minutes while the carrier investigates the underlying circuit.

A related class of complaint is “the tunnel is fine but the app is slow,” which often points to Boost (WAN optimization — compression, deduplication, TCP acceleration). Boost requires an active license on both ends of the optimized link and a symmetric path. Flows stay in pass-through (un-optimized) when traffic is end-to-end encrypted, when policy explicitly excludes them, when routing is asymmetric, or when a recent upgrade left mismatched Boost/software versions between the two ends.

Capacity Planning and License Review

Capacity planning is the day-2 discipline of confirming that appliances, transports, and licenses still fit the load — before users feel the squeeze. EdgeConnect appliance capacity is consumed by more than raw bandwidth: tunnel/IPsec count and enabled features (IPS/IDS, Boost, advanced QoS, segmentation, First-Packet iQ) all draw CPU, and Aruba’s guidance shows reduced effective throughput when many advanced features are turned on [Source: https://www.advizex.com/post/hpe-aruba-edgeconnect-a-technical-deep-dive]. A useful rule of thumb is to size to peak WAN throughput plus 20–30% headroom over a 3–5 year horizon, and to size up one model tier if you plan to enable many features extensively [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf].

A quarterly capacity and license review should ask:

• Are any appliances consistently above their throughput, flow-count, or CPU headroom? (Candidates for a model upgrade or for offloading features.)
• Are Boost and security licenses active where the design expects them — especially after any HA or appliance replacement?
• Do upcoming site additions or bandwidth increases fit the current Orchestrator sizing (appliance count, log retention)?

Key Takeaway: Day-2 work is centralized in Orchestrator. Upgrade Orchestrator first, then appliances in least-critical-first waves with a snapshot rollback and one-at-a-time HA upgrades. Troubleshoot by splitting overlay (config/crypto) from underlay (reachability/path): all tunnels down = underlay, some overlays down = policy. Review capacity and licenses quarterly, sizing for peak plus headroom and accounting for the CPU cost of enabled features.

10.3 Putting It All Together

This final section synthesizes the whole book — architecture, models, licensing, and management — into one coherent picture.

Reference Design for a Multi-Site Enterprise

Consider a fictional enterprise, “Meridian Retail,” with one primary data center, one secondary DC, three regional hubs (Americas, EMEA, APAC), and 600 branch stores. A standard EdgeConnect reference design for an organization like this combines a few well-worn patterns [Source: https://www.advizex.com/post/hpe-aruba-edgeconnect-a-technical-deep-dive].

Topology. Most enterprises use hub-and-spoke for branches, with branches forming IPsec tunnels to a regional hub, plus a full or partial mesh between the regional hubs and selective mesh for a small number of large or latency-sensitive sites [Source: https://www.youtube.com/watch?v=gJTiv3MWHq0]. The selectivity is deliberate: meshing every site to every site explodes the tunnel count, so mesh is reserved for cases with genuine site-to-site traffic (campuses, call centers) or strict low-latency needs.

Appliance models by role map directly onto the family from Chapter 4 [Source: https://www.securewirelessworks.com/edgeconnect.asp][Source: https://juaraitsolutions.com/edgeconnect-sd-wan/]:

Redundancy. Hubs and data centers run dual EdgeConnect appliances with a dedicated HA link, and tunnels over each underlay can connect to both appliances [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. At large hubs, each appliance terminates all transports (MPLS, Internet, LTE) so either one has a complete forwarding path [Source: https://www.youtube.com/watch?v=gJTiv3MWHq0]. Branches and hubs use two or more diverse underlays with path conditioning and tunnel bonding. Routing is designed so each hub prefers its local EdgeConnect gateways, avoiding the asymmetric paths and ECMP behavior that break stateful firewalls [Source: https://www.youtube.com/watch?v=gJTiv3MWHq0].

Management and licensing. A single global Orchestrator instance — deployed as SaaS, an on-prem VM, or in the customer’s cloud — drives ZTP, Business Intent Overlays, segmentation, path steering, and monitoring, with role-based access control and per-region templates [Source: https://www.advizex.com/post/hpe-aruba-edgeconnect-a-technical-deep-dive]. This is where the licensing model (Chapter 6) shows up operationally: the EdgeConnect base subscription plus Boost (where WAN optimization is justified) plus security tiers are all tracked and assigned centrally.

Figure 10.3: Meridian Retail reference design — 600 branches in hub-and-spoke to three regional hubs (EC-M pairs), regional hubs meshed to each other and to dual data centers (EC-L pairs), all managed by one global Orchestrator.

graph TD
    Orch["Global Orchestrator<br/>(ZTP, BIOs, licensing, monitoring)"]

    subgraph DataCenters["Data Centers (EC-L HA pairs)"]
        DC1["Primary DC<br/>EC-L pair"]
        DC2["Secondary DC<br/>EC-L pair"]
    end

    subgraph RegionalHubs["Regional Hubs (EC-M HA pairs)"]
        H1["Americas hub<br/>EC-M pair"]
        H2["EMEA hub<br/>EC-M pair"]
        H3["APAC hub<br/>EC-M pair"]
    end

    Branches["600 branch stores<br/>EC-XS / EC-S / EC-M by role<br/>(hub-and-spoke over MPLS / broadband / LTE)"]

    Orch -. "manages all appliances" .-> DataCenters
    Orch -. "manages all appliances" .-> RegionalHubs
    Orch -. "manages all appliances" .-> Branches

    Branches -->|"IPsec tunnels to regional hub"| H1
    Branches --> H2
    Branches --> H3

    H1 ---|"mesh"| H2
    H2 ---|"mesh"| H3
    H1 ---|"mesh"| H3

    H1 --> DC1
    H2 --> DC1
    H3 --> DC1
    H1 --> DC2
    H2 --> DC2
    H3 --> DC2

    DC1 ---|"HA / replication"| DC2

Notice how the four themes of this book converge in this one diagram: architecture (overlay/underlay, hub-and-spoke-plus-mesh), models (EC-XS through EC-L sized to role), licensing (base + Boost + security assigned per appliance), and management (one Orchestrator with ZTP and BIO templates). The reference design is the place where they stop being separate chapters and become a single system.

Common Pitfalls and Best Practices

Across the deployment and operations literature, the same mistakes recur — and so do the same best practices that prevent them.

Two best practices deserve emphasis because they pay off for years. First, standardize through templates and ZTP: appliances pre-registered by serial number in Orchestrator auto-download their configuration on first boot and join the correct site group, which makes a 600-store rollout repeatable and low-touch — keep a manual bootstrap fallback for sites behind restrictive firewalls. Second, export telemetry to your existing NMS/SIEM via syslog, SNMP, or API, so SD-WAN events correlate with ISP and router events for long-term trending rather than living only inside Orchestrator.

Where to Learn More and Certification Paths

Silver Peak EdgeConnect is now part of HPE Aruba Networking, so the authoritative documentation, data sheets, and training live under the Aruba brand. The single most useful reference for design and sizing is the official Aruba EdgeConnect solution data sheet, which carries the current HA patterns, models, and capacity numbers [Source: https://www.silver-peak.com/sites/default/files/infoctr/aruba-data-sheet-edgeconnect-solution-121620.pdf]. Because throughput and tunnel figures change by appliance generation, always validate sizing against the current data sheet for your hardware rather than memorized numbers.

To go deeper, the recommended progression is:

• Vendor documentation first. Aruba EdgeConnect and Orchestrator product documentation for your software version — the ground truth for UI paths, CLI syntax, upgrade procedures, and release-note deprecations.
• Technical deep-dives and design guides for architecture and HA patterns [Source: https://www.advizex.com/post/hpe-aruba-edgeconnect-a-technical-deep-dive][Source: https://www.youtube.com/watch?v=gJTiv3MWHq0].
• Vendor certification. HPE Aruba Networking offers role-based certifications spanning associate through expert levels, including SD-WAN and EdgeConnect-focused tracks; these formalize the design, deployment, and operations skills covered across this book.
• Hands-on labs. Stand up a virtual Orchestrator and virtual EdgeConnect (EC-V) appliances to practice ZTP, BIO design, upgrades, and tunnel troubleshooting in a safe environment before doing them in production.

Key Takeaway: A multi-site reference design is hub-and-spoke for branches, mesh between regional hubs and a few key sites, EC-XS-to-EC-L sized by role, dual-appliance HA at hubs/DCs with diverse underlays, and one global Orchestrator — the point where architecture, models, licensing, and management become one system. Avoid the recurring pitfalls (no baseline, config drift, hard cutovers, alarm floods, under-sizing) by standardizing on templates/ZTP and integrating telemetry, and deepen your skills through Aruba documentation, design guides, certifications, and virtual-appliance labs.

Chapter Summary

This capstone chapter turned the building blocks of the book into a working method for deploying and operating a Silver Peak / Aruba EdgeConnect SD-WAN.

The deployment lifecycle runs through five phases — discovery and design, lab/PoC, pilot, phased rollout, and optimization. Design must be requirements-driven and must establish a measurable WAN baseline. Pilots cover 3–10 representative (not easiest) sites with diverse connectivity and application mix. Migration from MPLS to a hybrid WAN is coexistence-then-transition: run transports in parallel, shift critical apps gradually with dynamic path selection, QoS, and FEC, then optimize or decommission MPLS — always with a documented rollback to legacy routing and DNS for each wave.

Day-2 operations center on Orchestrator. Software upgrades go Orchestrator-first then appliances in least-critical-first waves, with a backup/snapshot rollback and one-at-a-time HA upgrades. Troubleshooting splits overlay (configuration and crypto) from underlay (reachability and path quality): all tunnels down points to the underlay, while only some overlays down points to policy. Path problems are diagnosed via per-WAN-label performance and remediated by biasing overlays and enabling FEC, while watching for flap-inducing strict SLA thresholds. Capacity and license reviews size for peak plus 20–30% headroom and account for the CPU cost of enabled features.

Finally, putting it all together in a multi-site reference design shows the four themes of the book converging: architecture (overlay/underlay, hub-and-spoke plus selective mesh), models (EC-XS through EC-L by role), licensing (base, Boost, security assigned in Orchestrator), and management (one global Orchestrator with ZTP and BIO templates). Avoiding the recurring pitfalls and following the documentation, design-guide, certification, and hands-on-lab path turns that design into a network that runs well for years.

Key Terms