Define Business Intent Overlays (BIO) and explain how they translate business policy into network behavior across an EdgeConnect SD-WAN fabric.
Configure overlay matching criteria, topology choices, and link bonding policy at a conceptual level.
Explain how routing segmentation and regions interact with overlays to provide isolation and scalability.
Pre-Reading Check — Section 1: The Business Intent Model
1. What best describes the role of a Business Intent Overlay (BIO)?
A per-device IPsec tunnel that an administrator hand-builds between two sites.
A high-level intent object that bundles topology, path/QoS/security/optimization policy for a class of traffic.
A monitoring dashboard that reports which flows hit which path.
A physical WAN circuit such as MPLS or broadband.
2. Why is Unity Orchestrator described as a "policy compiler"?
It compresses traffic before it crosses the WAN.
It writes C code that runs on each appliance.
It turns a few human-readable intent overlays into fabric-wide device configuration (tunnels, routing, QoS, SLA policies).
It encrypts the management session to each EdgeConnect device.
3. Overlay matching is evaluated first-match in order. Why does the ordering matter?
A broad rule placed above a specific one can "steal" traffic intended for the more specific overlay.
The last matching overlay always wins, so order is irrelevant.
Orchestrator evaluates all overlays in parallel and merges the results.
Ordering only affects QoS marking, not classification.
4. A Real-Time overlay prefers MPLS with a 150 ms / 1% loss SLA and a broadband backup. What happens the instant MPLS jitter breaches the threshold?
Nothing until the MPLS link physically fails.
The flow is dropped and the call ends.
Flows are steered to broadband immediately, then shift back when MPLS recovers.
The overlay is reclassified into the Transactional tier.
5. Which of these is the typical, recommended number of core overlays for an entire enterprise?
One overlay per application.
Roughly three to six.
One per site.
At least fifty, to maximize granularity.
1. The Business Intent Model
Key Points
A Business Intent Overlay (BIO) is one intent object that bundles topology, path selection/bonding, QoS, security/segmentation, and optimization for a class of traffic.
Orchestrator is a policy compiler: a few human-readable overlays become fabric-wide device configuration.
Classification is ordered first-match — order is load-bearing; a catch-all default overlay handles the rest.
The BIO's path policy chooses a preferred transport and fails over the moment a per-class SLA is breached — without waiting for the link to die.
From Business Intent to Network Policy
A Business Intent Overlay is a high-level, intent-based policy object that defines how a particular class of traffic should use the SD-WAN fabric. Rather than hand-building hundreds of per-site ACLs, QoS queues, and routing statements, the administrator describes the business intent once, and Unity Orchestrator compiles that intent into the detailed configuration pushed to every EdgeConnect appliance.
A single BIO bundles all of the following into one object:
Topology — who is allowed to talk to whom (mesh, hub-and-spoke, or regional mesh).
Path selection and link bonding — which underlay transports may be used and how multiple links are combined.
QoS — priority, queuing, bandwidth reservation, shaping, and DSCP marking.
Security and segmentation — the encrypted overlay and its separation from other overlays.
Optimization — Forward Error Correction (FEC), packet duplication, and WAN optimization.
The defining feature is abstraction. The administrator defines a small number of overlays tied to business purposes — Real-Time (voice/video), Transactional (ERP/CRM/database), Bulk/Best-Effort (backups, software distribution), and Internet/Guest — commonly only three to six overlays for an entire enterprise.
This is why Aruba calls Orchestrator a policy compiler: you write intent in human-readable form, and Orchestrator derives the fabric-wide design (tunnel matrix per overlay, site roles, primary/backup paths), generates device-level configuration, and continuously enforces and monitors that behavior.
Matching Traffic to Overlays
Classification is configured in Orchestrator and evaluated on a first-match, ordered basis. The first overlay whose criteria match a flow takes ownership of it; a catch-all default overlay handles anything that matches nothing above it.
Match category
Examples
Typical use
Application-based (DPI)
Signatures for Teams, Zoom, Salesforce, Office 365; custom apps by domain/IP/port
Map a site, department, or guest WLAN to an overlay
Layer-4 and QoS markers
TCP/UDP ports (e.g. UDP 5060, 16384–32767 for VoIP), DSCP (EF, AF21/AF31), 802.1p CoS
Honor or normalize upstream markings
Because matching is first-match, order is load-bearing. The standard ordering is: critical real-time apps first, transactional line-of-business apps next, bulk/file-transfer after that, then guest and internet, with everything else falling through to the default overlay. If a broad Transactional rule matching 10.0.0.0/8 sits above a Real-Time Teams match, Teams media (also from inside 10.0.0.0/8) loses its EF priority — the fix is to order the specific match above the broad one.
Preferred and Backup Transport Assignment
Once a flow is assigned to an overlay, the BIO's path policy decides which underlay transports it may use and in what order. EdgeConnect appliances continuously measure latency, loss, and jitter, and steer flows away from a path the moment it breaches per-class thresholds — without waiting for the link to fail outright. The administrator expresses this in business terms: allowed transports, preference order, SLA thresholds, and prohibited paths (e.g. "guest traffic must never use MPLS").
Animation: From Traffic Match to Transport Selection
A flow is matched (first-match) into the Real-Time overlay, routed onto preferred MPLS, then steered to broadband when the MPLS SLA is breached.
Preferred path (MPLS)Backup path on SLA breach (broadband)
Figure 4.3: From Traffic Match to Transport Selection — ordered first-match classifies a flow into an overlay, then the overlay's path policy chooses a preferred transport and falls back when the SLA is breached.
flowchart TD
START(["Incoming flow"]) --> M1{"Matches Real-Time overlay criteria?"}
M1 -->|Yes| OV["Assign to overlay"]
M1 -->|No| M2{"Matches Transactional overlay criteria?"}
M2 -->|Yes| OV
M2 -->|No| DEF["Default / catch-all overlay"]
DEF --> OV
OV --> PATH{"Preferred transport meets SLA?"}
PATH -->|Yes| PRIMARY["Send via preferred (e.g. MPLS)"]
PATH -->|"No (latency/loss/jitter breach)"| BACKUP["Steer to backup (e.g. broadband)"]
PRIMARY --> RECHECK{"SLA recovers?"}
BACKUP --> RECHECK
RECHECK -->|Yes| PRIMARY
RECHECK -->|No| BACKUP
Key Takeaway
A BIO is a single intent object that bundles topology, path selection, QoS, security, and optimization for one class of traffic. Orchestrator compiles that intent into fabric-wide configuration; ordered first-match decides which overlay owns each flow, and the path policy decides which transports it prefers.
Post-Reading Check — Section 1: The Business Intent Model
1. What best describes the role of a Business Intent Overlay (BIO)?
A per-device IPsec tunnel that an administrator hand-builds between two sites.
A high-level intent object that bundles topology, path/QoS/security/optimization policy for a class of traffic.
A monitoring dashboard that reports which flows hit which path.
A physical WAN circuit such as MPLS or broadband.
2. Why is Unity Orchestrator described as a "policy compiler"?
It compresses traffic before it crosses the WAN.
It writes C code that runs on each appliance.
It turns a few human-readable intent overlays into fabric-wide device configuration (tunnels, routing, QoS, SLA policies).
It encrypts the management session to each EdgeConnect device.
3. Overlay matching is evaluated first-match in order. Why does the ordering matter?
A broad rule placed above a specific one can "steal" traffic intended for the more specific overlay.
The last matching overlay always wins, so order is irrelevant.
Orchestrator evaluates all overlays in parallel and merges the results.
Ordering only affects QoS marking, not classification.
4. A Real-Time overlay prefers MPLS with a 150 ms / 1% loss SLA and a broadband backup. What happens the instant MPLS jitter breaches the threshold?
Nothing until the MPLS link physically fails.
The flow is dropped and the call ends.
Flows are steered to broadband immediately, then shift back when MPLS recovers.
The overlay is reclassified into the Transactional tier.
5. Which of these is the typical, recommended number of core overlays for an entire enterprise?
One overlay per application.
Roughly three to six.
One per site.
At least fifty, to maximize granularity.
Pre-Reading Check — Section 2: Overlay Configuration Elements
1. A 300-site network in a single global full mesh needs roughly how many tunnels, and what is the main drawback of full mesh?
~300 tunnels; the drawback is added latency through a hub.
~44,850 tunnels; the drawback is that tunnel count grows as N(N−1)/2 and is expensive at scale.
~600 tunnels; the drawback is weak encryption.
Exactly N tunnels; there is no real drawback.
2. Which link-bonding mode is best suited to large backups and file synchronization?
High availability (active/standby).
Load sharing / high throughput (active/active).
Packet duplication across two paths.
No bonding; single circuit only.
3. For a loss-sensitive real-time flow, what technique lets EdgeConnect recover lost packets without retransmission?
Increasing the TCP window size.
Forward Error Correction (FEC), or packet duplication across two paths.
Lowering the DSCP marking to best-effort.
Backhauling the flow to a data-center firewall.
4. Office 365 traffic is best served by which internet-breakout option, and why?
Backhaul to the data center, because central inspection is always required.
No breakout (deny), because SaaS is untrusted.
Local internet breakout, because it avoids needless backhaul latency for trusted SaaS.
Cloud security only, because Office 365 cannot be classified.
5. A PBF rule says "high-risk URL categories always go to Zscaler." Given the evaluation order, what does this guarantee?
Nothing — the BIO's default breakout always wins over PBF.
PBF takes precedence over the BIO's default breakout for the matched traffic.
The routing table is consulted before any policy.
It only changes QoS marking, not the forwarding path.
2. Overlay Configuration Elements
Key Points
Every BIO picks a topology: full mesh (lowest latency, N(N−1)/2 tunnels), hub-and-spoke (central inspection, extra latency), or regional mesh (the global compromise).
Link bonding has three modes: HA (active/standby), load sharing (active/active), and real-time (packet duplication / FEC).
One unified QoS policy (priority, guaranteed/ceiling bandwidth, DSCP marking) is pushed fabric-wide, so a flow is treated identically everywhere.
Internet breakout chooses local-direct, cloud-security service chaining, backhaul, or deny; PBF can override the BIO default per flow.
Topology: Mesh, Hub-and-Spoke, Regional
Every BIO specifies a topology, which determines which sites build tunnels to which others. Orchestrator combines the topology with each site's role to build only the required tunnels — the administrator never configures individual tunnel pairs.
Topology
Tunnel pattern
Best for
Trade-off
Full mesh
Every site to every other site
Real-time collaboration needing direct branch-to-branch paths
Tunnel count grows as N(N−1)/2; expensive at scale
Hub-and-spoke
Spokes tunnel only to hub(s)
Centralized DC apps, central security inspection, backups
Branch-to-branch traverses the hub, adding latency
Regional mesh
Full mesh within each region; hubs interconnect regions
Large global deployments
More complex region/hub planning
Animation: Overlay Topologies Morphing
The same set of sites re-tunnels as the overlay topology changes: full mesh → hub-and-spoke → regional mesh.
Intra-region / mesh tunnelInter-region hub link
Figure 4.4: Overlay Topology Patterns. Full mesh gives lowest latency (no hub detour) but its tunnel count is the classic scaling problem — 300 sites in one mesh need roughly 44,850 tunnels. Hub-and-spoke suits traffic that should pass a central point. Regional mesh is the compromise for global networks.
Link Bonding Policy and QoS
The link-bonding strategy defines how multiple WAN transports are combined for a traffic class:
High availability (active/standby) — primary carries traffic; secondary used only on failure/SLA breach. Suits transactional apps.
Load sharing / high throughput (active/active) — traffic spread across circuits. Ideal for bulk transfers and backups.
Real-time performance — duplicate packets across two paths (first copy wins), or apply FEC on a single path to reconstruct loss without retransmission.
Layered on top of bonding is the overlay's QoS policy:
Minimum (guaranteed) and maximum (ceiling) bandwidth, shaping
Reserve 30% for voice; cap backups at 20%
Marking and remarking
DSCP and 802.1p CoS marking/remarking
Set DSCP EF outbound so the MPLS carrier honors voice
Because Orchestrator pushes one unified QoS policy to every appliance, a Real-Time flow is treated identically — same priority, reservation, and DSCP — whether it starts in New York or Singapore.
Figure 4.1: Anatomy of a Business Intent Overlay — one overlay object as a stack of layers, compiled by Orchestrator into per-appliance configuration.
graph LR
subgraph BIO["Business Intent Overlay (intent object)"]
direction TB
L1["Topology (mesh / hub-spoke / regional)"]
L2["Path and Bonding Policy (allowed transports, preference, SLA)"]
L3["QoS (priority, bandwidth, DSCP marking)"]
L4["Security and Segment (encrypted overlay, isolation)"]
L5["Optimization (FEC, packet duplication, WAN opt)"]
L1 --> L2 --> L3 --> L4 --> L5
end
ORCH["Unity Orchestrator (policy compiler)"]
BIO --> ORCH
ORCH --> C1["Per-appliance IPsec tunnel matrix"]
ORCH --> C2["Routing and segmentation entries"]
ORCH --> C3["QoS schedulers and DSCP rules"]
ORCH --> C4["Path-control SLA policies"]
Internet Breakout and Service Chaining
Internet-bound flows need a separate decision. The fabric first determines whether a destination is corporate (learned via overlay, configured statically, or learned via BGP/OSPF/MPLS) or internet (anything not matching a known corporate prefix). The BIO then applies one of:
Local internet breakout (direct) — egress out the local broadband/DIA link with source NAT. Best for trusted, latency-sensitive SaaS such as Microsoft 365 and Zoom.
Breakout via cloud security — IPsec/GRE tunnel to a provider such as Zscaler or Palo Alto Prisma Access for URL filtering, IPS, and SSL inspection.
Backhaul to hub or data center — ride the overlay to a hub firewall, then break out. Simpler central security, more latency.
No breakout (deny) — for sensitive internal-only applications.
Service chaining steers selected traffic through an external security service; Orchestrator automates redundant tunnel creation to the chosen enforcement nodes. Policy-Based Forwarding (PBF) can override the overlay default per flow. The evaluation order is: security/policy rules first, then BIO mapping, then PBF, then the routing table — so a PBF rule "high-risk URLs always go to Zscaler" takes precedence over the BIO's default breakout.
Key Takeaway
Each overlay specifies a topology, a link-bonding mode (HA, load sharing, or real-time duplication/FEC), a QoS profile, and an internet-breakout behavior. Service chaining and per-flow PBF rules let traffic reach cloud security or local breakout exactly as policy dictates.
Post-Reading Check — Section 2: Overlay Configuration Elements
1. A 300-site network in a single global full mesh needs roughly how many tunnels, and what is the main drawback of full mesh?
~300 tunnels; the drawback is added latency through a hub.
~44,850 tunnels; the drawback is that tunnel count grows as N(N−1)/2 and is expensive at scale.
~600 tunnels; the drawback is weak encryption.
Exactly N tunnels; there is no real drawback.
2. Which link-bonding mode is best suited to large backups and file synchronization?
High availability (active/standby).
Load sharing / high throughput (active/active).
Packet duplication across two paths.
No bonding; single circuit only.
3. For a loss-sensitive real-time flow, what technique lets EdgeConnect recover lost packets without retransmission?
Increasing the TCP window size.
Forward Error Correction (FEC), or packet duplication across two paths.
Lowering the DSCP marking to best-effort.
Backhauling the flow to a data-center firewall.
4. Office 365 traffic is best served by which internet-breakout option, and why?
Backhaul to the data center, because central inspection is always required.
No breakout (deny), because SaaS is untrusted.
Local internet breakout, because it avoids needless backhaul latency for trusted SaaS.
Cloud security only, because Office 365 cannot be classified.
5. A PBF rule says "high-risk URL categories always go to Zscaler." Given the evaluation order, what does this guarantee?
Nothing — the BIO's default breakout always wins over PBF.
PBF takes precedence over the BIO's default breakout for the matched traffic.
The routing table is consulted before any policy.
It only changes QoS marking, not the forwarding path.
Pre-Reading Check — Section 3: Segmentation and Regions
1. A routing segment behaves like a VRF. What is the most important consequence of that?
All segments share one routing table, so IP ranges must be unique.
Each segment has its own routing table, so segments may even reuse overlapping IP ranges.
Segments automatically leak routes to each other for convenience.
Segmentation is applied on the WAN/underlay ports.
2. How does traffic move from the Corp segment to the PCI segment when policy allows it?
The EdgeConnect appliance routes directly between the two segments.
Routes are automatically leaked between segments by Orchestrator.
It is bridged only through an external firewall that enforces inter-zone policy.
It cannot move at all under any circumstances.
3. What gets assigned to exactly one segment, and what is NOT segmented?
WAN ports are segmented; LAN interfaces are shared across segments.
Each LAN-side interface/VLAN binds to exactly one segment; WAN/underlay ports are not segmented.
Both LAN and WAN ports must be in the same single segment.
Only dynamic-routing neighbors are segmented; interfaces are global.
4. Regional mesh (3 regions of 100 sites) versus a single global mesh of 300 sites — why does regional mesh scale better?
It encrypts fewer packets per tunnel.
Sites mesh only within their region, cutting ~44,850 tunnels to roughly 14,850 plus a few inter-region hub tunnels.
It removes the need for any hubs.
It merges all regions into one routing table.
5. Which statement about the Interface → Segment → Overlay relationship is correct?
An overlay can span multiple segments at once.
An overlay is bound to a single segment, but one segment can host multiple overlays.
Each segment may host exactly one overlay.
Interfaces bind directly to overlays, skipping segments.
3. Segmentation and Regions
Key Points
A routing segment is a VRF-like instance: its own routing table, default route, and dynamic-routing instances — so segments may reuse overlapping IP ranges.
Each LAN interface/VLAN binds to exactly one segment; WAN/underlay ports are not segmented. Segments are isolated and bridged only through an external firewall.
Regions scale overlays: sites full-mesh within a region; hubs/core sites interconnect regions, sharply cutting tunnel counts.
The hierarchy is Interface → Segment → one-or-more Overlays → Region-constrained tunnels; an overlay binds to one segment, a segment hosts many overlays.
Routing Segments (VRF-Like Zones)
A routing segment behaves like a VRF: a completely separate routing table on each appliance, with its own default route, learned prefixes, and dynamic routing (BGP or OSPF). Because each segment is independent, segments may reuse overlapping IP ranges — two tenants can both use 10.0.0.0/8 without conflict. There is always a default/global segment (often ID 0); others carry names like Corp, Guest, PCI, or IoT.
The binding rules are precise:
Every LAN-side interface, sub-interface, or VLAN is assigned to exactly one segment, which determines its routing table and the overlay tunnels it may use.
WAN/underlay ports are not segmented; segmentation happens at the overlay level.
Dynamic routing is per-segment: a BGP neighbor in the Guest segment advertises and receives only Guest routes.
Segments are isolated by design — no automatic route leaking. To allow controlled Corp-to-PCI communication, you route both segments into an external firewall; the EdgeConnect appliance is deliberately not a general inter-segment router. This is why troubleshooting always starts with "which segment is this interface, route, or overlay in?"
Animation: Routing Segments as Isolated VRF-Like Zones
Three LAN VLANs bind to isolated segments. A direct Corp→PCI attempt is blocked; the only legal path crosses an external firewall.
Blocked direct leakLegal path via firewall
Figure 4.5: Routing Segmentation as VRF-Like Zones — LAN interfaces bind to isolated segments, each with its own routing table and overlays; segments never leak routes directly and are bridged only through an external firewall.
A full mesh scales as N(N−1)/2 tunnels — unmanageable for hundreds of global sites. Regions are the scaling mechanism: sites are grouped (AMER, EMEA, APAC) and, for a given overlay, the administrator picks regional mesh. Sites then full-mesh only within their region, while inter-region connectivity flows through designated hub/core sites.
Design
Tunnel calculation
Approx. tunnels
Global full mesh, 300 sites
300 × 299 / 2
~44,850
Regional mesh, 3 regions of 100
3 × (100 × 99 / 2)
~14,850 + a few inter-region hub tunnels
The mapping hierarchy ties everything together: Interface → Segment → one or more Overlays → tunnels constrained by Regions. An overlay is always bound to a single segment, but a segment can host multiple overlays. For instance, the Corp segment might carry a Corp-Data overlay (regional mesh) and a Corp-Voice overlay (prefer MPLS, strict SLA) simultaneously — both share the Corp routing table, yet each uses a different topology and policy.
Because each segment is an isolated routing domain, segmentation is the foundation of the security posture. Hard separation requirements — PCI cardholder data, OT/IoT apart from IT, guest apart from corporate — map naturally onto separate segments, each with its own overlays and breakout. A retailer might place point-of-sale terminals in a PCI segment (hub-and-spoke to a hardened DC, no local breakout) while guest Wi-Fi sits in a Guest segment (local breakout via Zscaler, never reaching corporate prefixes).
Design guidance favors restraint: a typical enterprise uses only two to five segments. Over-segmentation multiplies complexity, and heavy inter-segment traffic signals the boundary may be drawn in the wrong place. Small networks (under ~50 sites) often need no regions at all.
Key Takeaway
Routing segments provide VRF-style isolation per LAN interface and are bridged only through external firewalls, while regions scale overlays by meshing within regions and interconnecting through hubs. The hierarchy — Interface → Segment → Overlays → Region-constrained tunnels — is the model for both designing and troubleshooting an EdgeConnect fabric.
Post-Reading Check — Section 3: Segmentation and Regions
1. A routing segment behaves like a VRF. What is the most important consequence of that?
All segments share one routing table, so IP ranges must be unique.
Each segment has its own routing table, so segments may even reuse overlapping IP ranges.
Segments automatically leak routes to each other for convenience.
Segmentation is applied on the WAN/underlay ports.
2. How does traffic move from the Corp segment to the PCI segment when policy allows it?
The EdgeConnect appliance routes directly between the two segments.
Routes are automatically leaked between segments by Orchestrator.
It is bridged only through an external firewall that enforces inter-zone policy.
It cannot move at all under any circumstances.
3. What gets assigned to exactly one segment, and what is NOT segmented?
WAN ports are segmented; LAN interfaces are shared across segments.
Each LAN-side interface/VLAN binds to exactly one segment; WAN/underlay ports are not segmented.
Both LAN and WAN ports must be in the same single segment.
Only dynamic-routing neighbors are segmented; interfaces are global.
4. Regional mesh (3 regions of 100 sites) versus a single global mesh of 300 sites — why does regional mesh scale better?
It encrypts fewer packets per tunnel.
Sites mesh only within their region, cutting ~44,850 tunnels to roughly 14,850 plus a few inter-region hub tunnels.
It removes the need for any hubs.
It merges all regions into one routing table.
5. Which statement about the Interface → Segment → Overlay relationship is correct?
An overlay can span multiple segments at once.
An overlay is bound to a single segment, but one segment can host multiple overlays.
Each segment may host exactly one overlay.
Interfaces bind directly to overlays, skipping segments.