In an SD-WAN, what do the central controllers do, and how does a new branch edge provision itself through zero-touch provisioning?

## Three planes, three jobs No IETF standard defines SD-WAN, but implementations converge on the same division of labour. The words below describe that shared architecture. | Plane | Component | What it does | |---|---|---| | Management | **Orchestrator** | Holds device inventory, configuration templates, per-application policy, dashboards and logs | | Control | **Controllers** | Authenticate edges; collect and redistribute site prefixes, tunnel endpoints, keys and policy | | Data | **Edges** | Build tunnels over every transport, measure them, classify traffic and forward it | The control plane resembles a route reflector in spirit: each edge keeps a session to a small number of controllers rather than to every other edge. The controllers tell each edge which other edges exist, at which transport addresses, with which keys, and which private prefixes sit behind them. The edge then builds tunnels directly to its peers. - **Controllers are normally off the data path.** A store-to-hub voice call travels edge to edge through a tunnel; the controller only told both edges how to build it. - **Policy is central, enforcement is local.** An operator writes one rule, for example payment traffic may use MPLS or LTE but never guest broadband, and the controllers push it to every edge, which enforces it on each packet. - **Keys can be distributed centrally.** Some designs let controllers hand out tunnel keys instead of running a full pairwise key exchange between every two edges; the key-exchange protocols themselves are a separate subject. ## Zero-touch provisioning, step by step **Zero-touch provisioning (ZTP)** means a person with no networking skills can plug the box in and walk away. The sequence below is common; the details, including how the bootstrap service is found, are implementation choices. 1. **Before shipping**, the device's serial number and its factory-installed certificate are entered in the orchestrator's inventory and bound to a site, with that site's values (prefixes, circuit types, policy template). 2. **At the store**, staff connect the transports and power the device on. 3. The edge obtains a **transport address**, usually by DHCP on a broadband or LTE port, and reaches the internet. 4. It contacts a **bootstrap or redirect service** at a name or address built into its software image, authenticating with its certificate. 5. The bootstrap service recognises the device and **redirects** it to its own organisation's orchestrator and controllers. 6. Edge and controllers **authenticate each other**; the edge downloads its configuration and policy. 7. The edge joins the control plane, learns its peers and keys, builds its tunnels and starts forwarding. ## Where zero-touch breaks - **No automatic address.** A circuit that requires a static address, or a captive portal, stops step 3; a preloaded file or a technician is the fallback. - **No internet on the first port.** A store whose only working circuit is an MPLS VPN cannot reach an internet-hosted bootstrap service unless the carrier provides internet access or a reachable on-premises bootstrap exists. - **Wrong box at the wrong store.** Identity is bound to a site, so swapping two devices in shipping applies the wrong store's configuration; inventory hygiene is part of the design. - **A stolen device.** The certificate is the device's credential. Revoking it and removing it from the inventory is what stops a stolen box from joining. ## When the controllers disappear Because controllers are off the data path, losing them is not an instant outage. Implementations typically let edges keep forwarding on their last-known routes, tunnels and keys for a period, sometimes called headless operation. What stops working is everything that needs the control plane: - new stores cannot be provisioned; - policy and configuration changes cannot be pushed; - a tunnel that drops may not be rebuilt if it needs fresh information; - keys cannot be rotated, so tunnels eventually fail if the outage lasts longer than the key lifetime the implementation allows. For that reason controllers are deployed in redundant sets across sites or regions, and the controller's own reachability, over more than one transport, is part of the WAN design. The trade-off for central control is a new dependency: the WAN no longer depends only on circuits, but also on a software service that every edge must be able to reach.