A logistics firm installs three on-premises controllers in its data center for a new overlay with organization name LogiCorp. Edge routers fail to authenticate and form no control connections despite reachable IPs. Which initial installation setting should the engineer verify first to restore controller adjacency?
Select an answer to reveal the explanation.
Short Explanation
You’re checking the foundation before restoring controller adjacency. A mismatch in the organization name can silently break every DTLS and TLS handshake in the overlay.
Full Explanation
All three controllers should have the same organization name, LogiCorp, unique system IPs, and correct VPN 0 transport reachability. These settings establish the shared identity and transport needed for controller adjacency; a mismatched organization name or transport fault can prevent DTLS/TLS control connections even when edge-router IPs are reachable. Checking the system IP, VPN 0 transport settings, and organization name on all edge routers is useful, but it does not address a controller-side mismatch: edge devices cannot compensate for controllers that disagree. Checking those settings on the primary controller only is insufficient because all three controllers must match; one correctly configured node does not resolve a fault on the others. Checking VPN 512 management settings on all controllers can confirm management-plane access, but it does not verify the VPN 0 transport used for overlay control traffic. A management ping may therefore succeed without restoring adjacency. The exam caveat is to distinguish management reachability from the transport settings required for control connections. As a practical check, compare the organization name, system IP, and VPN 0 interface status on each controller, correct any typo or transport mismatch, and then retry edge onboarding.