Controller Placement for a Data-Residency-Constrained Global Rollout
A global manufacturer is migrating 380 branches in 14 countries to Cisco SD-WAN. Data-residency rules require configuration and flow metadata to remain in-country. It has two data centers-Frankfurt and Singapore-each with VMware clusters, 10 Gbps core links, and strong VMware operations skills but no SD-WAN experience. Branch transports are 20–100 Mbps MPLS plus 100–500 Mbps broadband; about 140 branches sit behind dynamic NAT with no static IP. Current RTT to Cisco-hosted controllers is 25 ms from Frankfurt and 110 ms from Singapore. The company wants controller redundancy with no single point of failure and a 12-month phased migration. It owns a Microsoft Enterprise CA and also has a public CA contract. The security team asks whether flow metadata leaving Singapore would violate residency, and the network team wants to know how the NAT branches will form control connections reliably.
1. What controller placement and redundancy model would you propose, and what residency caveat must be resolved before ordering hardware?
Read the worked answer
Start from what each controller does: vManage stores configuration and telemetry, vSmart holds OMP routing state, and vBond orchestrates connections. If residency applies to flow metadata, a two-DC hub design in Frankfurt and Singapore does not automatically keep data in-country for branches in the other 12 countries. Resolve the legal scope first. If 'in-country' is literal, deploy vManage/vSmart in each jurisdiction or use a regional Cisco cloud; a global vManage that receives Singapore telemetry is likely noncompliant. If the rule permits regional processing, use Frankfurt and Singapore as approved regional hubs and document which countries each covers.
For redundancy, deploy at least two vBond orchestrators with public DNS/IP, two vSmart controllers, and a three-node vManage cluster per management region. vBond should be reachable from all branches; vSmart and vManage should sit in the regional DC but be reachable through public or 1:1 NAT addresses. For 380 devices the scale is modest, so the driver is failure domain and residency, not throughput. Put vBond in both DCs so a DC failure does not strand branches. Test vManage cluster failover and vSmart failover before migration, and verify that telemetry stays within the approved boundary.
2. How would you handle certificates and the 140 dynamic-NAT branches, and why?
Read the worked answer
Use a public CA for vBond and preferably all controllers. With 380 routers, dynamic NAT, and a 12-month rollout, a chain trusted by default avoids bootstrap failures. The Enterprise CA is viable only if the root chain can be distributed and maintained on every router and the controller certificates include the correct SANs. Avoid an internal CA for vBond unless every branch can validate it during onboarding; a failed chain looks like a control-connection failure, not a certificate error.
Dynamic NAT does not prevent control connections if routers initiate outbound. vBond needs a public IP/DNS; routers behind NAT use NAT traversal. Do not put vSmart/vManage behind simple port forwarding unless there is no alternative; use public IPs or 1:1 NAT, and make sure the certificate SAN matches the address routers use. Allow outbound UDP 12346 and TCP 443/8443, and check firewall state timeouts. CGNAT is the real risk: if the mapping times out faster than the NAT keepalive, control connections flap even though data tunnels stay up. Confirm the timeout with the ISP or obtain static public IPs for critical sites. Validate with a pilot branch behind the same NAT type.
3. What should be validated in a pilot before the full rollout?
Read the worked answer
Run a pilot in each residency region and each NAT type. Validate certificate chain, clock/NTP, DNS resolution, and the exact controller FQDNs/IPs. Confirm control connections remain stable for at least 24 hours, not just minutes, and that OMP routes and TLOCs survive a vSmart failover. Test vManage cluster failover and confirm telemetry remains in the approved location. Check MTU and fragmentation to vBond/vSmart/vManage. For NAT branches, verify mapping timeouts and keepalives under idle conditions. Finally, test rollback: if a branch cannot connect, can it fall back to the legacy path? Do not scale until the pilot proves control-plane stability.