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

1. The WAN Problem Space

Every organization with more than one location faces the same fundamental challenge: how do you connect a headquarters, data centers, branch offices, and a growing pile of cloud applications into one network that is fast, reliable, secure, and affordable? For two decades the standard answer was MPLS (Multiprotocol Label Switching) — a private, carrier-provided service that forwards traffic between sites using labels rather than relying on the public Internet. It offers predictable latency, contractual SLAs, and a private path. For voice, video, and business-critical apps, that predictability was worth paying for.

The trouble is what it costs and how it is managed. In a classic MPLS design each branch has a traditional router, connectivity is mostly MPLS, and routing decisions are made router-by-router via the CLI. This creates recurring pain points:

1. High cost per megabit. MPLS bandwidth is far more expensive than broadband or dedicated Internet access (DIA) at equivalent speeds.
2. Rigid, slow change management. Adding a site or re-prioritizing an app means router-by-router changes and telco coordination; new circuits can take weeks or months.
3. Limited path choices. Sites are typically locked into one primary transport with a passive Internet VPN backup; using multiple links actively is hard.
4. Operational complexity. Device-by-device configuration leads to inconsistent policies, and monitoring is fragmented by site and transport.

Analogy: MPLS is a private toll highway between your offices — smooth and reliable, but you pay a steep toll per mile, a new on-ramp takes months, and you have only the one road. Meanwhile the public roads (the Internet) got faster and cheaper, and most of where employees now want to go (the cloud) is reachable from those public roads anyway.

Cloud and SaaS traffic growth

The MPLS model assumed a hub-and-spoke world where applications lived in a central data center. As traffic shifted to SaaS and IaaS — Microsoft 365, Salesforce, Zoom, AWS, Azure — the destination moved to the public cloud. In a traditional design, that Internet-bound traffic is often backhauled: a branch hauls its Microsoft 365 or Zoom traffic across MPLS to a central data center, out the data center firewall, and back again. For a video call needing sub-100 ms latency, that detour is the difference between a smooth meeting and a frozen one.

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

Cost, agility, and application performance pressures

These shifts converged into three sustained pressures. Cost: finance wanted WAN spending down even as demand climbed. Agility: the business wanted new sites in days, not months, and new apps prioritized instantly. Application performance: users expected LAN-quality experience for cloud and real-time apps. Traditional router-based WANs could not satisfy all three at once — keep MPLS and cost/agility suffer; move to cheap Internet and you lose the SLA and any good way to react when a link degrades mid-call. The market needed an approach that decoupled application policy from the underlying transport — SD-WAN.

Key Takeaway: Traditional MPLS WANs are reliable and predictable but costly, slow to change, path-limited, and poor at handling backhauled cloud traffic. The growth of SaaS/IaaS plus cheap broadband exposed these limits and created sustained pressure for a more cost-effective, agile, application-aware WAN.

2. What SD-WAN Delivers

SD-WAN applies the principles of software-defined networking to the WAN: separate the control plane (how traffic should flow) from the data plane (the actual forwarding), and build an intelligent software overlay that rides on top of whatever physical links (the underlay) are available. A 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/orchestrator — the "brain" — where policy is defined and network-wide telemetry is collected.
• Encrypted overlay tunnels (typically IPsec) between edges across one or more underlay transports: MPLS, broadband, DIA, LTE/5G.

The phrase to internalize is transport independence. The underlay links are treated as interchangeable "transport circuits," each with measurable characteristics (latency, loss, jitter, available bandwidth). The overlay tunnels and policies do not care whether a packet rides MPLS or cable broadband — only whether the path meets the application's requirements.

SD-WAN Architecture Overview (Figure 1.2)

Centralized policy and orchestration

The single largest operational difference is where intelligence lives. In a traditional WAN the control plane is distributed: every router runs its own protocols and is configured individually, and no single entity has a real-time, multi-transport, per-application view. In SD-WAN, a centralized orchestrator manages network-wide policies, maintains topology and health, pushes config templates, and aggregates telemetry into one dashboard. This unlocks zero-touch provisioning (ZTP) — ship an unconfigured edge, a non-technical person plugs it in, it phones home and joins the fabric — and policy that scales: a QoS change is one edit, not fifty.

Analogy: A traditional WAN is a fleet of taxis where every driver picks their own route with no coordination. SD-WAN is a ride-hailing platform: a central dispatcher sees every vehicle and every road's live conditions, routes each trip optimally, and changes the rules for the whole fleet from one console.

Transport independence and active-active links

Because the overlay abstracts the underlay, SD-WAN can use all links simultaneously rather than keeping one in cold standby — active-active usage. Edges continuously measure latency, jitter, loss, and availability, then steer traffic dynamically: load sharing across links, application-aware routing (voice over the lowest-jitter path, bulk backups over the cheapest, payment traffic over a secure overlay), and fast failover with brownout detection — moving flows off a link that is degrading but not yet down.

The cost implications are significant. Instead of upgrading a 20 Mbps MPLS circuit to an expensive 100 Mbps one, an organization might keep the 20 Mbps MPLS for voice and 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.

Traditional MPLS WAN vs. SD-WAN Overlay (Figure 1.4)

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

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 links active-active, routes each application by its real-time SLA, enables zero-touch provisioning and one-touch policy, and breaks cloud traffic out locally — delivering more bandwidth, more agility, and lower cost than traditional MPLS WANs.

3. The Silver Peak Journey

Silver Peak did not begin as an SD-WAN company. It was founded in 2004 by David Hughes as a WAN optimization (WAN acceleration) company. In the mid-2000s the dominant WAN pain was not the cloud — it was getting acceptable performance from expensive, bandwidth-constrained MPLS links. Its early product lines reflected that focus: NX (hardware appliances), VX (virtual appliances on hypervisors like VMware), and GMS (Global Management System). The techniques those boxes used define WAN optimization to this day: byte-level deduplication, compression, and TCP acceleration. In this market it competed with Riverbed and Cisco WAAS.

Analogy: WAN optimization is like two people who talk daily and develop shorthand — "you know, the usual." 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, traffic moved to SaaS/IaaS, encryption became standard, and enterprises wanted to use multiple links actively with central management. Silver Peak's response was the Unity architecture — a single, unified WAN fabric connecting data centers, branches, and cloud. Around 2014–2015 this crystallized into Unity EdgeConnect, a full SD-WAN platform built by reusing existing strengths: VX virtualization expertise, the WAN-optimization algorithms, and path-conditioning techniques for lossy links.

This is the defining characteristic of the platform. Where most SD-WAN vendors bolted on basic optimization (or none), Silver Peak folded mature, battle-tested WAN optimization into the 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 that operates at the network/transport level without deep data inspection.

Acquisition by Aruba (HPE) in 2020 and rebranding

In 2020, Hewlett Packard Enterprise (HPE), through its Aruba business, acquired Silver Peak for approximately US$925 million in cash. The logic was to combine Silver Peak's mature, application-aware WAN overlay with Aruba's campus/branch wireless LAN, wired LAN, and security portfolio — accelerating Aruba's Intelligent Edge strategy. For customers the transition was evolutionary: same EdgeConnect code base, honored support and entitlements, compatible appliances and images, no forklift replacement. What changed was branding and SKUs:

Knowing this mapping matters: older guides and configs still say "Unity," while newer datasheets use the HPE Aruba Networking names — but the technology underneath is one continuous lineage.

The Silver Peak Evolution Timeline (Figure 1.3, source diagram)

Position in the SASE and SSE landscape

The acquisition positioned EdgeConnect within a larger trend: SASE (Secure Access Service Edge), which combines SD-WAN networking with cloud-delivered security services — secure web gateway (SWG), cloud access security broker (CASB), zero-trust network access (ZTNA), firewall-as-a-service (FWaaS) — into one converged fabric. SSE (Security Service Edge) refers specifically to the security half of SASE. EdgeConnect supplies the SD-WAN, or "networking," pillar. To complete the security side, HPE acquired Axis Security (and its Atmos platform) in 2023, which became HPE Aruba Networking SSE. Together, EdgeConnect SD-WAN plus HPE Aruba Networking SSE form HPE Aruba Networking SASE.

This explains EdgeConnect's distinctive spot among SD-WAN vendors (Cisco SD-WAN/Viptela, Cisco Meraki, VMware SD-WAN/VeloCloud, Fortinet, Palo Alto Prisma/CloudGenix). Its WAN-optimization heritage — mature, tightly integrated Boost plus advanced path conditioning — 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 apps that genuinely benefit from acceleration.

Key Takeaway: Silver Peak began in 2004 as a WAN optimization vendor (NX/VX), evolved that 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. Rebranded to HPE Aruba Networking EdgeConnect, it now serves as the SD-WAN foundation of HPE Aruba Networking's SASE portfolio, distinguished by its deeply integrated WAN-optimization heritage.