A port authority configures EIGRP stub routing at remote fire stations. What primary problem does the stub feature address?
Select an answer to reveal the explanation.
Short Explanation
Remote fire stations should not be asked "do you know a path to the whole county?" Stub tells the hub: this spoke is a dead-end for queries—do not fan the search out there. Smaller query blast radius, fewer SIA headaches.
Full Explanation
EIGRP stub routing at remote fire stations primarily limits query propagation. A stub spoke advertises itself as stub so the hub does not query that spoke for paths to the rest of the autonomous system. Fire-station remotes are typically edge sites with no useful alternate transit path through them; marking them stub shrinks the query blast radius after a failure elsewhere and reduces Stuck-in-Active risk on the port-authority or county hub. Stub also constrains what the spoke advertises upstream depending on stub options, reinforcing the hub-and-spoke design intent.
Forcing unequal-cost load balancing toward the hub without variance fails by concept: stub is not a variance substitute. Converting EIGRP into a link-state protocol that floods LSAs only to the hub fails—stub does not change EIGRP into OSPF-style flooding. Disabling authentication on spoke WAN links is unrelated to stub and would weaken, not improve, overnight cutover security.
Exam caveat: stub stops the hub from querying the spoke for remote destinations; it does not by itself create a default route unless combined with appropriate advertisement/default behavior in the design. Operational check at the port authority: confirm remote fire stations show as stub neighbors on the hub, induce a controlled prefix withdrawal in a lab or window, and verify queries are not sent to those stub spokes while local fire-station prefixes still reach the hub as intended.