In an OSPF network, users in a particular OSPF non-backbone area are complaining about show access speeds to a shared corporate resource in another OSPF are

Question

Options

• AMake the area totally stubby so that the default can be followed along the best path
• BCreate a virtual link between the areas so that traffic can shortcut directly between them
• CLeak specific summaries on the ABRs for the remote subnets in addition to the default
• DImplement policy routing to channel the traffic in the optimal direction

• A
  12% (3)
• B
  20% (5)
• C
  64% (16)
• D
  4% (1)

Explanation

Leaking specific route summaries on the ABRs gives routers in the non-backbone area the routing granularity they need to select the optimal ABR and path toward the remote resource, rather than blindly following a coarse default route that may traverse a suboptimal exit point.

Why the distractors are wrong:

• A (Totally stubby): This removes routing information by replacing all inter-area and external LSAs with a single default route - the opposite of what you need when granular path selection is the problem.
• B (Virtual link): Virtual links exist to extend Area 0 connectivity to a disconnected area, not to create direct inter-area shortcuts; traffic still must traverse the backbone, so no path is "shortcut."
• D (Policy routing): PBR is a manual, per-router workaround that doesn't scale and doesn't fix the underlying routing information deficit - it's fighting OSPF instead of using it.

Memory tip: When OSPF area users complain about slow access to specific remote resources, think "specificity solves the problem." Default routes are blunt instruments; leaking specific summaries gives the routing table the precision to find the best path. If you see "stub" or "totally stubby" in an answer that's supposed to improve performance to a known destination, it's a trap - those options strip information out.

No community discussion yet for this question.