An enterprise with vEdge and cEdge sites reports inconsistent routing and missing centralized policies after adding a second Controller. All edges show control connections, but OMP routes differ between sites. Which Controller control-plane function should the engineer verify first to explain consistent route and policy distribution over OMP?

The correct verification is that the Controller builds full OMP peering and distributes consistent routes and centralized policies because the SD-WAN control plane separates secure transport from route and policy propagation, and after adding a second Controller divergent OMP views directly explain differing edge RIBs and missing centralized policy application across vEdge and cEdge sites. Checking authenticated DTLS/TLS session establishment validates only transport security and device authentication, which the stem already rules out as the cause since all edges show control connections up, so it cannot explain why OMP routes differ. Advertising OMP routes while delegating enforcement to local edge configuration is operationally sound for some distributed templates but fails the stated centralized policy requirement, since missing centralized policies must be sourced and versioned from Controllers, not replaced by local configuration. Synchronizing Controller state for redundancy while keeping independent per-site OMP tables is a plausible scaling optimization but violates the explicit need for consistent distribution, as site-specific tables intentionally create the differing views reported. As an exam caveat, do not equate control-connection state with OMP convergence, because TLS/DTLS up does not mean OMP peers are fully established or policies are synchronized between Controllers. As a practical check, compare show OMP routes received and centralized policy status on contrasting sites with Controller OMP peer and policy summary to confirm both Controllers advertise the same prefix set and policy version.