A university with 6,000 endpoints plans a two-site SD-Access fabric with redundant border and edge nodes, requiring fast endpoint roaming and resilient host tracking database lookups if a site link fails. Which control plane node placement supports resilient host tracking for this SD-Access fabric design?
Select an answer to reveal the explanation.
Short Explanation
You've got roaming users who can't wait on a WAN link for lookups. Local redundancy keeps the map database close and alive, a bit like keeping campus directories in each building.
Full Explanation
In SD-Access the control plane node hosts the LISP mapping database that maps endpoints to edge node locators, and edge nodes query it for every new flow, so placement directly affects convergence, roaming latency, and survival during partitions. Deploying redundant control plane nodes per site localizes queries, provides site survivability if the interconnect fails, and supports scale by distributing load while edge nodes register each endpoint with every configured control plane node, so no inter-node database synchronization is needed. Centralizing control plane nodes in the data center satisfies simplicity but violates the requirement for resilient lookups during a site link failure because queries would fail or hairpin over the WAN. Combining control plane and border functions on WAN routers conflates distinct roles and exposes the mapping system to border scaling and failure domains, which weakens both functions. Placing a single control plane node per fabric reduces signaling in theory but creates a single point of failure and scale bottleneck that cannot meet 6,000-endpoint redundancy and roaming needs. Exam caveat is that control plane redundancy complements but does not replace border redundancy for external connectivity. Practical check is to verify endpoint count and roaming scope per site before sizing redundant pairs.