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

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:

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 those roads. The overlays are your shipping policies — "perishable goods take the fastest clean route; bulk freight takes whatever is cheapest." Dynamic Path Control 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 — the secret behind its fast failover.

Auto-discovery and automatic tunnel creation

In a traditional WAN an engineer configures every tunnel by hand. For a 100-site mesh that is thousands of tunnels and a configuration nightmare. EdgeConnect replaces this with orchestration:

1. Site definition and WAN uplinks. Each appliance registers with Orchestrator. You declare each WAN interface, give it a label (MPLS, INET, LTE), and set addressing (static, DHCP, or behind NAT).
2. Topology selection. You choose full mesh, hub-and-spoke, or regional hubs. Orchestrator computes which sites tunnel to which, over which labels — the auto-discovery step.
3. Automatic IPsec tunnel creation. Orchestrator pushes endpoints, IKE/IPsec parameters, and NAT-traversal settings; appliances negotiate IKE, build the security associations, and register each tunnel as a logical "WAN path."
4. Tunnel health monitoring. Every tunnel is then continuously monitored for latency, loss, jitter, and availability — the live data that feeds path selection.
5. Route distribution. LAN networks learned via static, OSPF, or BGP are advertised across the fabric — but DPC, not the routing protocol, decides which tunnel carries which flow.

The result: between any two sites you typically have multiple parallel IPsec tunnels, one per underlay, all up and all monitored at once.

Figure 3.1: The three-layer EdgeConnect model.

Topology options

With the fabric in place, the question becomes: of the several tunnels available between two sites, which should carry a given packet right now? Answering 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.

Business Intent Overlays: expressing what you want

DPC steers according to Business Intent Overlays (BIOs). Each BIO specifies:

• What traffic matches — by L7 application ID, FQDN, IP prefixes, ports, subnets, DSCP, VLANs, or user groups.
• Path preferences — allowed WAN labels, priority order, primary/secondary/backup roles, and local breakout vs hub backhaul.
• SLA thresholds — maximum acceptable latency, jitter, and loss, plus how aggressively to react.
• Forwarding behavior — per-flow vs per-packet, FEC, packet duplication, retransmission, and QoS marking.

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.

Per-flow versus per-packet steering

Per-flow (default). A flow is identified by its 5-tuple. DPC filters out disallowed or SLA-violating tunnels, ranks the survivors, then hashes each new flow to the single best tunnel and pins it there until that tunnel fails or breaks SLA. Same path for every packet means in-order arrival — what TCP prefers.

Per-packet (tunnel bonding). DPC stripes the packets of a single flow across multiple tunnels at once for bandwidth and resiliency, but packets can arrive out of order, so the receiver must resequence them.

Figure 3.4: The Dynamic Path Control decision flow.

Brownout and blackout detection and failover

A link can fail two ways. A blackout is a hard failure: probes stop, the tunnel is declared down, and it leaves the candidate set immediately. A brownout is insidious: the tunnel is still up — probes and traffic pass — but a metric breaches the SLA (loss > 2%, latency > 150 ms). The path is marked degraded, not down, and can be direction-specific.

Each path lives in one of three states — Healthy, Degraded, or Down. New flows go to a healthier transport; 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 stay put unless degradation is severe.

Figure 3.5: Path state machine.

Tunnel bonding policy modes

Trade-offs are real: striping across links of different latency increases reordering, adds buffering delay, and parity/duplication add bandwidth overhead. So bonding is reserved for flows that genuinely benefit.

Forward Error Correction (FEC)

FEC trades a little extra bandwidth for a lot of reliability. The sender groups packets into blocks, computes one or more redundant parity packets per block, and transmits the parity alongside the originals — in parallel with the data, so the receiver reconstructs a lost packet without waiting for retransmission.

Mechanism (illustrative). Take D1–D4 and compute parity P (think XOR of the four). Transmit D1, D2, D3, D4, P. If one Dx is lost but P and the other three arrive, the receiver rebuilds the missing packet — no retransmission, no slow-start penalty. A 4+1 scheme cannot recover two losses in one block, which is why ratios are adjustable (4+1, 8+2).

FEC is adaptive: it raises the ratio when loss is high and lowers it when clean. Both sliders at 100% approximates HA-style 1:1 FEC; both at 0% disables it. With a single tunnel, FEC overhead caps around 20%. FEC pays off most on Internet/LTE/satellite at ~1–5% loss and for real-time UDP where retransmission is useless.

Figure 3.2: FEC reconstructing a lost packet.

Packet Order Correction (POC)

FEC fixes lost packets. POC fixes out-of-order packets — an unavoidable side effect of per-packet steering across links of different latency, ECMP, and asymmetric routing. To TCP, out-of-order delivery looks like loss: duplicate ACKs, spurious fast-retransmits, needless congestion-window cuts.

POC uses a resequencing buffer on the receiver. EdgeConnect stamps each overlay packet with its own sequence ID — independent of IP/TCP numbers — caches out-of-order packets, and uses a configurable, RTT-based reorder wait time before giving up on a late packet. Packets are then delivered to the LAN in order.

Example. Path A has 20 ms latency, Path B has 60 ms. The sender stripes 1→A, 2→B, 3→A; they arrive 1, 3, 2. Without POC, TCP may fast-retransmit. With POC, the receiver holds 3, waits briefly for 2, then delivers 1, 2, 3 — trading a few ms of buffering for a clean stream.

Tuning is a balance: too short and reordering leaks through; too long and added latency hurts interactive traffic. Rule of thumb: a shorter wait for voice/real-time, a longer wait for TCP and high-throughput flows.

Path Conditioning: FEC and POC together

FEC and POC together are path conditioning, applied inside the overlay to make a messy WAN path look clean. On a typical Internet path, loss and reordering coexist; FEC handles loss, POC handles reordering, and endpoints experience something close to a private, in-order WAN.

The independent proof point comes from Miercom: path conditioning preserved acceptable voice MOS with up to roughly 55% aggregate underlay loss (50% on one link, 5% on another), because the parity stream on the second link reconstructed what the first dropped.