Worked Example: SD-WAN B2B

The account manager and solution architect design the SD-WAN topology: hub-spoke with Sydney CBD HQ as the dual-underlay hub, 7 branch clinics as internet-only spokes. Application-aware routing policies are defined during the design phase: clinical applications → MPLS (priority), email and web → DIA (best-effort), video conferencing → load-balanced across both underlays. The hub acts as the central traffic breakout point — all branch traffic egresses through the hub for security inspection and internet access.

CPQ runs feasibility checks per site. HQ — MPLS feasible (existing PE router PE-SYD-01 at Sydney CBD exchange with available capacity), DIA feasible (local ISP fibre handoff). Branches — DIA feasibility varies: 5 sites have fibre availability, 2 sites require 4G backup as secondary path. All 8 sites pass minimum bandwidth requirements for the Managed SD-WAN Gold product specification.

Hub CPE: Cisco vEdge 2000 — dual WAN interfaces, hardware-accelerated crypto, 1 Gbps aggregate throughput, suitable for dual-underlay hub role. Branch CPE: Cisco vEdge 620 — single WAN interface, 300 Mbps throughput, suitable for internet-only branch sites. All CPE devices are pre-staged at the operator warehouse with base ZTP configuration (bootstrap config containing vManage controller address and authentication certificates).

Gold SLA selected: 99.95% availability, <50 ms latency hub-to-branch, 4-hour restore for any site. Pricing: HQ $3,500/month (dual underlay + premium vEdge 2000 CPE), branches $1,200/month each (DIA underlay + vEdge 620 CPE). Total monthly: $3,500 + (7 × $1,200) = $11,900/month. Total 36-month contract value: $428,400.

Pilot phase: HQ + 1 branch (target T+14 days). Wave 1: 3 branches (target T+30 days). Wave 2: 3 branches (target T+45 days). The hub must complete before any branch — this is a hard dependency driven by the hub-spoke topology. The pilot branch validates end-to-end hub-to-branch connectivity before scaling to the remaining 6 sites.

CPQ submits a TMF622 POST /productOrder request to COM containing 8 Product Order Items (one per site). Each POI is tagged with siteRole (hub or branch), underlayType (dual or internet-only), rolloutPhase (pilot, wave1, wave2), and cpeModel (vEdge 2000 or vEdge 620). The phased rollout schedule and hub-spoke dependency are captured as order-level metadata.

COM validates the enterprise contract terms: 36-month commitment confirmed, Gold SLA tier available at all 8 sites, negotiated pricing approved by commercial review. Credit check passes — MediCorp Health Group has an existing enterprise account in good standing, and the $428,400 contract value is within the approved credit limit. No deposit required.

COM reads Product Specification PS-SDWAN-01 and decomposes differently based on site role. Hub site receives 3 CFS: CFS:SD-WAN-Overlay (siteRole=hub), CFS:Underlay-MPLS (100 Mbps PE circuit), CFS:Underlay-DIA (200 Mbps internet). Each branch site receives 2 CFS: CFS:SD-WAN-Overlay (siteRole=branch), CFS:Underlay-DIA (100 Mbps internet). Total CFS count: hub (3) + 7 branches × 2 = 17 service order items across all sites.

COM tags the hub service order as a dependency for all branch service orders. This is a hard constraint: SOM will enforce that the hub must reach "completed" state before any branch service order begins processing. This dependency is driven by the network topology — branches connect TO the hub for traffic breakout, so they have nowhere to send traffic until the hub is operational.

COM creates 4 service orders aligned to the rollout plan and hub-spoke dependency: SO-PILOT-HUB (hub site, 3 SOIs — overlay + MPLS + DIA), SO-PILOT-BR1 (branch 1, 2 SOIs — overlay + DIA, depends on SO-PILOT-HUB), SO-WAVE1 (branches 2–4, 6 SOIs — 3 branches × 2 CFS each, depends on SO-PILOT-HUB), SO-WAVE2 (branches 5–7, 6 SOIs — 3 branches × 2 CFS each, depends on SO-PILOT-HUB). SO-PILOT-HUB is submitted to SOM immediately. All others are held pending hub completion.

ROM's NSO adapter configures PE-SYD-01 interface GigE0/0/1 via NETCONF. The interface is brought up in VRF MEDICORP with the appropriate encapsulation (dot1q or native, depending on access handoff). NSO pushes the configuration transaction and confirms commit success on the PE router.

ROM's NSO adapter pushes the L3VPN service model to PE-SYD-01. VRF MEDICORP is created with route-distinguisher 65000:2208 and route-target 65000:2208. MPLS label is allocated from the label space. BGP VPNv4 session is established with the route reflector, advertising the MEDICORP VRF prefixes.

ROM requests a /30 subnet from IPAM for the PE-CE link: 10.200.22.0/30 allocated. PE side: 10.200.22.1 (configured on GigE0/0/1 in VRF MEDICORP). CE side: 10.200.22.2 (will be used by vEdge 2000 MPLS WAN interface). IPAM record updated with allocation purpose, site reference, and DNS entries.

ROM's Internet Gateway adapter provisions a 200 Mbps DIA circuit at the Sydney CBD exchange. NAT/PAT is configured for the enterprise address range. Enterprise-grade firewall policy (enterprise-gold) is applied, permitting SD-WAN control plane traffic (DTLS, IPsec) and blocking known threat vectors.

ROM allocates a /29 public IP block from IPAM: 203.0.113.0/29 (6 usable addresses). These are used for the SD-WAN WAN interface (DIA side), management access, and NAT pool. IPAM records the allocation with purpose "DIA-public-block" and links it to the MediCorp HQ site.

ROM triggers shipment of pre-staged vEdge 2000 (S/N: VEDGE2K-HQ-001) from the operator warehouse to MediCorp HQ. On-site, the device is powered on and boots into factory default. It contacts the ZTP server via DHCP Option 66, downloads the bootstrap configuration containing: vManage controller address, MPLS WAN interface IP (10.200.22.2/30), DIA WAN interface IP (203.0.113.2/29), authentication certificates, and organisation ID.

Once the vEdge 2000 contacts vManage and establishes a DTLS control connection, ROM's SD-WAN controller adapter pushes the "gold-hub-vedge2000" device template via RESTCONF. The template configures: dual WAN interfaces (MPLS transport with colour "mpls" + DIA transport with colour "biz-internet"), LAN-side interfaces for the HQ network, OSPF routing towards the MPLS PE, TLOC extensions for both transports, and BFD probes for path liveness detection.

ROM's SD-WAN controller adapter pushes the application-aware routing policy to the hub via vManage. Policy rules: clinical applications (identified by DSCP markings and application signatures) → MPLS path (priority, strict SLA), email and web traffic → DIA path (best-effort), video conferencing → load-balanced across MPLS and DIA (weighted ECMP). The policy is activated and vManage confirms policy compliance on the hub device.

All 8 hub ROIs complete successfully. ROM publishes ResourceOrderItemStateChangeEvent for each completed item. The hub site is now fully operational: MPLS underlay active (PE interface up, L3VPN routing established), DIA underlay active (internet gateway provisioned, public IPs assigned), vEdge 2000 registered in vManage (ZTP complete, device template applied), and application-aware routing policy active.

SOM evaluates its orchestration plan as each ROI completes. When all 8 ROIs are done, the 3 hub SOIs are marked complete: SOI-001 (SD-WAN Overlay), SOI-002 (Underlay MPLS), SOI-003 (Underlay DIA). SO-PILOT-HUB is marked "completed". Service instances are created in Service Inventory. SOM releases the hub-spoke dependency: SO-PILOT-BR1 can now proceed.

Branch 1 follows the same pattern but is simpler than the hub: DIA-only underlay (no MPLS), branch device template (gold-branch-vedge620), and no application-aware policy configuration (branches inherit policy from the hub via vManage). The vEdge 620 completes ZTP, connects to vManage, receives its branch template, and establishes an IPsec overlay tunnel to the hub. Branch validates: can reach hub, application policies are working, hub-to-branch latency measured.

SO-PILOT-BR1 completes. Both pilot sites are operational: hub and branch 1 connected via SD-WAN overlay. SLA monitoring confirms hub-to-branch latency is under 50 ms. Application-aware routing validated: clinical traffic traverses MPLS at hub, branch traffic reaches hub via DIA overlay tunnel. COM is notified and triggers Wave 1.

Wave 1 (3 branches) starts immediately after pilot completion. Each branch takes approximately 3–5 days: CPE shipping (1–2 days), ZTP and vManage registration (same day), overlay tunnel establishment and validation (same day). Branches within the same wave run in parallel — they are independent of each other. Wave 2 (3 branches) starts after Wave 1 completes. The same pattern repeats.

All 8 sites are active. vManage shows the full hub-spoke topology: 1 hub with 7 branch tunnels. SLA probes are active at all 8 sites, confirming Gold SLA compliance. Application-aware routing is operational across the entire overlay. COM marks PO-2024-01890 as "completed". Billing activates: HQ at $3,500/month, 7 branches at $1,200/month each. Total rollout duration: approximately 40–45 days.