Chapter 10: Deployment, Operations, and Best Practices

1. Deployment Lifecycle

A Silver Peak (now Aruba) EdgeConnect deployment is not a single cutover event. It is a deployment lifecycle — a structured sequence 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. Treating deployment as a lifecycle rather than a flag-day swap is the single biggest predictor of a low-drama project. Think of it like renovating a house you still live in: you plan, test materials in one room, keep the kitchen working while you redo the bathroom, and always know how to put a wall back.

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.

Phase	Purpose	Key activities
1. Discovery & design	Understand the environment	Inventory sites, circuits, apps; classify apps by criticality; baseline current WAN (latency, jitter, loss, ticket volume)
2. Lab / PoC	Validate technology in isolation	Stand up Orchestrator + a few appliances; test routing, overlays, security integration, firewall interop
3. Pilot	Validate in production reality	Deploy to 3–10 representative sites; test app performance, failover, policy, runbooks
4. Phased rollout	Industrialize	Roll out in waves using templates and ZTP; review metrics after each wave
5. Optimization	Steady state	Tune Business Intent Overlays, path thresholds, security posture; iterate on operations

The design phase must be driven by requirements, not technology preference. Before choosing any appliance model, inventory sites, circuits, applications, and performance/security requirements — latency budgets, loss tolerance, availability targets, regulatory constraints. Classify applications by business criticality and performance sensitivity, because that classification becomes the raw material for your Business Intent Overlays (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 ticket volume. 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.

Replay

The pilot phase is where design assumptions meet reality. Choose 3–10 sites that collectively mirror your environment rather than your easiest sites: low-to-medium business risk but real usage; diverse connectivity (MPLS+DIA, broadband-only, LTE backup); application-mix coverage (a SaaS-heavy site and a latency-sensitive voice/VDI/EMR site); and local champions who can validate user experience. Pilot objectives should be explicit and measurable, tied to the baseline — for example, "improve voice MOS and reduce failover events." The pilot is where you refine the artifacts you will mass-produce: device templates, Business Intent Overlays, Zero-Touch Provisioning workflows, and runbooks.

Phased Migration from MPLS to Hybrid WAN

The migration from legacy MPLS to a hybrid WAN — one using MPLS, broadband, and/or LTE simultaneously as underlays — should be treated as coexistence then transition, never an abrupt cutover. 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; order new circuits early — ISP lead times are often the longest pole in the tent.
2. Overlay standup. Deploy EdgeConnect over the hybrid underlay, build overlays and BIOs, steer low-risk traffic across SD-WAN while critical traffic stays on MPLS.
3. Parallel run / gradual traffic shift. Move increasingly critical apps from MPLS to SD-WAN as performance is validated. Dynamic path selection, QoS, and FEC guarantee critical-app performance; keep a per-site fall-back (revert default route to MPLS) active throughout.
4. MPLS optimization or decommission. Retain a reduced MPLS footprint where strict SLAs or regulatory isolation justify it; elsewhere remove MPLS once operations are stable, update routing, and renegotiate contracts.

Cutover and Rollback Planning

Every site wave needs a documented rollback procedure before cutover begins. The core of any EdgeConnect rollback is simple: 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 back to the legacy edge router — not re-cabling. A practical per-wave cutover package contains a design/migration plan and site diagram, a test/validation checklist (reachability, hard and soft failover, monitoring), and rollback steps with a clear go/no-go decision point owned by a named person.

Example: A retail chain cutting over 40 stores schedules each 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 (POS reachable, voice MOS acceptable, SaaS breakout working, MPLS failover tested by disabling broadband), 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.

2. Day-2 Operations

Once sites are live, 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 makes this far more centralized than legacy WAN operations: most day-2 work happens in Orchestrator rather than by SSH-ing into individual routers.

Software Upgrade Strategy via Orchestrator

A software upgrade follows two firm rules: Orchestrator first, then appliances, and appliances in waves. Before touching any version, complete the pre-upgrade checklist: check compatibility (does the target Orchestrator support your current ECOS versions? read release notes for schema changes and deprecations); back up Orchestrator (export config + database, take a VM snapshot, confirm integrity); and set a change window during which policy changes are frozen.

Appliance upgrades are staged and pushed from Orchestrator: upload the new ECOS image per platform, create upgrade groups by region/role/impact, then schedule waves during low-traffic hours, ordered least-to-most critical. Upgrade non-critical sites → smaller branches → central hubs/DCs. For HA hubs, upgrade one appliance at a time: fail traffic over, upgrade the first, confirm health, then upgrade its partner. Avoid config changes during a wave — keep a single variable in flight.

Upgrade principle	Why it matters
Orchestrator first	Management plane must support the appliance versions it manages
Back up before upgrading	Snapshot/config export is the rollback path
Waves, least-critical first	Limits blast radius; a bad wave 1 stops wave 2
HA pair: one at a time	Maintains a forwarding path throughout
Freeze config during a wave	Isolates upgrade as the only change variable

After each wave, verify per-appliance that the device is Online with the new version, tunnels are up, and no new alarms appear. If tunnel issues appear only after an upgrade, the usual suspects are a new default behavior (changed cipher suite, path-SLA default, NAT detection) or a template inconsistency where a change did not reach every site.

Troubleshooting Tunnels and Path Issues

Effective troubleshooting starts with one decision: is this an overlay problem (tunnel config 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; if only some overlays are down it is an overlay/policy problem. Verify underlay reachability first (ping the peer WAN IP, check the WAN interface, routing, and UDP 500/4500 through any firewall/NAT) before touching any tunnel configuration.

Symptom	Likely cause
Phase 1 up, Phase 2 down	Transform-set / PFS mismatch, or proxy-ID mismatch
No IKE negotiation at all	Firewall or port issue (UDP 500/4500 blocked)
Worked before, failed after upgrade	New default cipher unsupported by older peer; PSK/cert not on both ends

Replay

Path issues are a distinct category: the tunnel stays up, but traffic suffers loss, latency, jitter, or flapping on a specific transport. Diagnose via Orchestrator's per-WAN-label path performance view (loss, latency, jitter, MOS, SLA status). Remediate by biasing the overlay toward a healthier transport, enabling FEC or packet duplication for real-time flows on a lossy Internet path, 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. A related complaint — "the tunnel is fine but the app is slow" — often points to Boost, which requires an active license on both ends and a symmetric path.

Capacity Planning and License Review

Capacity planning confirms that appliances, transports, and licenses still fit the load before users feel the squeeze. 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 effective throughput drops when many features are on. Size to peak WAN throughput plus 20–30% headroom over a 3–5 year horizon, and size up a model tier if you plan to enable many features. A quarterly review should ask whether appliances are above headroom, whether Boost/security licenses are active where the design expects (especially after HA or appliance replacement), and whether upcoming additions fit current Orchestrator sizing.

3. Putting It All Together

This final section synthesizes the whole book — architecture, models, licensing, and management — into one coherent picture. Consider a fictional enterprise, Meridian Retail: one primary data center, one secondary DC, three regional hubs (Americas, EMEA, APAC), and 600 branch stores.

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 few large or latency-sensitive sites. The selectivity is deliberate: meshing every site to every site explodes the tunnel count, so mesh is reserved for genuine site-to-site traffic (campuses, call centers) or strict low-latency needs.

Role	Typical model	Notes
Small branch (kiosk, clinic, small store)	EC-XS	Lowest throughput tier
Medium branch	EC-S	—
Large branch / regional hub	EC-M	Terminates a region's branch tunnels
Data center / large hub	EC-L	DC-grade throughput and tunnel scale

Redundancy. Hubs and data centers run dual EdgeConnect appliances with a dedicated HA link; tunnels over each underlay can connect to both appliances. At large hubs, each appliance terminates all transports (MPLS, Internet, LTE) so either one has a complete forwarding path. Routing is designed so each hub prefers its local EdgeConnect gateways, avoiding the asymmetric paths and ECMP behavior that break stateful firewalls.

Management and licensing. A single global Orchestrator — SaaS, on-prem VM, or cloud — drives ZTP, Business Intent Overlays, segmentation, path steering, and monitoring, with role-based access control and per-region templates. This is where the licensing model (Chapter 6) shows up operationally: the EdgeConnect base subscription plus Boost plus security tiers are all tracked and assigned centrally.

Replay

Notice how the four themes 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).

Common Pitfalls and Best Practices

Pitfall	Best practice
No WAN baseline	Measure latency, loss, jitter, ticket volume before you start
Per-site custom configs / config drift	Use central templates and BIOs; avoid site-specific exceptions
Hard MPLS cutover	Coexist then transition; keep per-wave rollback to legacy routing
Ignoring ISP lead times	Order circuits early; build last-mile redundancy into the plan
Alarm floods	Tune alarms to what matters: tunnel down, SLA breach, appliance unreachable, license fault
Overly strict SLA thresholds	Set realistic thresholds for Internet paths to avoid flapping
Security bolted on later	Align firewalls, segmentation, and Zero Trust/SASE from the start
Sizing to today's bandwidth	Size to peak + 20–30% headroom over 3–5 years, accounting for feature CPU cost

Two best practices deserve emphasis. First, standardize through templates and ZTP: appliances pre-registered by serial number auto-download their configuration on first boot and join the correct site group, making 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 authoritative documentation, data sheets, and training live under the Aruba brand. The most useful reference for design and sizing is the official Aruba EdgeConnect solution data sheet. Because throughput and tunnel figures change by generation, always validate sizing against the current data sheet for your hardware. The recommended progression: vendor documentation first; technical deep-dives and design guides; HPE Aruba role-based certifications (associate through expert, including SD-WAN/EdgeConnect tracks); and hands-on labs with virtual Orchestrator and EC-V appliances to practice ZTP, BIO design, upgrades, and tunnel troubleshooting safely.