A fire district is building the SD-Access underlay and wants a stable IGP. Which prefix policy correctly reflects underlay design intent?
Select an answer to reveal the explanation.
Short Explanation
The underlay is the highway system; it should know road IDs, not every passenger’s home address. Keep infrastructure and locator prefixes in the IGP, and let the overlay track user endpoint subnets. Dumping every user subnet into the underlay makes the highway map noisy and brittle.
Full Explanation
A fire district building a stable SD-Access underlay should carry infrastructure/locator prefixes in the underlay IGP and keep noisy endpoint subnets in the overlay rather than redistributing them into the underlay. That prefix policy keeps the underlay small, stable, and focused on fabric node reachability for public-safety sites.
Redistributing every user endpoint subnet into the underlay IGP so edges can route without LISP defeats overlay mapping and bloats the underlay with churn.
Replacing the underlay IGP with end-to-end spanning user VLANs across all cores abandons the routed underlay model.
Injecting default routes from every access VLAN into the underlay to accelerate onboarding pollutes underlay routing with access-VLAN artifacts.
Exam caveat: underlay may include selective shared infrastructure routes, but user EIDs belong in overlay mapping—not as underlay IGP noise.
Operational check: inspect underlay LSDB/RIB for locator-only intent, confirm user subnets are absent from underlay, and test overlay reachability via LISP. Publish the underlay prefix policy in the fire-district fabric design. 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.