A sanitation department configures a remote site as an EIGRP stub but still needs that site to advertise one critical local prefix upstream. Which concept addresses that need?
Select an answer to reveal the explanation.
Short Explanation
Stub usually means "I don’t transit and I keep advertisements tight," but sometimes the landfill site must still yell about one vital subnet. A leak-map style exception lets that one prefix out without turning the spoke into a full query participant again.
Full Explanation
EIGRP stub with a leak-map (or equivalent selective advertisement) lets a remote sanitation site remain stub for query purposes while still advertising a required local prefix upstream. Stub alone often restricts what the spoke originates; when one critical landfill or plant subnet must be known at the hub without reopening the spoke to full query participation, leak-map-style exceptions advertise that prefix while preserving stub’s query-limiting benefit. That matches hub-and-spoke civic designs that need selective spoke origination.
Disabling stub entirely and relying only on defaults at every spoke fails when the design still needs query containment plus one specific advertisement. Redistributing the prefix into BGP solely on the remote router may be a different architecture, but it is not the EIGRP stub selective-advertisement concept the stem asks for. Setting variance to 128 so stub routers automatically originate every local subnet fails by concept: variance is unequal-cost load balancing, not stub advertisement control.
Exam caveat: leak-map/stub option details vary by platform IOS train—know the design intent (stub + selective advertise) more than a single CLI token. Operational check: confirm the sanitation spoke still appears as stub on the hub, verify the critical local prefix is present upstream, and ensure a failure elsewhere does not cause the hub to query that stub spoke for unrelated destinations.