Skip to main content
BSS/OSS Academy
Domain Examples/Enterprise SD-WAN — Managed

Enterprise SD-WAN — Managed

How a managed SD-WAN site is added to an enterprise’s existing network end to end: the product sells an edge size and access, SOM decomposes a site service under the customer’s network service, ROM reserves and activates the underlay and the edge from inventory and IPAM, SOM configures the overlay through the SD-WAN controller as its own domain, and verification — not "config applied" — completes the order. Cisco Meraki is the worked vendor; the architecture is vendor-neutral.

Architecture Overview

BSS — Commercialsells the service · manages what was orderedSOM — Service Order Managementwhat service must exist — calls the controller directly, configures nothing itselfROM — Resources, Inventory & IPAMunderlay, edge asset and addresses — never the overlayDomainscontroller: the overlay · NMS: the access · assurance: is it working?adapter → Dashboard API v1COM captures the product order: add a site to the existing SD-WAN. No circuit, address or serial is named.Customer orderCOM · PO-88213Sells an edge size, an access and profiles — never a device model. The resource catalog maps size to model.Product Catalogedge size · access · profilesSOM creates the site service under the customer’s existing network service, and derives the RFS.Service decompositionsite CFS under network CFSSOM sequences the work: a resource order to ROM, the overlay to the SD-WAN controller, completion only after verification.Service orchestrationresources → ROM · overlay → controllerRecords the site service under the network service, with the controller’s ids as references — not copies of its configuration.Service inventorysite + network CFS · controller refsThe access port, circuit, handoff VLAN and edge asset, each with its state.Resource inventoryport · circuit · VLAN · edgeSystem of record for addressing: the WAN /30 of the operator’s access and the site LANs, unique across the overlay. Never the customer line’s address.IPAMWAN /30 · LAN /24ROM reserves the underlay, the addresses and the edge, and has the access NMS build the DIA. It never touches the overlay.Resource fulfilmentreserve → activateCisco Meraki SD-WAN: Meraki Dashboard (cloud). Holds the overlay: the site object, the claimed edge, tunnels, policy. Called by SOM through an adapter.Meraki Dashboardoverlay · system of recordConfigures the operator’s access: the port, the handoff VLAN, the bandwidth profile and the PE interface. Executes; does not choose.Access NMSport · VLAN · PEProves the site end to end before completion, then monitors it and ties alarms to the site service.Assuranceverify · monitor · correlateBranch siteUnderlay — two WANsInternetHubs — HQ & DCSaaSWAN1 · DIAWAN2local breakoutoverlay — encrypted tunnels to both hubsOslo Branch LAN: Corporate VLAN 10 (10.10.7.0/24), IoT VLAN 30, Guest VLAN 20 (local only).switchLAN 10.10.7.0/24Corp · IoT · GuestSD-WAN edge CPE-84721, serial Q2XX-AAAA-1111 — a Medium edge (Meraki MX95 in the worked example). Holds no configuration of its own: it fetches what the controller holds.EdgeCPE-84721Medium edgeThe operator’s access: ACC-OSL-07 ge-0/0/12, handoff VLAN 2107, circuit CIR-00123 at 500 Mbit/s, PE side 203.0.113.9/30. Reserved by ROM, configured by the access NMS.Access + PEge-0/0/12 · VLAN 2107The customer’s own broadband (CUST-BB-5521), addressed by DHCP from its ISP. A reference in inventory: the operator does not order, reserve or configure it.Customer ISPreference only · DHCPInternetThe hubs, already live: HQ Oslo (priority 1) and DC London (priority 2). The branch joins as a spoke.HQ Oslo · hub 1DC London · hub 2SaaS · InternetM365 · collaboration
InventoryAccess portCIR-00123VLAN 2107WAN /30LAN /24Edge CPE-84721LicenceWAN2 customer line · REFERENCE

Pick a scenario and press Simulate an activation. New site follows PO-88213 from the order to a verified, live Oslo Branch; Edge never checks in shows what happens when the box on site is not the one claimed; Increase bandwidth takes the live site from 500 Mbit/s to 1 Gbit/s and shows which systems are not involved. The platform dropdown relabels the controller — the boundaries do not move.

Cisco Meraki SD-WAN — managed from Meraki Dashboard (cloud); customer tenant: organisation; configuration by per-network configuration; templates optional; device identity: serial; API: Dashboard API v1 (REST). SOM’s contract with the adapter stays the same.

Branch site & LAN

Oslo Branch (SITE-OSL-002): users on Corporate, Guest and IoT segments. The Corporate LAN 10.10.7.0/24 comes from IPAM and must be unique across ACME’s overlay, or the hubs cannot route to it.

SD-WAN edge

One appliance (CPE-84721, a Medium edge — Meraki MX95 in the worked example) with two uplinks. It holds no local configuration of its own: it fetches what the controller holds, builds the tunnels and steers traffic per policy.

Underlay — two WANs

WAN1 is the operator’s DIA (CIR-00123, 500 Mbit/s, VLAN 2107, 203.0.113.10/30) — reserved by ROM, activated through the access NMS. WAN2 is the customer’s own broadband by DHCP — a reference in inventory, nothing more.

Overlay & controller

Encrypted tunnels from the branch to both hubs. The controller holds the overlay — site object, tunnels, policy — and is its system of record. SOM talks to it directly; ROM never does.

Hubs, DC & SaaS

HQ Oslo and DC London are the hubs, already live. Traffic to corporate applications rides the overlay; SaaS and Internet break out locally or centrally as the network’s policy says.

The decisions behind this architecture

Each is one legitimate choice, not the only one. What was chosen here, what the alternative is, and why the choice matters.

1The SD-WAN controller is its own domain, called by SOM through an adapter.

Alternative: The controller sits behind ROM, as one more activation target.

Why it matters: The overlay is a service-level construct with its own system of record. Behind ROM, overlay changes (policy, QoS) would run through resource ordering that has nothing to allocate. The cost: SOM needs a second southbound interface, and the adapter becomes an owned component.

2Two CFS levels: one network service per customer, one site service per site.

Alternative: Site services only, each carrying its own copy of policy and topology.

Why it matters: Network-wide things change once. With site-only services a policy change becomes thirty orders, and the copies drift.

3The operator’s own access is an RFS of the SD-WAN site.

Alternative: Access sold as its own product (DIA), related to the SD-WAN site — or the customer brings its own.

Why it matters: Inside the SD-WAN product, one order delivers the site. As a separate product, access can be sold, priced and assured on its own and reused by other products — at the price of coordinating two orders. Customer-provided lines are references either way.

4LAN addressing comes from the operator’s IPAM.

Alternative: The customer manages its own addressing and supplies the subnets on the order.

Why it matters: The overlay needs unique subnets across all sites. Whoever owns the plan must check that uniqueness — decide which one, and never both.

5The controller is the system of record for overlay configuration; inventory holds references.

Alternative: Mirror the full overlay configuration into service or resource inventory.

Why it matters: Copies drift the first time someone changes a setting in the controller by hand. References can be reconciled; copies have to be kept in step.

6The edge is claimed into the customer’s tenant before it ships.

Alternative: Claimed on site, when the installer reports the serial.

Why it matters: Claiming first means the box configures itself on first power-up — but only if the serial shipped is the one claimed. Claiming on site tolerates a swapped box at the cost of a step on the day.