A municipal library consortium wants LISP map-server/map-resolver services to survive a single control-plane node failure. What redundancy approach aligns with SD-Access fabric design?
Select an answer to reveal the explanation.
Short Explanation
The control-plane node is the fabric’s phone book for who lives where. If you only keep one copy and that box dies, lookups go dark. Dual CP nodes keep map-server/map-resolver service up so one failure does not strand the consortium’s EIDs.
Full Explanation
A municipal library consortium that needs LISP map-server/map-resolver services to survive a single control-plane failure should deploy dual control-plane nodes. Redundant CP nodes keep EID-to-RLOC mapping available if one node fails, aligning with SD-Access high-availability practice for civic fabrics.
Running the map-server only on wireless controllers and disabling LISP on wired edges breaks wired fabric mapping and misplaces CP function.
Replacing control-plane nodes with Anycast RP MSDP peers for unicast host mapping confuses multicast RP redundancy with LISP mapping services.
Storing all EID mappings exclusively in the underlay OSPF LSDB without a CP node abandons the LISP control plane SD-Access relies on.
Exam caveat: dual CP nodes need consistent MS/MR configuration and underlay reachability from all edges/borders; redundancy without reachability still fails.
Operational check: deploy two CP nodes, fail one in a window, and confirm edges still resolve mappings for a test endpoint. Document CP pair addressing in the library consortium fabric HA plan. In municipal operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the platform code and policy revisions used by the civic network team.