A community college district must keep a remote site as an EIGRP stub yet still advertise one redistributed LTE prefix outward. Which pattern supports that limited exception?
Select an answer to reveal the explanation.
Short Explanation
Stub says “I’m mostly a quiet leaf,” but leak-map is the hall pass for one special LTE prefix headed out. You keep query protection and still announce the exception. Ripping stub out or cranking variance doesn’t create that surgical allowance.
Full Explanation
EIGRP stub with leak-map allows tightly scoped outbound exceptions—such as a redistributed LTE prefix—without returning the site to full query participation. A community college district that must keep a remote site stub yet still advertise one redistributed LTE prefix outward should keep stub enabled and use a leak-map (or stub leak) so the permitted prefix can be advertised while stub query limits remain. That limited exception pattern matches spoke designs with backup WAN injection.
Removing stub entirely and accepting full query participation re-exposes the domain to query load from that site. Setting variance to 128 so redistributed prefixes bypass stub rules automatically confuses load-balancing with stub advertisement policy. Changing the LTE prefix to a BGP local preference inside the EIGRP named process mixes BGP attributes into an EIGRP problem that stub leak already solves.
Exam caveat: only leak what must be advertised; overly broad leak-maps weaken the stub boundary. Operational check: keep stub on, apply leak-map for the LTE prefix, confirm upstream learns LTE while queries still honor stub limits, and flap the primary to ensure LTE backup behavior remains as designed.