A retailer with 60 stores must force all inter-store traffic through two data-center hubs for inspection, while hubs still exchange routes directly. Spokes must not learn each other's TLOCs via OMP. Which control policy construction creates that hub-and-spoke topology?

The topology depends on separating OMP prefix reachability from TLOC transport construction, and only centralized TLOC filtering on the controller forces hairpinning at scale for 60 stores because the controller reflects all TLOC advertisements. Limiting outbound TLOC updates so spokes install only the two hub TLOCs means spokes can build IPsec tunnels only to hubs, so inter-store traffic must transit a hub for inspection, while permitting hubs to retain full TLOC visibility preserves direct hub-to-hub tunnels and route exchange for resiliency. Filtering only OMP prefixes to spokes fails conceptually because spokes would still install peer spoke TLOCs and retain ability to establish direct data-plane tunnels, leaving the mesh intact despite restricted prefixes. Restricting all sites to spoke TLOCs fails conceptually because removing hub TLOCs eliminates hub-to-hub adjacency and the required inspection choke point, inverting the design toward isolated spokes. Redistributing spoke TLOCs outward from the hubs fails conceptually on enforcement point and outcome because a hub-local function cannot consistently control 60 spokes like a controller policy can, and it explicitly restores direct spoke-to-spoke peering that violates forced inspection. As an exam caveat, distinguish TLOC filtering that prevents tunnel creation from prefix filtering or data policy that only influences routing or forwarding after tunnels already exist. As a practical check, verify with show omp tlocs on a spoke that only hub entries appear and that spoke-to-spoke flow counters increment only on the hubs.