Question 160 A broadcast Ethernet segment with three OSPF routers stays at 2-WAY between two non-DR routers; operators expect every pair to reach FULL. Which lasting design or operational safeguard best prevents this particular issue from recurring? Deploy per-link OSPF timer templates as a paired change. Assign unique stable router IDs in the deployment inventory. Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. Educate monitoring rules on expected OSPF states for each network type. ExplanationCorrect Answer D:Educate monitoring rules on expected OSPF states for each network type. This addresses the recurring cause: On broadcast networks, DROTHER routers typically form full adjacency with DR/BDR, not each other. A targeted acceptance check is: Show correct DR/BDR roles and FULL adjacency to them without attempting to force all pairs FULL. Other Answers A:Deploy per-link OSPF timer templates as a paired change. On broadcast networks, DROTHER routers typically form full adjacency with DR/BDR, not each other. B:Assign unique stable router IDs in the deployment inventory. On broadcast networks, DROTHER routers typically form full adjacency with DR/BDR, not each other. C:Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. On broadcast networks, DROTHER routers typically form full adjacency with DR/BDR, not each other.
Question 161 A Frame Relay-style hub-and-spoke OSPF network has a DR elected at a spoke that cannot reach other spokes directly. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Use a network type and neighbor design appropriate for the nonbroadcast multipoint topology. Check NSSA Type-7 to Type-5 translation eligibility and ABR behavior, then correct the export design. Set compatible hello and dead timers on both ends of the same OSPF adjacency. Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. ExplanationCorrect Answer A:Use a network type and neighbor design appropriate for the nonbroadcast multipoint topology. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. Check network-type output, selected DR, and actual spoke route reachability after redesign. Other Answers B:Check NSSA Type-7 to Type-5 translation eligibility and ABR behavior, then correct the export design. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. C:Set compatible hello and dead timers on both ends of the same OSPF adjacency. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. D:Correct the interface or path MTU mismatch rather than using mtu-ignore as the default workaround. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation.
Question 162 A Frame Relay-style hub-and-spoke OSPF network has a DR elected at a spoke that cannot reach other spokes directly. Which technical mechanism best explains the behavior observed in this scenario? OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. OSPF neighbor creation checks hello/dead timer compatibility; mismatched intervals cause hello rejection. ExplanationCorrect Answer B:OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. This explains why the initial condition produces the observed failure. The direct repair is: Use a network type and neighbor design appropriate for the nonbroadcast multipoint topology. Validate through: Check network-type output, selected DR, and actual spoke route reachability after redesign. Other Answers A:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. C:OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. D:OSPF neighbor creation checks hello/dead timer compatibility; mismatched intervals cause hello rejection. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation.
Question 163 A Frame Relay-style hub-and-spoke OSPF network has a DR elected at a spoke that cannot reach other spokes directly. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. Trace the default route's OSPF source/type and validate the intended origination point. Check network-type output, selected DR, and actual spoke route reachability after redesign. Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. ExplanationCorrect Answer C:Check network-type output, selected DR, and actual spoke route reachability after redesign. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. Other Answers A:Compare interface MTUs and observe EXSTART progressing through EXCHANGE to FULL after alignment. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. B:Trace the default route's OSPF source/type and validate the intended origination point. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. D:Confirm unique IDs and clean neighbor/LSDB convergence following an approved restart. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation.
Question 164 A Frame Relay-style hub-and-spoke OSPF network has a DR elected at a spoke that cannot reach other spokes directly. Which lasting design or operational safeguard best prevents this particular issue from recurring? Keep ABR area-type policy consistent under redundancy changes. Assign unique stable router IDs in the deployment inventory. Teach path-type hierarchy alongside cost tuning in OSPF policy review. Specify OSPF network type and DR eligibility explicitly for hub-spoke media. ExplanationCorrect Answer D:Specify OSPF network type and DR eligibility explicitly for hub-spoke media. This addresses the recurring cause: OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. A targeted acceptance check is: Check network-type output, selected DR, and actual spoke route reachability after redesign. Other Answers A:Keep ABR area-type policy consistent under redundancy changes. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. B:Assign unique stable router IDs in the deployment inventory. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. C:Teach path-type hierarchy alongside cost tuning in OSPF policy review. OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation.
Question 165 An interarea route is absent because the only remaining area connects to the backbone through a nonbackbone transit area. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Repair Area 0 connectivity or configure a supported temporary virtual link through an eligible transit area. Identify the OSPF external/default origination and area behavior before altering an unrelated BGP attribute. Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. Make both sides' area-type settings consistent with the approved stub-area design. ExplanationCorrect Answer A:Repair Area 0 connectivity or configure a supported temporary virtual link through an eligible transit area. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. Verify backbone adjacency and restored interarea prefixes on the separated ABR. Other Answers B:Identify the OSPF external/default origination and area behavior before altering an unrelated BGP attribute. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. C:Enable the appropriate OSPFv3 IPv6 address-family/interface participation on that interface. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. D:Make both sides' area-type settings consistent with the approved stub-area design. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases.
Question 166 An interarea route is absent because the only remaining area connects to the backbone through a nonbackbone transit area. Which technical mechanism best explains the behavior observed in this scenario? OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. ExplanationCorrect Answer B:OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. This explains why the initial condition produces the observed failure. The direct repair is: Repair Area 0 connectivity or configure a supported temporary virtual link through an eligible transit area. Validate through: Verify backbone adjacency and restored interarea prefixes on the separated ABR. Other Answers A:OSPF election and adjacency expectations depend on network type; an unsuitable DR location can break multiaccess operation. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. C:OSPF INIT means hellos are received but two-way recognition is not yet confirmed in the neighbor lists. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. D:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases.
Question 167 An interarea route is absent because the only remaining area connects to the backbone through a nonbackbone transit area. After applying the correction, which verification evidence most directly demonstrates that this issue is resolved? Check network-type output, selected DR, and actual spoke route reachability after redesign. Check the area's LSDB and confirm expected default and no unwanted detailed interarea routes. Verify backbone adjacency and restored interarea prefixes on the separated ABR. Show correct DR/BDR roles and FULL adjacency to them without attempting to force all pairs FULL. ExplanationCorrect Answer C:Verify backbone adjacency and restored interarea prefixes on the separated ABR. This checks the affected traffic or control-plane behavior, not merely a generic up/down indicator. The underlying mechanism is: OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. Other Answers A:Check network-type output, selected DR, and actual spoke route reachability after redesign. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. B:Check the area's LSDB and confirm expected default and no unwanted detailed interarea routes. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. D:Show correct DR/BDR roles and FULL adjacency to them without attempting to force all pairs FULL. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases.
Question 168 An interarea route is absent because the only remaining area connects to the backbone through a nonbackbone transit area. Which lasting design or operational safeguard best prevents this particular issue from recurring? Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. Audit explicit OSPF costs during link-speed and redundant-link changes. Validate consistent stub/NSSA/normal area settings for all routers in an area. Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. ExplanationCorrect Answer D:Design durable Area 0 continuity rather than relying permanently on virtual-link workarounds. This addresses the recurring cause: OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. A targeted acceptance check is: Verify backbone adjacency and restored interarea prefixes on the separated ABR. Other Answers A:Include bidirectional hello and multicast delivery tests in OSPF interface acceptance. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. B:Audit explicit OSPF costs during link-speed and redundant-link changes. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. C:Validate consistent stub/NSSA/normal area settings for all routers in an area. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases.
Question 169 An OSPF route unexpectedly favors an intra-area path over a lower-cost external path to the same prefix. Which corrective action most directly resolves the documented failure without suppressing unrelated safeguards? Verify OSPF route-type preference before changing interface costs. Check NSSA Type-7 to Type-5 translation eligibility and ABR behavior, then correct the export design. Set compatible hello and dead timers on both ends of the same OSPF adjacency. Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. ExplanationCorrect Answer A:Verify OSPF route-type preference before changing interface costs. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. Compare route types and selected path with correct test prefixes after remediation. Other Answers B:Check NSSA Type-7 to Type-5 translation eligibility and ABR behavior, then correct the export design. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. C:Set compatible hello and dead timers on both ends of the same OSPF adjacency. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. D:Set a stable unique router ID and plan an OSPF process restart where necessary for it to take effect. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy.
Question 170 An OSPF route unexpectedly favors an intra-area path over a lower-cost external path to the same prefix. Which technical mechanism best explains the behavior observed in this scenario? OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. ExplanationCorrect Answer B:OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. This explains why the initial condition produces the observed failure. The direct repair is: Verify OSPF route-type preference before changing interface costs. Validate through: Compare route types and selected path with correct test prefixes after remediation. Other Answers A:OSPF SPF cost, including manually set interface cost, determines equal-cost installation within the same route type. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. C:BGP weight influences local BGP path choice, not which OSPF default LSA an area accepts from an ABR. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy. D:OSPF interarea routing relies on a connected backbone design; virtual links can restore logical backbone continuity in supported cases. OSPF intra-area routes are preferred over interarea and external routes for the same prefix by OSPF path-type hierarchy.
