Past the SD-WAN label
Most people run EdgeConnect as two circuits with automatic failover. It does that. It also does more, and the extra is where the value sits. EdgeConnect came out of Silver Peak. Its roots are WAN optimisation and path control. Run it as failover only and you use a fraction of it.
Here is what the rest does, and how we design it.
Business Intent Overlays
The core construct is the Business Intent Overlay, or BIO. You define an overlay per class of application. Each one carries the intent for that class. Real-time traffic gets low latency and preferred transports. Bulk traffic takes the cheaper path. EdgeConnect maps applications to overlays and applies the policy at every site.
Adding a site becomes a policy change. The common mistake is too many overlapping overlays. Then you get a policy set nobody wants to touch. Keep them few. Define them by intent.
Define overlays by application intent
Do not mirror your circuits with overlays. Group traffic by intent: real-time, transactional, bulk, guest. Let EdgeConnect pick the transport per packet. A handful of overlays covers a large estate.
Path conditioning
Path conditioning is where most deployments leave value unused. It applies forward error correction and packet order correction. FEC rebuilds dropped packets from parity. It avoids waiting for a retransmission. Packet order correction resequences packets before the application sees them. With tunnel bonding across links, broadband carries voice and video like a private line.
FEC adds a small bandwidth overhead. Apply it to voice, video and interactive traffic. Leave it off bulk transfers. Tuning this per overlay is the work that matters.
First-packet iQ and breakout
Standard SD-WAN identifies an application a few packets into a flow. By then the first flow is already routed on a guess. First-packet iQ classifies on the first packet using a hosted application database. Local internet breakout then works from packet one. SaaS traffic leaves locally instead of being backhauled.
Secure internet breakout steers each flow by classification. Traffic goes out to trusted SaaS, to a data centre, or to a security stack for inspection. That steering decision is the link to the security side.
Where SASE fits
EdgeConnect is the connectivity half of SASE. The security service edge is the other half. It inspects and enforces on traffic after breakout. HPE Aruba Networking pairs EdgeConnect with its own SSE. It also automates integration with Zscaler, Netskope and Palo Alto Networks. That matters when you already run one of those stacks.
Design both halves together. Breakout policy and inspection points are one decision. We treat secure multi-site connectivity and the security edge as one SASE design.
What we see go wrong
The recurring failures are design decisions, not the technology.
- Overlay sprawl. Overlapping overlays nobody will touch. Keep them few and intent-led.
- Path conditioning left at defaults. The main benefit goes unused.
- Two circuits from one provider over one backhaul. They fail together.
- Breakout and security designed apart. Enforcement ends up inconsistent.
- No baseline before cutover. You cannot prove the change or find a regression.
The underlay decides the ceiling
EdgeConnect works well over poor links. It cannot create diversity that is not there. Check the physical path of each site's circuits first. Two circuits sharing a duct or an aggregation point fail together.
How we'd approach it
We work in this order. Map the applications and what each class needs. Confirm the real transport diversity at each site. Design overlays by intent. Set path conditioning to match the traffic. Design breakout and security in the same pass. Cut over beside the existing WAN, measured against a baseline.
We have run SD-WAN since 2018, EdgeConnect included. If yours runs at failover only, start with a design review.