Zero-Touch Provisioning Stalls Across a New Site Rollout
A logistics company is deploying 25 new branches with ExtremeCloud SD-WAN appliances and cloud orchestration. Technicians at each site rack the appliance, connect WAN1 to the ISP router, and power on. After 48 hours, 20 sites show healthy in the orchestrator, but five do not: three never appear as claimed, one appears but stays in a pending state, and one repeatedly reboots. Site details: one ISP uses carrier-grade NAT; one building has a captive portal; one ISP requires an HTTP proxy; one site's firewall blocks outbound 443; one site has a duplicate management IP from a copied staging config. The project manager wants to send replacements. You have remote hands and a 4-hour maintenance window.
1. List the provisioning dependencies you would verify, in order, before approving any hardware replacement.
Read the worked answer
Treat zero-touch provisioning as a chain, not a single event. Verify in this order: hardware power and boot health; link state and DHCP lease (address, mask, gateway, DNS, NTP); DNS resolution of the orchestrator FQDN; outbound reachability to the orchestrator on TCP 443, including any proxy or captive portal; accurate system time and certificate validity; correct serial number or claim code tied to the tenant; activation/licensing state; and finally the intended configuration template. A replacement only helps if the failure is in the hardware layer. If the appliance has a valid lease but cannot resolve or reach the orchestrator, a new box will fail identically. Check the orchestrator's own audit log for claim attempts and the site firewall counters for blocked 443 sessions. Only after confirming the chain should you use the maintenance window to swap hardware. The duplicated management IP is especially important: it can look like a hardware fault but is a staging error.
2. For each of the five failing sites, identify the most likely blocker and the first remote action.
Read the worked answer
For the CGNAT site, outbound onboarding should still work; check whether the orchestrator requires an inbound connection or whether the carrier NAT is timing out UDP keepalives. First action: test outbound 443 and capture NAT translation behavior. For the captive portal site, the portal intercepts HTTPS and prevents onboarding. First action: have remote hands whitelist the appliance MAC or bypass the portal for the WAN port. For the proxy site, the appliance may not be configured to use the proxy. First action: set the proxy or confirm direct egress is allowed. For the firewall-blocking site, check deny logs for the orchestrator IP/FQDN and open outbound 443. First action: validate with a packet capture or firewall log. For the duplicate management IP site, fix the copied staging configuration or use DHCP reservation; do not replace hardware. The pending-state appliance likely has a claim/serial or license mismatch; reconcile the serial in the orchestrator before touching hardware.
3. The PM wants to pre-stage all replacements with static management IPs and disable orchestration onboarding. Evaluate that proposal.
Read the worked answer
Reject it. Static management IPs reintroduce the exact duplicate-address problem already seen, create site-by-site manual work, and remove the orchestrator's ability to reconcile serials and templates. Disabling onboarding also defeats the deployment model and will delay the remaining 20 sites if the template changes. The correct response is to fix the onboarding chain: use DHCP reservations where static addressing is required, claim serials in advance, configure proxy or captive-portal bypass, allow outbound 443 to the orchestrator, and validate DNS and time. Hardware replacement should be limited to the appliance that is genuinely rebooting, and even that site deserves a boot-log review first. If a site genuinely cannot support ZTP, use a documented exception with a local staging file and a plan to return to orchestration, not a fleet-wide bypass.