Chapter 2: Core Architecture and Components

The Three Pillars

Every Silver Peak EdgeConnect SD-WAN deployment rests on three logical components. 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).

A useful analogy: think of a national delivery company. The EdgeConnect appliances are the local depots in each city. The Orchestrator is the head-office operations center that sets the rules. The Unity Cloud Portal is the corporate registration desk where a new depot is enrolled, given credentials, and told which operations center it reports to. Once running, a depot talks to operations daily; 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. It comes in three form factors so the same logical role can be filled anywhere:

• Physical appliances — purpose-built hardware for branches, retail stores, and data centers.
• Virtual appliances — software images on a hypervisor (VMware ESXi, KVM, Hyper-V) on a customer's own server.
• Cloud appliances — images deployed inside public cloud (AWS, Azure, GCP) so cloud workloads join the same fabric.

Regardless of form factor, the appliance terminates WAN underlay links, builds encrypted overlay (IPsec) tunnels, runs local routing (static, OSPF, BGP), enforces intent-based policy with DPI classification, and performs path conditioning and optimization (FEC, packet order correction, jitter buffering). With the optional Boost license it adds WAN optimization — TCP acceleration, deduplication, and compression.

Orchestrator: The Management Plane (Formerly GMS)

The Orchestrator is the centralized management system — the "single pane of glass" through which administrators configure, monitor, and troubleshoot every appliance. It was originally the Global Management System (GMS) under the Silver Peak brand; after the HPE/Aruba acquisition it was renamed Orchestrator. The two names refer to the same thing.

The Orchestrator can run on-premises as a VM, in cloud IaaS, or as a vendor-hosted SaaS instance. Its responsibilities include intent-based policy management via Business Intent Overlays (BIOs), zero-touch provisioning (ZTP), monitoring and analytics, lifecycle management (image management, templates, backup/restore, RBAC, multi-tenancy), and integrations (Syslog, SNMP, REST APIs). A defining property: the Orchestrator is not in the data path — user packets never flow through it.

Unity Cloud Portal: Onboarding and Cloud Services

The Unity Cloud Portal is a vendor-operated cloud service that acts as the "phone-home" front end. Its primary jobs are zero-touch onboarding (a new appliance authenticates with serial number + activation token and receives its license status and the address of the Orchestrator to join), license and subscription management (the central pool of appliance, Boost, and feature licenses), and Orchestrator-as-a-Service access for SaaS deployments. The key idea: the Cloud Portal is mostly involved at onboarding and licensing time; once adopted, day-to-day traffic flows directly between appliance and Orchestrator.

Figure 2.1: The Three Pillars and Their Interactions.

Planes of Operation

Network architectures are described in three planes — management, control, and data. The model separates who decides what from what actually moves packets. In EdgeConnect each plane lives in a specific place, and that placement tells you exactly how the network behaves under failure.

The management plane is where the network is configured, monitored, and maintained — it lives almost entirely in the Orchestrator. The control plane decides how to reach destinations and which path to use; in EdgeConnect it is distributed across the appliances, each maintaining its tunnels, running routing protocols, measuring path quality, and selecting paths in real time. The Orchestrator shapes control-plane behavior but does not make the packet-by-packet decision. The data plane forwards user traffic and runs only on the appliances; the Orchestrator is never in the data path.

How Appliances Register and Receive Policy

Bringing a new branch online ties all three planes together:

1. Management plane — bootstrap and ZTP. The appliance boots, gets an IP (usually via DHCP), phones home to the Cloud Portal, learns its Orchestrator address, and opens a secure session. The Orchestrator authenticates it, assigns a site name and role, and pushes a configuration template plus site-specific policy (BIOs, segmentation, security).
2. Control plane — build overlays and learn routes. Using that policy, the appliance forms IPsec tunnels, establishes BGP/OSPF sessions, learns local prefixes, advertises them, and installs remote prefixes.
3. Data plane — forward traffic. Users generate traffic; the appliance classifies each flow, applies the overlay policy, and forwards onto the chosen path(s).

The key consequence 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 new configuration and fresh analytics, but traffic keeps flowing.

Zero-Touch Provisioning Flow

Zero-touch provisioning (ZTP) lets a non-technical person stand up an appliance without touching a command line. The orchestrated flow: ship preloaded with defaults → rack, cable, power on, reach the Internet → contact the Cloud Portal (serial + token) → portal validates license and returns the target Orchestrator address → appliance opens a secure session to that Orchestrator, which pushes full configuration → appliance builds tunnels and forwards. ZTP failures usually fall on the Cloud Portal/ZTP side (unregistered/unlicensed device, wrong key, blocked DNS/HTTPS, NTP/clock causing TLS cert failures) or the Orchestrator side (unreachable, license/capacity limit, mapped to the wrong Orchestrator).

Figure 2.2: Zero-Touch Provisioning Sequence.

Overlays and Underlays

The final architectural idea is the separation of the physical network you rent from carriers (the underlay) from the intelligent virtual network EdgeConnect builds on top (the overlay).

Underlay Transports: MPLS, Broadband, and LTE

The underlay provides basic reachability between appliances — transport types (MPLS, broadband, private Ethernet, LTE/5G, satellite), the IP layer (WAN interface addresses and ISP routing), and measurable characteristics (bandwidth, latency, jitter, loss, MTU, CIR). Two essential facts: EdgeConnect does not change how the underlay works (it uses whatever IP connectivity exists), and if underlay reachability is broken — by routing, an ACL, NAT, or a blocked port — overlay tunnels cannot form over that path. A common gotcha: tunnels use IPsec, so underlay firewalls/NAT must permit UDP 4500 and related IPsec packets between WAN IPs.

Business Intent Overlays as Logical Fabrics

The overlay is the virtual SD-WAN network: encrypted IPsec tunnels plus the logical topologies and policies that ride them. A Business Intent Overlay (BIO) answers one question: given a type of traffic, how should the fabric treat it? Each BIO defines traffic classification (via DPI, subnets, ports, user groups), topology (full mesh, hub-and-spoke, regional mesh), path preferences and SLA thresholds, QoS treatment (DSCP, prioritization, bandwidth guarantees), and security/segmentation. A crucial subtlety: multiple BIOs share the same physical tunnels — a BIO is not a separate tunnel, it is a logical overlay distinguished by policy and segmentation. The "Voice" and "Backup" BIOs may both ride the same Internet-to-Internet tunnel. The whole system — every appliance, tunnel, and BIO — is the SD-WAN fabric: one transport-independent virtual WAN with centralized control and distributed enforcement.

The analogy worth remembering: the underlay is the roads (MPLS, Internet, LTE), and the overlay is the set of virtual lanes painted on top, each 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 and remote WAN interface. Typically there is one tunnel per transport pair (MPLS↔MPLS, Internet↔Internet, LTE↔LTE), with cross-transport tunnels if configured. Tunnels are auto-discovered and auto-built by the Orchestrator once sites and WAN links are defined, then continuously probed for latency, jitter, loss, and (for voice) a Mean Opinion Score (MOS). If the underlay loses IP connectivity, the tunnel goes down; if the underlay is up but degraded, the tunnel stays up but flagged as not meeting SLA, letting the fabric prefer a healthier tunnel.

End-to-end example. HQ (50 Mbps MPLS, 200 Mbps broadband) and Branch A (10 Mbps MPLS, 100 Mbps broadband). The Orchestrator auto-builds an MPLS↔MPLS tunnel (~20 ms, <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. If MPLS later drops 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 carrier router, and even if the Orchestrator happens to be unreachable.

Figure 2.3: Basic SD-WAN Topology with Overlays and Underlays.